Custom Booking Forms/ Form Fields

This topic contains 7 replies, has 3 voices, and was last updated by  Stephen Harris 9 years, 3 months ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #8123

    Hey Stephen –

    Sorry to be so present on these boards- you sound busy. Recently realized that custom form fields for event booking would be very helpful to us- I’d probably even pay a good deal extra for it.

    The organization we work with has to collect vastly different info for many events. If we could give non-programmer administrators an easy way to collect data about event attendees, I know they would really appreciate it. They need to collect data like “Do you need to rent a tent?” “Will you have a chaparone?” “Do you prefer the color red or blue for your souvenir?” Etc… These questions change frequently, and they host many events annually.

    There is even a reasonable amount of need for multi-attendee entries. (One ticket purchaser enters info for a number of people he/she represents).

    I imagine that a template system – where a number of event types/ticket types could be saved and reused– with as much administrative freedom as possible – would make my particular clients very happy.

    Not sure about precedent for this with other users of the plugin, however–but thought I’d ask

    If possible, I’d like to email you a link with some examples of how this has been implemented elsewhere.

    Hope you are well ! Thanks for your time!

    CE @ WA

    • This topic was modified 11 years, 1 month ago by  Ann/Caitlin Wiegand/Everett.
    Ann/Caitlin Wiegand/Everett
    #8126

    No worries! It’s great to get feature requests (even if occasionally we can’t fulfil them) – it indicates how the plug-in is being used (and how customers would like to use it) – and helps steer development :).

    As for custom fields for the booking form, you already have it: http://wp-event-organiser.com/pro-features/booking-form-customiser/ :). You can download this data when you download the bookings as CSV.

    There is even a reasonable amount of need for multi-attendee entries. (One ticket purchaser enters info for a number of people he/she represents).

    This is something I’m looking into, that is “ticket meta” rather than “booking meta” which the existing form customiser caters for. The idea is that these fields would be duplicated in the booking form according to the number of tickets selected. There are still some decisions to be made on how to handle this in the plug-in, and also, how the user interface should work.

    I imagine that a template system – where a number of event types/ticket types could be saved and reused– with as much administrative freedom as possible – would make my particular clients very happy.

    1.5 will see a change in the user interface for ticket management (loosing the cramped modal in favour of something inline where options can be revealed / hidden). This is partly pre-empting the admin UI changes WordPress will be implementing in 3.8 (http://www.wptavern.com/breaking-new-features-selected-to-merge-into-wordpress-3-8-core), but also about giving the ticket-edit area more space. With that comes the possibility of providing more advanced options – so this will definitely be looked at post 1.5

    (Feel free to email the links you referenced!)

    Stephen Harris
    #8210

    Hey again! Now that I have been using the booking form customization tool- I was hoping you can help me to understand how CSS works with this. Can I give fields classes? Check out our incredibly long form:
    http://boyscouts-dpvc.org/?event=voyageur-trace-district-cub-scout-polar-bear-prowl

    If I could use css to give sections widths or to give fields classes, I’d be really thrilled.

    Hope you are well.

    CE @ WA

    Ann/Caitlin Wiegand/Everett
    #8213

    Hi

    • Entire “bookings” area is given ID eo-bookings
    • The ‘booking’ title is given class eo-booking-title
    • The booking form is given ID eo-booking-form
    • Each form element is wrapped in eo-booking-field
      • Each actual form element is given the class eo-booking-field-X (where X is a type identifier, e.g. input, select, number, html etc).
    • Labels are given the class eo-booking-label

    E.g. to give all form elements of type ‘input’ 70% width:

    .eo-booking-field-input {
       width: 70%;
     }

    Does that help?

    Stephen Harris
    #8214

    I know- I realize that those things are possibe- but what ends up appearing are really complicated long lists– I am not having so much luck with making partitions that are meaningful. So- maybe for the future– if section breaks could be given classes or something like that– i dunno– just a though.

    All the best.

    CE@WA

    Ann/Caitlin Wiegand/Everett
    #9063

    Hi Stephen
    I would second the idea of having ticket meta. We often have the need to capture information about per person/ticket t-shirt sizes or different meal options per ticket (veggie/meat options).

    Thanks again for a great plugin
    Stuart

    Stuart Farish
    #9080

    Progress is being made for this. It won’t be in 1.6 but may just be in 1.7…

    Stephen Harris
    #18734

    Just an update here, but v1.11.0 is in beta and will support “Attendee questions”. This will be a ‘hidden feature’ at first in that there is no user interface for the customiser. But an API is provided by which you can register form fields to capture data on a ticket basis.

    Stephen Harris
Viewing 8 posts - 1 through 8 (of 8 total)
To enable me to focus on Pro customers, only users who have a valid license for the Pro add-on may post new topics or replies in this forum. If you have a valid license, please log-in or register an account using the e-mail address you purchased the license with. If you don't you can purchase one here. Or there's always the WordPress repository forum.