How upgrade-proof are custom overrides?

Hi,

I'd like to simplify the frontend simple event submission form as some of the fields just aren't relevant to my users. I know I could create a custom override for my template as per the documentation, but how likely is it that a new version of event bookings will break my template override? I don't really want to create more work for myself in future.

I had though about using CSS to simply hide the input fields I don't want to be displayed, but there aren't CSS IDs on the control groups so I can't reliably hide the right fields in case you were to change the simple template.

Thanks,
Roger

Which control groups / input fields were you wanting to hide? Most items on the form do have ID's, so it must be a section that doesn't that you want to hide. I'd probably use CSS to hide whatever I could as it is less likely to cause an issue down the road, but that's more my style, especially since my site provides a unique ID to every event, so I can target specific events this way.


Just be careful not to hide a REQUIRED field!

Back to Part 1 of your question. Yes, there is a risk of problems, but usually, not big ones.

I spent my the entire day today updating my old overrides, which I haven't touched in a year or two, in order to get some of the new features working. This is usually the only time I need to worry about my overrides. I was actually surprised how well my site was still running as I looked at one of my overrides, realizing what used to be a one-file template was now a 10-file template, but my one-file override was still working! Glad to have the new features that I have been missing now!

Only once that I can recall (a few years back) had one of my overrides broken EventBooking because changes to EB were dramatic enough to be incompatible with the old file my override was based off of. A few times, the custom features that my override added broke because of changes EB to the core functions that my override was calling. I always tag my changes (I use my name & the date of the mod) in my overrides so that I can find my custom code again.

Hello

I always try my best to make new version backward compatible with old version. So creating override would no cause any problem, it will still work well when you update to new version of Events Booking in the future (at least during 3.x series)

The only problem with implementing override is that when there is new features added (to the layout which you created override), that new features won't be available because you have an override for that layout which is base on old code

However, for submit event form, I don't think we won't add many new features there, so override should be safe

I don't know which one you need to remove, but I think you can try to hide it using css. Although it doesn't have css class or id, I think you can use :nth-child() CSS pseudo-class developer.mozilla.org/en-US/docs/Web/CSS/:nth-child to hide the element you don't want

Tuan

@James @Roger is trying to make override for frontend event submission form, not registration form

Tuan

Thanks both for your answers.

It would be quicker to say which fields I want to display than which ones I want to hide as I'd like a very small form with just title / category / location / start date and time / description / registration type / registration url.

I was reluctant to use nth child on such a large form where any additional field added in future would break the CSS, so I'm thinking on balance I'll do an override for this one.

Yes. For now, please implement it as override. It's very likely that I will add options to allow choosing the fields to show on submit event form simple layout. But it will take time to implement, hopefully, we will get it in version 3.8.3

Tuan