A few suggestions and a question or 2

[Anonymous]

Thanks Franky for the quick response 🙂

Anyways, I had a few feature requests that I wanted to share (although the plugin is already awesome):

1. On the registration confirmation page, it would be wonderful if we could eliminate the huge space between the booking message and the payment button. Alternatively, if we could have “payment format” option boxes like those in Settings=>Event and RSVP that would be wonderful!
2. The new multi-price addition is great but is there any way to automate the addition of the multiple seat selection to the registration form? (SEAT1, SEAT2, SEAT3, etc.) It’s not difficult for me, but my clients will never be able to add the correct code. I tried to set it up with a conditional

   [events_if tag='#_PRICE' contains='||'] <tr><th scope='row'>#_ATT{TICKET2}{Children}* $#_PRICE:</th><td>#_SEATS2</td></tr> [/events_if] but it looks like the php that checks for SEAT2 is processed before the conditional so it always generates the error on the event page “Not all required fields are present in the booking form.”. Any ideas for a workaround?

3. Is there a way to add global shortcode access to all the format areas? In particular, I wanted to use one of my custom attributes in the Reservation Form but it just shows as #_ATT{TICKET_LEVEL}. Could you add the ability to use custom attributes everywhere?
4. Could you add the ability to initialize a custom attribute in the RSVP Form rather than the single event page in Settings? For now I had to use a workaround and initialize my custom attribute within a conditional so it doesn’t show on the event page.
5. Is there a way to parse/select one of the values in a multi-price event? (like #_PRICE[1], #_PRICE[2], etc)
6. Is there a way to add a payment option, like cash? (can we do this, obviously you can if you had time 🙂 )
7. This one is just for user ease — when you edit an event could you make it just reload the page with an “updated” message rather than returning to the events list?

   Thanks again for the awesome plugin, these are just some requests/ideas that I think might really smooth out some of the functionality.

[Franky]

1: br-tag removed, see: http://plugins.trac.wordpress.org/changeset/696256

Although a payment-format option is a good idea, it would solve some other things as well. Leaving this one still open.

2: not really possible: the thing is that I don’t know what title each price would have. For now the multi-price is really a hack of the regular price thingie, so you need to add your own text for each possibility. And I do indeed check this, but I’ll take a look at your conditional tag thingie.

3: let me check 🙂 The Reservation form is “new”, so I might have forgotten about it 🙂

4: Should be ok once 3 is sorted out

5: #_EVENTPRICExx or #_PRICExx is already there

6: no, not possible. Adding a “cash” option is best just putting it in either the event details and/or the mail for now. Do you mean a possibility to say “Cash” on the payment page?

7: the problem is: you can edit a single event to become a recurrent event, so I would need to check all that just to let it show again. Might be better from user point of view but it’s a PITA to code up properly (and I would need to clean up the current code first …)

[Franky]

Could you check if 2,3 and 4 behave better with this change:

http://plugins.trac.wordpress.org/changeset/696268

And I added a new conditional tag #_IS_MULTIPRICE:

http://plugins.trac.wordpress.org/changeset/696271

[Franky]

I edited the doc at http://www.e-dynamics.be/wordpress/?cat=25 to explain this part of my previous comment:

5: #_EVENTPRICExx or #_PRICExx is already there

[Anonymous]

Franky you make these code changes way too quickly, I think you need a hobby ;-). But seriously, thanks for the quick response, I’ll test all these new changes in the morning.

[Anonymous]

Shh! He’s been on a great tear lately (development was a bit slower before) and I don’t want it to stop! 🙂 The software’s been getting better and better.

It’s very rare to get this kind of attentiveness on any software project, whether free/donationware or commercial.

[Anonymous]

Ok, I tried to test out as much as I could but there were a lot of variables going on here.

1. Number 3 from above seems almost completely fixed. It now evaluates my custom attributes in the RSVP Form Format box to their correct values rather than “#_ATT{Ticket}”.
2. Number 4 from above is not working, I still have to initiate any custom attributes in an event form rather than the RSVP form.
3. I still can’t get the conditional to work. I tried the “#_IS_MULTIPRICE” test but it failed with both values of 0 and 1. Also, to clarify from above, I know you can’t code it to automatically name the additional prices I was just wondering if it was possible to build in the logic I’m attempting with my conditional that if there are multiple prices the # dropdown will be automatically added in the form. The name attached to them can be a default of Seats1, Seats2, Seats3, etc — we can always change that with custom attributes.
4. #_PRICExx did not work in any way I tried it but #_EVENTRPRICExx did work. That being said, it ONLY evaluated in the RSVP form if I first included it in one of the Event forms. Like #1, it seems like you still have to use most shortcodes (custom or other) at least once in an Event form before they are recognized in the RSVP form. 🙁
5. Regarding issue 1 above I’m not sure I was clear. When you submit a registration the confirmation page has a huge space between where it says “Payment handling” and the actual button. It looks like this can be fixed (at least for paypal) by removing the new line code (.”n”) from line 101 of paypal.php (as each hidden field is creating a new line for some reason.
6. The new version of events-manager.php you updated is missing a “}” on line 1431 before the else 🙂

Thanks again and hopefully we can work these things out.

[Franky]

1: ok

2: I only take into account custom attributes defined in the “Settings” pages of EME, not those per event. I could do that, but then a reload would be needed before the custom attributes section appears etc … I do welcome patches here.

3 and 4: should be ok now with this (tested this time): http://plugins.trac.wordpress.org/changeset/696778

5: html doesn’t care about newlines, only html matters. So I removed the “br” tag as said: the button is now much closer to the “payment handling” text.

6: was already fixed 🙂

[Anonymous]

Thanks so much for all the fixes and awesome response time!

2: I only take into account custom attributes defined in the “Settings” pages of EME, not those per event. I could do that, but then a reload would be needed before the custom attributes section appears etc … I do welcome patches here.

Sorry I wasn’t clear again. I meant to say that even if I add a custom attribute in the Settings => RSVP page (rather than the Settings => EVENT page) it will not appear in an event as a fillable attribute.

[Franky]

Are you sure? This change (made some comments ago) should fix that: http://plugins.trac.wordpress.org/changeset/696268#file0

[Anonymous]

Thanks as always Franky. I updated to the newest trunk and now it seems to be working — with the caveat that when I initialize the custom attribute I include the alt text (which is fine). Keep up the great work!

P.S. Any workaround/way to get that conditional I posted above to work? The conditional check is now successful but it seems that if “#_SEATS2” is in there at all then it always assumes it to be a multiprice event, even if “#_SEATS2” is only in the conditional, and thus it gives the error message “Not all required fields are present in the booking form.” Pictures for reference: http://imgur.com/Q1AYtzr,K5VWWHt

[Franky]

Yeah … that’s a difficult one: for now I just count the ones I encounter, conditionals are not interpreted (which would be impossible anyway: it would change the content of #_SEATS2 as well, so I couldn’t count it).

I need to add better logic there and really search for e.g. #_SEATS1, #_SEATS2 when it’s multiprice with 2 prices. Even then a conditional tag might mess things up …

Can you try to change line 361 and 369 in eme_formfields.php to use “>=” instead of “==” ?

So it looks like

if ($required_fields_count >= 3+$count) {

and

} elseif ($required_fields_count >= 4) {

[Anonymous]

I was just trying to find that piece of code 🙂 Thanks for the help, I’ll give it a shot.

EDIT: Success!! Thanks so much Franky, now I can make this easy enough to hand over to non-tech savvy clients.

[Franky]

GReat! I’ll add it to trunk this evening. So I guess all your requests made in this thread are ok now?

[Anonymous]

Pretty much 🙂 I’m sure we’d all love to see a more fleshed out multiprice system in the next release but there’s no rush as everything is working wonderfully.

[Author]

Posts