[11-September-2023] Events Booking version 4.6.0 releases

Today, I am happy to announce next release of Events Booking, version 4.6.0. Below are the improvements in this release:

1. Improve Registration Form / Registration Process

- Allow easily displaying registration form in Columns format by changing Number Fields Per Row config option. So you can easily have registration form to be displayed in 2, 3, 4... columns if need.
- Do not process registration and display error message if users enter wrong coupon code on registration form so that they know about it and correct the code.

2. Add Auto Membership Plugin

This plugin bring a closer integration with our Membership Pro extension. It allows you to setup so that when someone registers for your event, they will be subscribed automatically to selected subscription plans in Membership Pro. 

3. Added Prevent Overlap Registration Plugin

The new plugin Events Booking - Prevent Overlap Registration if enabled, will prevent same user from registering for two events which overlap time with each other. Of course one person cannot attend two different events which overlap time, so sometime, it makes sense to prevent them to register for these two events using the plugin.

4. Layout Improvements

- Improve Table Layout: Added a new config option Show Category In Table Layout to allow showing event categories in Table layout
- Improve Events Booking - Advanced Events Slider module: Added a new parameter Thumbnail Width to control the the size of thumbnail displayed in the module. It is full width by default but you can change it to use the original thumbnail size if needed.
- Improve Events Grid Layout : Added parameter to allow using background color setup inside each category to display category for each event in the layout

5. Category Improvement

- Allow translating category's messages if the site is a multilingual website
- Allow using Custom Category Details URL if needed. This could be useful in case you are using paid builder to build category page and not using default category page generated by Events Booking.

6. Improve Check-in Registrants

Play different sound (for success and failure check-in) so that the users who perform checking in registrants are informed about check-in result, not only by the result message but also by success and failure sound.

7. Compatible with Joomla 5

The Joomla! development team just released Joomla 5.0 beta 1 recently. So we put some effort to work on the extension to make it compatible with Joomla 5 native (do not require backward compatible plugin enabled). We will still have to test more, but as of right now, the extension is fully compatible with Joomla 5 beta 1. That means you can start playing with the extension on Joomla 5 if needed.

8. Other Improvements

- Improve Frontend Registrants Management: Added parameter to allow controlling default category. It could be useful if you allows filtering registrants base on categories from frontend registrants management
- Added config options to allow Selecting Default Hours and Minutes for Event Date and Event End Dates of new events. That could be useful if the time (hours/minutes) are the same for most of your events, so you don't have to select the hours and minutes each time you setup new event.

9. Bugs Fixes

Make sure events are displayed on right language on Events Map module on multilingual website


Please update your site to this latest version of Events Booking to use these nice improvements. Thanks for continue using our products and support our development.

Regards,

Tuan

Thks Tuan!

I don't know where to find the update link ?

Hello

You just need to configure Download ID eventbookingdoc.joomservices.com/getting...on#use-joomla-update and you can then update to new version from within administrator area of your site (if your subscription is still active, we provide free upgrade for one year for each purchase)

Regards,

Tuan

- Allow easily displaying registration form in Columns format by changing Number Fields Per Row config option. So you can easily have registration form to be displayed in 2, 3, 4... columns if need.

I have searched in vain for where I can change the number of fields per row in the registration form. I cannot find anything in the code or in the db tables that looks like it has anything to do with the number of columns and I cannot find anything that looks like it controls this in the Configuration tabs.

Where is this tucked away??

Hi Dave

It is is Events Booking -> Configuration, General tab, Registration Settings section.

Go there find Number Fields Per Row config option and change it.

Regards,

Tuan

thank you. it might be useful to have that info in the documentation.

actually, since it appears that that there are a few hundred fields that can be figured in Events Booking, the vast majority of which will never be used by the vast majority of users, might be useful to have a way for people to more easily locate those few configuration options in which they are actually interested (when they discover that a particular option exists that could be useful to them).

The ordering of the options in a config tab or column of a tag looks like it is primarily determined by when the option got added to the product. there seems to be minimal organization by function or any other kind of logical or lexical characteristics.

perhaps, with so many options in so many tabs it would make sense to either have a good way to find which tab and where in the tab they are (column and position) using some kind of index, or you could prefix each option with a tab id, column id, (section id) and order in the column. you could then direct people to where the option field is located in the confirmation page using that prefix.

As it is, I don't see how anybody who doesn't already know how to find the right tab, the right label text could possibly find where to change a specific setting. I'm still not sure why I was unable to find this specific one before you told me the tab and column and text to look for.

thank you for implementing this feature... the two column registration form appears (at first glance at least) to be much more user friendly than the one column layout. I think it would make a much better (more intelligent and thoughtful arrangement of the fields) default layout - for the registration form than the current default as shipped - the single column layout.

well done.

  A few small "issues"

when I choose two fields per row on the registration form, the "Registration Information" title (eb-heading - which does not appear in the "translation" table for some reason) gets moved all the way to the right side of the two columns... I've observed this on my laptop, but not on my tablet. It's not pretty and it doesn't look like I changed it with CSS either. I hope you can easily fix it or give me a workaround.

I've changed (in Translation) the string EB_MEMBER_REGISTRATION from "Member [ATTENDER_NUMBER] information" to "Registrant [ATTENDER_NUMBER] information". However, that changed does not appear in the registration form - apparently because the string being displayed is "eb_heading", that same string which I cannot locate in the Translation table. Shouldn't it be displaying the eb_member_registration string?

I'm not sure what the "right" solution to this next issue might be... if somebody is purchasing several tickets then the form wants the names of the people for whom the tickets are intended. That's fine, but then in the "Registration Information" section, one of those names (I presume) has to be entered once again before the one person's address, etc.

These are "Individual Registrations" only - so I'm not sure why the form even allows somebody to purchase more than one ticket. I understand that I could set the "Only Allow Registering For One Ticket Type" switch but why is that necessary for an "Individual Registration" ?? What am I not understanding??

I have attached some screen shots so you can see what I see.

Hello Dave

1. About the issue with the layout

Could you please submit a support ticket sending us super user account of the site and link to registration form so that I can ask my template developer to look at it and find a solution ?

2. The language item which you need to change is EB_TICKET_MEMBERS_INFORMATION

3. Individual Registration is just the name of registration type. Ticket Types is actually, an optional add-on to that type of registration. So depend on how you want it to work, you can configure it to meet your need. For example, only allow registering for one type of ticket, do not collect members information for each ticket type....

Regards,

Tuan

#1 - I will create a test copy of the site and submit a ticket with credentials so you can see the problem and determine how to fix it. 

#2 as you can see from the circled text in the screen shot, the text says "MEMBER nnn Information" in the field I was attempting to describe. Using Chrome's debugger I can see that the code references a variable eb_header at this point ... which I presume maps to the constant  EB_HEADER. That just happens to be the name of the variable reference in the code that puts out the text that originally said "Member Information" and which I'd changed to "Registrant Information" - this the text the comes AFTER the names of the individual ticket holders and which my #1 issue is about...  It would seem that the code SHOULD be referencing the variable eb_ticket_information (which I presume retrieves the value of the constant  EB_TICKET_MEMBERS_INFORMATION) rather than the variable eb_header which I presume would retrieve the correct text constant. I can try to verify that when I get a chance but it would probably be more efficient for you to look into this. 

 
As for #3 - are you saying that there is no difference at all between an "Individual Registration" and a "Group Registration" other than the text that appears at the top of the registration form?? Generally, I think people would expect that "Individual Registration" sould mean that one person, an "individual" is registering themselves only and would expect that they'd be allowed to only get one ticket; "Group Registration" should  mean that they are registering more than one person - a family, a team, a group of friends, a couple - who all want to attend the event 'together'. Some may be "members', some students, some non-members, some 'seniors', some 'children', etc. Generally they would expect that the name of each attendee would need to be entered in the Group Registration form ... in the way the form does it now with the name of each attendee associated with their ticket type. 

It seems to me that an Individual Registration should

a) automatically limit the number of tickets to 1. Obviously, the one ticket can only be of one ticket type, so it should be unnecessary to say "one ticket of one type". There isn't any way to get one ticket of more than one type, is there?
b) not list the registrant name under a ticket type as there should only be ONE ticket and ONE ticket type involved in the transaction. Instead, only the fact that they are requesting on ticket of type xxx should be listed - without a name. Their name should appear directly under "Registrant Information"...and again in the payment information area as needed.

For Group Registration it DOES seem reasonable to list the registrants' names under each type of ticket as the form does now.  However, it is not at all clear whose name and address, etc. ought to go in the "Registration Information" fields. I think I understand that you want to collect information for who and how to contact 'somebody' who is the person 'responsible' for registering the group, but I don't think that is very clear at all to somebody who not already familiar with how this form works. Maybe just changing "Registration Information" to "Primary Contact Information for Group" would do the trick??

Thank you for the rapid reply and for your patience.