aurovrata / cf7-grid-layout

A WordPress plugin extension for Contact Form 7 to design responsive grid-layout forms.
https://wordpress.org/plugins/cf7-grid-layout/
GNU General Public License v2.0
6 stars 7 forks source link

support nice-select and select2 in default cf7 form #13

Closed netzgestaltung closed 4 years ago

netzgestaltung commented 4 years ago

as bespoken here: https://wordpress.org/support/topic/select2-and-neice-select-not-loaded-on-frontend/

netzgestaltung commented 4 years ago

i didnt see that comment ;-)

aurovrata commented 4 years ago

So I had a look through your changes, and some are good (in the js scripts) but others I would like to better handle in the admin.

For example, searching for strings in the form output (prior to form shortcode being printed to screen) is fine for small forms but slow for large (several 100s lines of html code) forms.

I have been wanting to improve the efficiency/speed of js script files required for forms. In order to achieve this, my intention was to flag the need for various scripts at the time of saving a form (in the js script prior to form update/publish).

I have been looking at Minify, a php lib used by W3 Total Cache plugin to build static js and css bundles. I am thinking to use this to build specific js/css bundles for each form when they are saved so that a single js script is loaded when the file form is loaded on the front-end.

this would also take care of non-grid designed forms

what do you think?

aurovrata commented 4 years ago

So finally, I made a number of changes on the server (admin) side of the code to handle the logic of script loading more efficiently at the time of saving the form to the DB. The front-end has also been changed to load the scripts required, and the select2, nice-select, benchmark and validation for non-grid forms. This was released in v3.0.0.

Please test it and let me know if it works.

netzgestaltung commented 4 years ago

thanks for that!

my goal was to modify as less as possible because i dont wanted to break something. but i agree that its better to have any other method then looking into the html.

i will test it in the next week

netzgestaltung commented 4 years ago

i think that having one or "not much" single files, no matter what css or js or static file, is better.

i researched to that topic a lot over time, my conclusion was that it takes some longer loading on the first run but then its cached in the browser. on the next pages it makes it much faster because you have less http requests, so i always would pack all js in one large minified file.

this is then interessting when working with libs like jquery, modernizr - i put jquery and all used plugins together in one file.

for custom js files i would neither minify nore put it together with other scripts. so in the end i come up mostly with: 2 larger minified files and one smaller non minified js file.

but that also depends on the task so i always decide that every single time when having new tasks.

aurovrata commented 4 years ago

Ya, I was thinking to load un-minified custom/plugin scripts in WP_DEBUG mode and bundled/minified other wise.

While doing some more reading around the js minify plugin I realised that is it used in a number of caching plugin (W3 Total being the most widely used), so now I am thinking that instead of minifying the js bundle, maybe just bundling all the js files into a single file (plugin & custom script only in non-debug mode) and letting caching plugins do the minifyng/compressing.

Question: have you used any php based bundlers? Minify is actually quite large and does so much more than just bundling. Found JS & CSS Bundler and Minit.

netzgestaltung commented 4 years ago

meanwhile i tested w3 total cache(https://www.alphabetisierung.at) which has a module to minify the files cached (as you mentioned), so i think the option is available at user side.

i only used the yui-compressor on a company server or used online services for compressing (also yui based)

aurovrata commented 4 years ago

nice. Let me know if you find anything else.

My current roadmap for the plugin is s concentrate on internal improvement in v3. I have re-written the back-end editor to better load scripts, and once I have some time I will explore bundling in earnest. v3.0 also has improved roles/capabilities management, something the original cf7 plugin does not handle properly.

I am going to make some online videos on how to use the plugin to its full potential because quite a of questions on the support forum are about documentation and the lack of it.

In the long-term i would like to separate the plugin core and the additional functionality (UI editor, tabs/tables, dynamic dropdown, benchmark tag) into modules, so as to make it easier to manage.

I also plan to make a module to get rid of the cf7 scripts.js file altogether which is not very efficient and replace it with VueJS to enable client-side validation handling. This would allow cf7 forms to be integrated into reactive themes, something that is currently not possible but would also make form submission and validation extremely fast.