Forum Replies Created
-
Posts
-
And thanks for insisting on the problem.
Original cause: those 3 gateways “phone” home before going to their respective endpoints, and that is local code that existed before I started implementing memberships. So I forgot to adapt the price calculation there when memberships came into existence.Ok, success. Reason was: in the case of a number of payment gateways the payment price was being calculated as an event price, not a member price. This change should fix it (test seems to confirm it):
https://plugins.trac.wordpress.org/changeset/2008708/Since those gateways were never before tested with memberships, nobody stumbled on this error before … Payment gateways affected were: stripe, paymill and braintree.
The payment error handling is done by stripe. Again: every api has it’s own way of handling things, some better than others. The error ‘invalid positive integer’ is also generated by stripe, not me. That’s the only thing they provide, and so their error is what I can show.
Now back to the problem: the price being 0. I’ll test some more, I just realized I tested using an rsvp on an event, not a membership.
Edit: good news (now, well … good …): I can reproduce it, let me test more now.You have to check your stripe logs (even in test there is in stripe a log for every request). But compare your version of eme_payments.php with this one:
https://plugins.trac.wordpress.org/browser/events-made-easy/trunk/eme_payments.phpAt the bottom there’s a link to download the plain text version.
And if all else fails: give me admin access to a test site of yours where you have the issue. I’ll use my test key/pwd and see what gives then.
This is now fixed:
https://plugins.trac.wordpress.org/changeset/2008593/You can use eme_localized_date on the date, it will format the date based on your wp settings. If you don’t like it, you can even add a second argument to it with your own formatting (php date formatters):
eme_localized_date($event[‘event_start_date’]);
or
eme_localized_date($event[‘event_start_date’],”MY FORMAT”);
There’s also a function eme_localized_time (for time formatting).Use the placeholders mentioned in the link above in your template to be used in your eme_mybookings shortcode, that’s it …
#_CANCEL_URL will give you the cancel url (or use #_CANCEL_LINK to have a clickable link)
Update from the frontend is not possible
#_RESPSEATS gives you the number of seats
#_EVENTNAME will give the event name, and #_EVENTPAGEURL a link to it.The basic howto mentioned in the forum helps you along too:
https://www.e-dynamics.be/wordpress/forums/topic/how-do-i-get-started-with-eme/
And then:
https://www.e-dynamics.be/wordpress/category/documentation/3-installation-and-usage/The reason I’m not offering the direct answer is because you need to know how to work with EME so you can make your own changes further down the path. People ask me all the time for discount codes etc … in return they promise a donation and many never actually donate. So I stopped providing the “real” answer and prefer to help people getting to know EME. I’m planning on adding videos in the future too (the second mentioned link above contains some older youtube videos and howto’s too).
That’s only possible for logged in users of course. But then: use eme_mybookings, see
https://www.e-dynamics.be/wordpress/category/documentation/6-shortcodes/eme_mybookings/And the placeholders to use
https://www.e-dynamics.be/wordpress/category/documentation/7-placeholders/7-8-bookings-list/Please do use the search function on this site and check the doc on the right.
No 2 payment gateways are alike, so the resulting code needs to take all that into account.
But your error seems to indicate that the price now sent to stripe is 0 . The currency is ok, but apparently the price not. I’ll check this evening. Please check your webserver logfiles for regular php errors, because even the currency thing would have been logged as an undefined variable notice (and the fix would have been quicker)Arghl … the error was something totally different (although the lowercase is probably needed too).
This extra fix should help:
https://plugins.trac.wordpress.org/changeset/2008081There are just too many options for html to have them all covered, so I leave the extra html attributes up to the person defining them. It is never needed of course.
Concerning the fact it doesn’t show as you want in the backend: your theme might be interfering here, you should do some browser-debugging using your browser CSS debugger of choice.The trashcan is also present for other admin sections 🙂
But I added extra confirmation to most, see
https://plugins.trac.wordpress.org/changeset/2008076/
and
https://plugins.trac.wordpress.org/changeset/2008077/File upload will no longer be shown as a custom field for events or locations. Since you can upload files in WP media library or when defining the event/location in the event/location notes, this is not needed.
Feel free to convince of another answer 🙂I get a popup when using the trashcan-image or when selecting multiple records and selecting the bulk action to delete those. Do both not present a popup? Because certainly the bulk-option does not proceed without approval, the trashbin-image thingie is from inside jtables javascript itself and might not show a popup in your case.
See if this helps:
https://plugins.trac.wordpress.org/changeset/2008048/This seems to be the problem:
Missing required param: currency
The thing is that that param is passed (the value being the currency of the membership defined). Do you have some custom currency defined for your membership or so?
I’ll test it here tooConfirmed, this should fix it:
This change should help you:
“Allow a separator to be specified for multi-value custom fields when printing the values via #_FIELD or #_FIELDVALUE”
Change: https://plugins.trac.wordpress.org/changeset/2008007/Although custom fields per event (not talking about custom fields for the rsvp form) are now possible, some do not make much sense of course. In the case of a file, you can just as well upload it to the wordpress media galery and select it there.
But you’re correct in the fact that I don’t take file uploads totally into account here.I need to check the code for updating personal fields in the db. Of course it should always take the latest info from the form.
Concerning your second request: you can create a custom formfield and use it in your rsvp form, bt just don’t designate it as a “person field”. That way it will be stored with the booking, and not with the person. This is the recommended method if you ask for booking-specific info.Set the minimum number of seats to book at 0, or use the “attendance” rsvp type when defining your rsvp parameters.
Already possible, see the doc at https://www.e-dynamics.be/wordpress/category/documentation/7-placeholders/7-2-events/ :
#_ADDBOOKINGFORM_IF_NOT_REGISTERED adds a form which allows the visitors to register for an event. The form is displayed only if RSVP is enabled for the given event and if the user hasn’t registered yet (only possible to detect if the RSVP is for WP registered users only). See the placeholder doc concerning ‘Registration form fields’ to change the format of the form.
#_CANCELBOOKINGFORM_IF_REGISTERED adds a form which allows the visitors to remove their registration for an event. The form is displayed only if RSVP is enabled for the given event and if the user has registered already (only possible to detect if the RSVP is for WP registered users only).Also, there are several conditional placeholders, to be used with the [eme_if] shortcode. See https://www.e-dynamics.be/wordpress/category/documentation/7-placeholders/7-1-conditional-tags/
That has already been fixed in the dev-version, but it shouldn’t lead to 500-errors for stripe. You need to check in your logs and first find the 500-line (typically in your error log).
You can also delete a whole bunch of records in one go, telling the record name would be pointless. It only deletes the records you selected, do visual confirmation is already present.
But I don’t really understand your remark about the record indication on the template page.When you delete the plugin, all data gets removed which is the correct thing to do.
Otherwise there would be EME DB tables and options left without any purpose.Dynamic data shows extra fields based on the value of other fields, nothing more. Those dynamic fields themselves can’t contain other conditions though.
You can’t use multiple forms for one event because it would get confusing in the backend: what if the used rsvp template got deleted and I need to edit a booking? How would I know which fields actually to use then? While this is the responsibility of the system manager, it is more likely to happen if you add multiple templates to 1 event. And using conditional tags, dynamic fields and other methods you can achieve pretty much anything (and personally I don’t see a use in having multiple rsvp templates for 1 event, because in the end it is still an event, not a questionnaire form like some people would like).
Maybe some cases do exist, but adding the code would be for such a low usage that currently I don’t see much benefit besides me coding it 🙂Booking form and Registration form are the same.
RSVP template is something else: it is the template used to build the form. It stems from the fact that in the past there were no templates …
I’ll go around and take a look at nomenclature later on, but this is low priority for me 🙂 I’m open to all changes being submitted though.Btw: your idea for discounts might not be so bad 🙂
I’ll take a look at maybe just take multiprice-discounts into account too.Indeed, that should be fixed with this:
https://plugins.trac.wordpress.org/changeset/2006005I said that because of the simple use case you had: check if the user is in a certain group and then apply a discount. Without coding, that works for a simple fixed discount, but not for multiprice and different discount amounts.
If you want that, you’ll need to start coding some small things yourself (like mentioned in the filters documentation).First: you pointed a bug out to me concerning hidden fields (the empty value). This will be fixed in the next version.
Second: you can’t use it that way (because it is a hidden field, and the value there has no relation to whatever you choose for seat value).
If you want something more complicated, you need to read up the documentation concerning discount filters here: https://www.e-dynamics.be/wordpress/category/documentation/12-hooks-and-filters/Thanks.
This should fix it:That page should not be used in your menus or for anything else. See the doc:
https://www.e-dynamics.be/wordpress/category/documentation/3-installation-and-usage/Read the doc on the shortcode eme_events, paging is perfectly possible:
https://www.e-dynamics.be/wordpress/category/documentation/6-shortcodes/eme_events/
Also, for filtering, use the addition shortcode eme_filterform
https://www.e-dynamics.be/wordpress/category/documentation/6-shortcodes/eme_filterform/I think you need to use “+” there, not “,”. The logic being that you probably want events not in category 10 *and* not in category 11. In fact the “,” is pretty useless in a “not”-case.
But for the “+” I just added a small fix:
https://plugins.trac.wordpress.org/changeset/2005365/Confirmed as a bug, will be fixed in the next version.
Here’s the change (a bit more than what’s needed for you, but it will work):
https://plugins.trac.wordpress.org/changeset/2004877/Meanwhile I changed the logic, so it should at least be a little more intuitive: the values are always shown, for the search you can just search on text and optionally limit the search to certain custom fields.
Could you check if this one-liner fixes it for you:
1 and 2 are updated in the doc.
3 and 4 are tackled in the next version, where the edit/add screens have been revamped and more explanation has been added.Well, quite easy: just create a custom field with “extra charge” set to yes and the value to something negative (for the discount). You can even make that a hidden field, so it doesn’t bother anybody.
Then use a conditional tag around that field and you’re good to go.
While I’m at it, maybe I’ll extend the basic discount functionality to include this directly, but I need to think how to implement that in a user-friendly fashion.Pages are not in membership context. For events, you can use event placeholders in rsvp mails, thank-you message, the event format etc … And this is identical for memberships: the membership placeholders are only valid in membership mails, membership signup etc …
The conditinal tag is_user_member_of is handy so people can show/hide stuff (be it custom fields in a rsvp form, text, the whole event) based on wp-login and eme membership.You’re correct for the logged-in part This should fix that:
https://plugins.trac.wordpress.org/changeset/2002594/events-made-easy/trunk/events-manager.phpConcerning your tests with other placeholders: like I already said: they waork only in a membership context. Testing them on a plain wordpress page or event won’t work.
And for your question about adding the wp-id automatically: I stopped doing that because of the problems with maintaining that link (for rsvp forms, in the backend, multiple member signups for other people with the same admin account in the front, …). So it needs to be set manually.
#_IS_USER_MEMBER_OF is meant to evaluate if the logged in user is a member of a EME membership, and that is checked by linking your WP user with an EME person (go in EME=>People and edit the person of choice, you can there link your wp id to that person).
#_MEMBERID only results in something related to EME member (like a mail, or a pdf when in the EME member overview).
I’ll check #_AVAILABLESPACES{nn} later on.The IS_USER_MEMBER_OF was failing due to a wrong sql statement, not the conditions.
This fixes that issue:
https://plugins.trac.wordpress.org/changeset/2002206/#_AVAILABLESPACES{n} only works if your event is multiseat … is that the case?
Well, using the latest version will result in correct (and documented) behavior for the shortcode, no need to check on that with developers …
For all to know: reason was in the German translation (using double quotes in a translated string while the original is using single quotes). Translating for a html-project can be tricky 🙂
Whatever access is needed to be able to add/edit events. If you can reproduce this on a test site, even better.
Wait, I did some more testing: the code now returns a list of bookings, but for future=0 it seems to return all bookings, not just the ones for past events. Let me check this.
Edit: that is the correct behavior, also documented like this. So for me it seems ok.Well, the fix works here, tried both with and without future. Did you apply it to the latest version?
And if it doesn’t work, check your webserver logfiles for PHP errors, that might give an extra hint (it might be that you need to activate PHP error logging, see your provider if that is not the case).I’m sorry, I can’t possibly know all wp plugins 🙂
Like I said, it is just a normal form submit, so if it is not working, something is blocking it. Either use your webbrowser debugger to see what happens or give me access so I can see …
Also: there is a wordpress plugin called “Health Check & Troubleshooting”, that allows you to deactivate all plugins just for your session (and then you can reactivate in your sessions e.g. EME and see if it works).This will fix it:
https://plugins.trac.wordpress.org/changeset/1998945/Confirmed (I changed SPACES in SEATS, but forgot some things).
Simple workaround: use #_RESERVEDSPACES or #_BOOKEDSEATS.I’ve already changed the 2.0.77 version to account for the missing placeholder (if you reinstall it, it will be there).
It’s not really worth a new version, so I’ll hold back on that until extra things arrive 🙂Can you check if this fixes it for you:
https://plugins.trac.wordpress.org/changeset/1998386/events-made-easy/trunk
(only the second change is really needed, the first one is cosmetic)
Based on your video it seems indeed some plugin is blocking the form-post. Since it is a regular form submit (no js involved), there’s no other option (if there was an error further down the submit, it would show).
So check or disable your security plugin and try again.I can’t reproduce this, it works fine here. Can I have a test account on your site to see?
Or, maybe some security plugin is blocking the update action?The problem is that you use 2 seat categories but haven’t defined seat prices for these categories. I corrected your price setting, seems ok now.
And what is the minimum amount of seats required for that event? And when does the error poo up? All extra info is useful for me to try and reproduce it.
Or you can mail me a temp admin account, so I can see for myself (or create a test event that has the same problem and give me admin to only that event).Did you update to the last version? My tests with an empty field value work correct in dropdown and radiobox …
See the hint:
Showing custom field values can be heavy on the database. If you want to show some field values, select these in the “Custom fields” select-box shown above.
This was also a bug (albeit a very weird one …).
This should fix it:
https://plugins.trac.wordpress.org/changeset/1996716/If you can confirm it, then I’ll release a new version tomorrow.
Confirmed as a bug, this should fix it:
I’m guessing it it because the field No/yes/maybe has values 0/1/2. The value 0 might be the problem …
Ok found it, indeed an issue in eme.js
This should fix it (I changed it in the just released 2.0.74 too):
https://plugins.trac.wordpress.org/changeset/1993560Using that in a theme yourself , there is indeed a change (in that by default no echo happens of the list).
Either (using your example), just put an echo/print before your call:
<?php print eme_get_events_list("limit=0&order=ASC&template_id=8&category=1"); ?>
or add an extra “echo=1” to the parameter list.
Btw: is explained in the API doc (half/half) that points to the options of eme_events for all argument possibilities (and there the echo param is mentioned as “do not use”).Concerning your eme.js: is that in your own created theme-files? Because then you’re not loading all js-files.
Well, I fixed it and changed the plugin headers to 2.0.73 but forgot to create that tag, so that’s why I released 2.0.74 today (with more stuff 🙂 )
Already done, will be in the next version 🙂 Was mostly in info-text lines, some in presets and option values, some in comments (and I changed one variable name too).
Anyway, this is the fix:
https://plugins.trac.wordpress.org/changeset/1992655/Indeed, but I clearly mark the PHP version requirement on the plugin page @wordpress.
Unfortunately wordpress provides no means to give people a warning before downloading a plugin unsupported by their php version.
However: the current 2.0.72 no longer has this coding issue, I worked around it (although other parts of EME still have a requirement for newer php versions, like some payment gateways).It’s weird that php gives you that error. In my experience people with hosting providers often have older versions of php running than what they think they have. Put a phpinfo-call in a standalone php script on your site to check.
I’ll see if I can anyhow change my code to make it more simple for older version, but still that would require you to be able to update. For now: remove the events-made-easy folder, than will get you your admin-page back.This means you have a php version older than 5.6 (probably 5.2 or 5.3, versions that are out of support for several years already). EME requires at least 5.6
This means you have a php version older than 5.6 (probably 5.2 or 5.3, versions that are out of support for several years already). EME requires at least 5.6
Correction: there’s a typo in the location definition, maybe that is blocking it …
I’ll fix this asap and release a new version.If that table doesn’t exist, you are having issues with the update. Go back to the older version (I hope you made a backup) and try again …
Correct, this should fix it:
https://plugins.trac.wordpress.org/changeset/1988892/#_ICALLINK is meant to be used in the single event format settings. So enter it there (either specifically when creating/editing an event, or in the global EME settings menu)
Confirmed, fixed here:
https://plugins.trac.wordpress.org/changeset/1986398/events-made-easyNormally you need the capability “Edit events” for this, but the next version will also allow the creator to delete his own events.
See this change: https://plugins.trac.wordpress.org/changeset/1984135/This change should prevent wrong state/country entries:
https://plugins.trac.wordpress.org/changeset/1982264/Hmmm … weird that autocomplete should work, but that still shouldn’t leave you with an empty value as you described.
But on the other hand, you’re correct: I should check whether the value for the country in fact corresponds with an existing country in the backend. If you could provide me with a test scenario that most definitely results in a ‘wrong’ country value, then I can test on my side to see if the code I’ll add works.Do you use #REQ_COUNTRY ? That should require the field to contain data.
The search waits 0,5 seconds before doing an ajax call to the backend, to reduce the number of calls being made. In my tests, this is not slow at all, but of course ymmv.The next version will have this fix too:
“Auto-approve after payment now also works if you manually mark a booking as paid”That button will return (I saw that too), that’s already fixed in dev.
I’ll also check if the auto-approve option is used when marking as paid.Since these already exist for quite some time now:
#_IS_USER_IN_GROUP{xxx} (‘1’if the logged in WP user is in the EME group called ‘xxx’, ‘0’ otherwise)
#_IS_USER_MEMBER_OF{xxx} (‘1’if the logged in WP user is a member of the EME membership called ‘xxx’, ‘0’ otherwise)this means we can use conditional tags to show/hide stuff (and also the rsvp form has these as extra invocations #_ADDBOOKINGFORM_IF_USER_IN_GROUP{xxx} and
##_ADDBOOKINGFORM_IF_USER_IS_MEMBER_OF{xxx} )
So for now, I’ll close this.I did a little more digging: 2.0.59 (I already deleted the 2.0.58 tag) and newer have no DB changes made to them (only code), so while I assume you were already on something newer than 2.0.58 (by following the updates), this remains a mystery. Nothing in my code can explain a column just disappearing in mysql …
I’m glad it works again for you, but maybe you should check with the db-guys if they can see anything in their logs that might help pinpoint the origin of the problem.This is simply not possible 🙂 The creation date gets set upon booking and never changes again.
I’m interested in your DB version here. Also a dump of your mysql booking-table might be interested to take a look at.There’s no real mail setting changed between 2.0.65 and 2.0.66 … if you use mail queuing, mails arrive with a delay of course. Or maybe spam? Also, check your mailserver logfiles.
2.0.58? That contains the column by default at first install, and no actions are taken on that column later on. Make sure nothing is wrong with your database in general …
Which version did you update from? This column is always present since version 1.x of the plugin (years ago, in the beginning it got renamed from another column though).
If that’s the only column missing, execute this in your db editor (phpmyadmin or so):
alter table wp_eme_events add event_author mediumint(9) DEFAULT 0;
But really, what version did you update from?It took me a while, but in the end I already had the code without realizing it. So the next version will no longer allow a booking if you enter an incorrect discount code.
You can of course put anything you want in the discount field, but only accepted discount codes will affect the price. The patch I gave is only for the discount field being required, it has no other effect than that. I’ll check here to see if the discount-functionality still works to be sure.
That’s just a limit I had on the input field (2 chars). I’ll increase it to 3 this evening (2-line change in eme_events.php).
You’re correct, small bug in the code upon submit (check can be disabled with the setting “Check required fields upon submit?”).
Fix is here:
https://plugins.trac.wordpress.org/changeset/1973871/(only the line with DISCOUNT is needed, the rest is more cosmetic).
When defining the RSVP settings for an event, you can define exactly when rsvp should start. So no need for eme_if here.
5.6 is since long the minimum required version for EME, and you should upgrade to 7.1 or even better 7.2 as soon as possible.
The Mollie code is not mine, but provided by Mollie. If you have a syntax error, your php version is too old.
Wordpress allows overrides for themes (using a child-theme), but not for plugings. So it will not happen as long as wordpress doesn’t provide an interface for it.
While EME can provide subforms (using dynamic data), it is only 1 level deep. If you want some fields based on info per field, you’ll need your own jquery for that.
But even the subform can contain fields that influence the total price 🙂This is now implemented. See this change:
https://plugins.trac.wordpress.org/changeset/1971713/That option is now available when permanently deleting people (from trash). But you’re correct, it might also be there when moving to trash.
See this change:
https://plugins.trac.wordpress.org/changeset/1971696/This is indeed more logical. This change will fix this:
The nonce system is never intended for extreme security … even WP says that. For temporary url access it is of course ok, but for changing of user info I don’t think it would be sufficient.
But it goes beyond that in how to decide what can be changed, and how. Because not all info is added by the person in question too …That is not possible, as they are not registered people and so they can’t prove their identity. I’d need to start using passwords for that, and that’s over the top …
Also the problem with self-service is that e.g. for members the info needs to be correct (address, phone, …) so for now it needs to be done manually.The CSV report can show custom fields (check the hint on how to show custom fields).
But the html table sort is indeed an option.Fixed here (one-line fix in eme_people.php):
I tried your code in the format titled “Booking recorded html Format”, and it works just fine there …
You need to use “Contact Person Email Pending Subject Format” and “Contact Person Email Pending Body Format”.
Correct, I mixed up the name of the form with another form and thus an ajax-code intercepts it and the result is of course not what is expected, so nothing happens.
This is now fixed in development (and I ajaxified that cancel confirmation form too), I’ll release asap.EMEFS has its own settings, so no: these do not apply.
The next version of EMEFS will also have a setting concerning a honeypot field.You’re correct, it is a bug. While I was renaming the “delete_booking” to “cancel_booking” I missed some occurences in the javascript code. I’ll fix this today and release a new version later on (the dev-version already contains the fix now).
Just using unix line ending should work fine … I guess even windows line endings should be ok. PHP has a function that parses csv, but it is sensitive to line endings (like everything in php in fact). See also: https://stackoverflow.com/questions/4541749/fgetcsv-fails-to-read-line-ending-in-mac-formatted-csv-file-any-better-solution
Apparently the error is because of other plugins also using guzzler (part of mollie api), but probably older version. See https://github.com/mollie/WooCommerce/wiki/Composer-Guzzle-conflicts
My best guess for now: check all your plugins, disable all and reactivate one by one until you find the conflicting one. But again: it is a mollie api issue, not EME specific.
If you find the plugin causing conflict: you can report it to mollie on https://github.com/mollie (or your mollie tech contact).
Also make sure all your plugins are up-to-date and still maintained … if one uses also the guzzler library (like mollie does), then this will cause the problem.This is something else … this is internal Mollie code failing. Since it works for me locally and my provider: can it be you’re using an old php version? What is your php version?
Ok, I made a test booking (please do delete it so it doesn’t take up valid places).
The problem you’re seeing doesn’t seem to have anything to do with Mollie itself, nor the redirection to it. There seems to be an error in the backend when returning the ‘booking success” message.
This might be related to another bug that was just reported today and for which I released a new version, see: https://wordpress.org/support/topic/database-error-271/
If your success-message somehow contained the number of approved seats, that might have been the reason. What is the format of the success message?
Also, to make it easy: you can first update to 2.0.61 and see if that fixes the problem, then we know we were talking about the same issue.Your topic title is “customer not directed to Mollie after recent plugin-update” and now you’re saying it works ok with the live API key? Then I don’t see any issue.
So please redirect your questions concerning test api key and payment notification to Mollie, I’m not in control of their code (I just use it in the way they describe it). If they decide to not give out correct notifications for a test key, that’s not something I can change. Feel free to post any answer they may provide here.I already use the wordpress nonce as initial protection. Further protection: use the captcha and/or (recommended) only allow registered people to enter new events.
I just tried (signup to Mollie and requested a new API test key) and everything seems to work just fine.
Check your mollie API keys to make sure your keys are correct.
Btw: your error seems to be when mollie calls back to report the payment status, and that only works with a live API key. People shouldn’t see this error though.
Nothing in your error report points to an error with redirection to Mollie though.That was not in the info of your posts above. Let me check this, this might be related to the new api.
