Sage: Sage 9 beta - Plugin scripts not enqueued?

[lengcai]

Submit a feature request or bug report

• [x] I've read the guidelines for Contributing to Roots Projects
• [ ] This is a feature request
• [x] This is a bug report
• [x] This request isn't a duplicate of an existing issue
• [x] I've read the docs and NPM Debugging Guidelines post and followed them (if applicable)
• [x] This is not a personal support request that should be posted on the Roots Discourse forums

---

What is the current behavior?

I can confirm the same problem encountered and discussed in the discourse below. I'm using the code from latest branch:

https://discourse.roots.io/t/sage-9-plugin-scripts-not-enqueued/8618

In my case, I am having problem with Master Slider plugin which try to enqueue_script whenever a it's shortcode is embedded in page. I can confirmed the Master Slider plugin does invoked the wp_enqueue_script, but the script is not included in the final rendered result.

The script appear at the bottom of the html when I switches to other theme.

What is the expected or desired behavior?

Would expect the plugin script to be included at the bottom of the html.

---

Bug report

Please provide steps to reproduce, including full log output:

1. Generate sage theme using,
   $ composer create-project roots/sage your-theme-name dev-master
2. Install and activate this theme.
3. Install Master Slider plugin
4. Create a simple slider using the Master Slider
5. Paste the shortcode into a newly created page.
6. View the page, the slider doesn't show up as it's javascripts not enqueued

Please describe your local environment:

WordPress version: 4.7.3

OS: Linux Cent OS 6.7

NPM/Node version: v6.10.0

Where did the bug happen? Development or remote servers?

Both Development & remote servers

Is there a related Discourse thread or were any utilized (please link them)?

https://discourse.roots.io/t/sage-9-plugin-scripts-not-enqueued/8618

---

Feature Request

Please provide use cases for changing the current behavior:

X

Other relevant information:

X

[astappiev]

I have the same problem with "WPBakery Visual Composer" and "Visual Composer Extensions Addon" plugins.

Base scripts and styles from "WPBakery Visual Composer" loaded correctly, but those which loads additionally for some shortcoders are missing.
For "Visual Composer Extensions Addon" I don't see any scripts or styles that are loaded, because all of them should be loaded only when shortcode is used somewhere on the page.
When I switched to another theme without sage, everything works fine.

I'm using almost clean version of sage from master (I changed only some styles).

[Treenity]

Same probleme here with custom plugin based on Wordpress plugin boilerplate.
Scritps are registered in wp_enqueue_scripts filter, then enqueued in shortcode.

they don't appear on the page.

Some informations :
var_dump of wp_script in head.blade.php return registered scripts as expected, but enqueue like to be skipped, maybe it's a blade problem due to the order of the render step.

[creatingusernamesgivemeanxiety]

I've experienced this with two plugins in Sage 9 beta; WooCommerce and Elementor. I manually had to enqueue WooCommerce's add-to-cart-variation.js to get product variations to work frontend. It's the same with Elementor's jquery-numerator.min.js. Disable all other plugins did not work. Switch theme however, did.

[JulienMelissas]

I'm not able to reproduce this. Are any of you having issues using Soil or not using Soil? Would be great help debug. Thanks!

[astappiev]

I have tried to comment all this lines below and it didn't help. Using Sage 8 with Soil I don't have the issue.

add_theme_support('soil-clean-up');
add_theme_support('soil-jquery-cdn');
add_theme_support('soil-nav-walker');
add_theme_support('soil-nice-search');
add_theme_support('soil-relative-urls');

[creatingusernamesgivemeanxiety]

I'm using Sage 9. Soil didn't do any difference. I have project with the issue. I could pack it with All-In-One-WP and send to you if you like to investigate it further. @JulienMelissas

[MWDelaney]

If it's helpful, I can report this problem with WooCommerce Composite Products, too. The scripts and styles get registered (so I can enqueue them myself by handle) but whatever is supposed to be enqueueing them in the plugin isn't firing.

I have WooCommerce Composite Products in a private GitHub repo that I can invite Roots team members to view if that's useful for tracking down the problem.

[JulienMelissas]

Thanks to all for providing some more details. I really have wanted to look into this to see if I can figure out what it is (I'll be honest we don't use a lot of plugins on our platform, and I haven't experienced any of this yet), but I've had a deadline all week. I'm going to try to take a look this weekend if I can. I'm wondering if there's something to do with the way these plugins enqueue or maybe some weird naming issue. Not sure where to start haha. I'll let y'll know if I need some plugin access, thanks for the offers 😄

[MWDelaney]

I mentioned this to Ben on Twitter, but I think part of the problem, at least with WooCommerce Composite Products, is that the enqueue is happening mid-page. I found where the relevant enqueue call is being made, and echoed some text right next to it; the echo occurs below the product title, not in the header or footer.

That's some pretty lousy plugin-writing practice right there.

Hopefully this is useful info?

[ghost]

I am having the same issue with Page Builder plugin where the script is not loaded at the bottom of the page. I just tested with another theme and the following script is not loaded when using Sage 9

script type='text/javascript'>
/* <![CDATA[ */
var panelsStyles = {"fullContainer":"body"};
/* ]]> */
</script>
<script src="/app/plugins/siteorigin-panels/js/styling-24.min.js?ver=2.4.25"></script>

[wgroenewold]

@MWDelaney Indeed. I think these plugins need some love and maybe some kind of boilerplate for devs to contact the author with these suggestions.

[MWDelaney]

Surely contacting the authors is a best practice, but when the problem is localized to our theme and the plugin works everywhere else, the incentive isn't super strong to fix it.

If there's a way to mitigate for these bad practices in Sage, I think we need to look at that, too.

[kimhf]

The issue is that the code does not seem to execute in the same order as it is with other themes. The result is issues with scripts added indirectly from a template. Woocommerce calls
wp_enqueue_script( 'wc-add-to-cart-variation' ); before the script later is registered in the wp_enqueue_scripts action. Seems to me that this is caused by blade. After some trail and error, replacing
@include('partials.head')
width
@yield('app_head_partial', App\Template('partials.head'))
in app.blade.php and then

@section('app_head_partial')
    @include('partials.head')
@endsection

in single-product.blade.php seems to solves it for this template. But this "solution" needs to be manually added on all templates where this problem shows up.

[QWp6t]

I'm sure we can come up with a fix. I've just been busy lately. I'm expecting next month to be a little more chill and I'll hopefully be able to finish up what's left for Sage 9.

PRs are also always welcome.

To be clear, I don't think it's fair to blame Blade or Sage. This is the fault of plugin developers who are doing things wrong. But I'm willing to work on resolving it since this bad practice is so common.

[kimhf]

Could something like this work? (In filters.php)

/**
 * Render page using Blade
 */
add_filter('template_include', function ($template) {
    remove_action('wp_head', 'wp_enqueue_scripts', 1);
    wp_enqueue_scripts();
    $data = collect(get_body_class())->reduce(function ($data, $class) use ($template) {
        return apply_filters("sage/template/{$class}/data", $data, $template);
    }, []);
    echo template($template, $data);
    // Return a blank file to make WordPress happy
    return get_theme_file_path('index.php');
}, PHP_INT_MAX);

I think this could solve it for some plugins, but maybe not those who load their own templates like woocommerce. It works in my custom woocommerce template loader, but will not work with the <?php echo App\Template('woocommerce'); ?> solution.

Maybe this would be better? (In helpers.php)

/**
 * @param string $file
 * @param array $data
 * @return string
 */
function template($file, $data = [])
{
    if (remove_action('wp_head', 'wp_enqueue_scripts', 1)) {
        wp_enqueue_scripts();
    }

    return sage('blade')->render($file, $data);
}

[MWDelaney]

@Kimers second solution seems to work for me, at least for a few random Gravity Forms addons.

[corbanb]

/**
 * Render page using Blade
 */
add_filter('template_include', function ($template) {
    remove_action('wp_head', 'wp_enqueue_scripts', 1);
    wp_enqueue_scripts();
    $data = collect(get_body_class())->reduce(function ($data, $class) use ($template) {
        return apply_filters("sage/template/{$class}/data", $data, $template);
    }, []);
    echo template($template, $data);
    // Return a blank file to make WordPress happy
    return get_theme_file_path('index.php');
}, PHP_INT_MAX);

Notcing this is being a big bottle neck for performance when running load tests and seeing newrelic results. Its taking the loggest of any method FYI.

[iljamm]

@Kimers seconding @MWDelaney, the second patch for helpers.php fixed an issue for me with woocommerce's mix and match plugin.

[xeiter]

Thank you @Kimers! The second patch for helpers.php fixed the issue for me too. Subscribing to this thread.

[renaem]

@Kimers just letting you know that I found this and your second solution fixed this for me as well, using the Galleries by Angie Makes (wc-gallery) plugin! THANK YOU!!

[gsusI]

FYI, problem still happens in the latest stable release of Sage.

In my case the conflict was with Elementor, @kimhf's second solved the issue. Thanks for that.