Not if you use a child-theme for your actual theme, which is recommended for WP.
Custom CSS get saved in the theme folder, and as such if you use a theme without a child-theme folder it will erase all custom changes you make to your theme when it is upgraded.
Thread Starter
SaaX
(@saax)
Hi Aurovrata,
ok, that’s the issue then – I didn’t know 😉
Thanks,
SaaX
It’s a good practice to use a child theme, even if you don’t make any changes to your theme (custom functions in function.php or custom CSS file), however just in case you do then when you update the parent theme, your changes remain safe. It also means that you don’t need to back up the parent theme.
However, I will make a note to add a notice to users using custom form CSS/JS that get saved to a parent theme instead of the child theme, so this issue doesn’t come up again 🙂
Thread Starter
SaaX
(@saax)
Thanks a lot – I just didn’t have the need for a child theme for the two sites that use your plugin.
btw, did you take a look at the UI design proposals on github? Any thoughts?
Thread Starter
SaaX
(@saax)
I did at the time and it all sounds very promising – is there already something to play around with?
no, not yet, but will update the thread once there is some beta ready for testing
Thread Starter
SaaX
(@saax)
Looking forward to that – I remember that I struggled when starting to use the plugin initially. I’ve only recently fine tuned some bits and that’s when I started to use the CSS option, thus I’m only now realising that they disappear when updating the theme.
The contact and check-in forms are extremely important for our business – so I will probably setup a WP test instance.
The contact and check-in forms are extremely important for our business – so I will probably setup a WP test instance.
that’s a good practice. In fact I have been thinking about the best way to transition forms from v4 to v5 update.
v5 will likely have changes that would break current forms, so I have 2 possible paths,
– build v5 forms with its own js scripts on the front-end while loading the old scripts for forms built with previous plugin versions. The forms already have a version number associated with them, allowing to flag them accordingly. However, editing existing forms would likely need to warn the user to redesign them.
– or place a warning on the last v4.x plugin version to let user know that v5 has many changes and they need to thoroughly test their existing forms before their live site.
I think the first option is likely the simpler to cause less disruption.
