Compile and cache all CSS and JS

The compiler is my favorite feature of Beans.

Would it be possible to compile and enqueue also third party JS and CSS files? I mean from plugins like jetpack or akismet.


Hi Jochen,

When Compile all WordPress styles is enabled, all the styles enqueued properly using wp_enqueue_styles() will be automatically compiled in the global Beans CSS file (third party plugins included).

When Compile all WordPress scripts is enabled, all the scripts enqueued properly using wp_enqueue_script will be automatically compiled in global Beans JS file (third party plugins included).

Some themes and plugins (and WP Core in some cases), enqueue assets differently "the wrong way" which will not be included in the compiler.

If you want to add custom assets to a compiler, please refer to this article. The uikit compiler id is always present so you can use that id do add files to that compiler.

Have fun,

Hey, I found the following code in the Mailchimp for WP plugin:

wp_enqueue_script( 'mc4wp-ajax-forms', $this->plugin->url( '/assets/js/ajax-forms' . $suffix ), array( 'mc4wp-forms-api' ), $this->plugin->version(), true );
wp_enqueue_script( 'mc4wp-forms-api', MC4WP_PLUGIN_URL . 'assets/js/forms-api'.  $this->filename_suffix .'.js', array(), MC4WP_VERSION, true );

I have also asked the developer:

Hi Jochen, Yes, the plugin does use the default WP function to enqueue scripts. It does so in a smart way though, only loading the scripts on pages where they are actually needed and at the bottom of the page, to make sure the page loads as fast as possible for your visitors (visibly). However, the Beans framework should be able to deal with that! Hope that helps. If not, let me know!

Do you have an idea, why the compiler does not include the files forms-api.min.js and ajax-forms.min.js?

Hey Jochen,

I looked into their code and here is how they are enqueueing their assets:

add_action( 'wp_enqueue_scripts', array( $this, 'load_stylesheets' ) );
add_action( 'mc4wp_output_form', array( $this, 'load_scripts' ) );

You see that the styles are "properly" enqueued which the scripts aren't. I understand why they are doing so but they could still use wp_enqueue_scripts action and check if the content contains their form shortcode to conditionally load their script (and their style which they are not doing at the moment, they are loading style on every page).

Beans compiler can indeed not cater for scripts enqueued using custom hook such as mc4wp_output_form as there is not way to guess it πŸ˜‰ You will notice if you set a styling for the form in their options and enable style compiling in Beans Settings, it will be compiled in the main stylesheet as expected.


I got answer from the plugin developer:

The trouble with the proposed approach is that there is no way for the plugin to know if a form is outputted on the current page as people can output forms in all kinds of ways, using a PHP function, WordPress widgets, shortcodes etc. Stylesheets have to live in the area of a site but scripts can be loaded at any point in the document without an issue, so the plugin is utilising this to the fullest.

I'm sorry but we can't implement their recommendation in the plugin, as that would mean a lot of unnecessary script loads. If I were them, I would build the compiler in such a way that it doesn't use WordPress hooks but simply parses the resulting HTML from any page. This would allow them to work with any way of loading scripts on a site. Alternatively they should be checking the enqueued scripts at a later time in the WP process, such as when the page finished loading. They can simply use the global $wp_scripts object to see which scripts have been enqueued (this would also work with our scripts, and many many other plugin that load their scripts in the footer).

Hey Jochen,

I understand why they are doing so and here there isn't much more we can do on both sides.

If I were them, I would build the compiler in such a way that it doesn't use WordPress hooks but simply parses the resulting HTML from any page.

Beans is not a caching plugin and we do not grab the entire HTML to cache it so we simply can't do that. Plugins like WP Rocket aim to do such things so you could look into that. Doing such page caching would never be in Beans Core as it is plugins territory. Sorry I couldn't help further on this but this is really out of Beans scope πŸ™


Write a reply

Login or register to write a reply, it's free!