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

Thks Tuan!

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

- 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??

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.

#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.