How to include assets properly (plugin)

Hey there,

there’s one thing I always stumble about and I’m not sure how to do it properly. When I want to include my custom assets to the export I do the following (in that example with the element-styles.min.css). However, I find it quite tricky and maybe a bit buggy, could that be? As I mentioned, I’m using the plugin not the theme exports.

It works when I want to remove for example Bootstrap - it doesn’t always work with custom stylesheets. In that example here it doesn’t export the stylesheet am I doing something wrong? Do they need to be in a specific folder?

Thanks in Advance for your help!

Cheers
Wolfgang

As so often before, after writing that lines here i think i found a possible solution for it, at least I recognized a behaviour which I didn’t recognized before:

When I set it to “yes” and afterwards save the .html template again and do the export afterwards it gets included.
When I export the theme/plugin without saving the .html in between it doesn’t get exported!

Sorry for the huge amount of comments. I’ve figured out how it works now:
I also have to set the parent folders to export then everything works as expected.
Bildschirmfoto 2022-08-06 um 12.33.40

There’s only one thing left I wasn’t able to figure out:

When I want to use a custom javascript file in a Gutenberg Block (again plugin) like in the screenshot above “wcd_accordion.js” the file doesn’t get enqueued on frontend. I’ve managed now to export that javascript file too as described above and it shows up in my plugin folder. I’ve also debugged the PG_Blocks::register_block_type helper function. Until that marked line 370 the path of the javascript file is correct. Then the function called register_block_type, which i assume is a Gutenberg-internal function, get’s called. That’s the only step I wasn’t really able to debug, but I guess that $script_handle ist still correct?!

Are there any additional Steps i can take? That’s how I linked the file on the block attribute, but as the correct path get’s passed I guess that’s right there…
Bildschirmfoto 2022-08-06 um 12.40.07

2 Likes

@Wolfgang.Hartl, I found the culprit in PG helpers code:

In wp_pg_helper.php, the code:

 if (!empty($reg_args['enqueue_script'])) {
                $script_handle = 'block-script-' . md5($reg_args['enqueue_script']);
                wp_register_style($script_handle, $reg_args['enqueue_script'], array());
            }

The function should be wp_register_script, of course.

I will push this fix and other changes to PG Live today or tomorrow.

Ooh man, thank you so much! Somehow I even saw it and the way it was written there I thought to myself, that’s right and I didn’t think too much about it!

Please don’t hurry with the update, after all it’s the weekend and I can help myself at the moment by overwriting that one line. :slight_smile:
Thanks for your answer!!

Just one more question @matjaz . I just recognized that the javascript file get’s enqueued in the header (without passing the argument for it).

Although I can optimize that using an optimization plugin which moves the javascript to the footer again I would prefer to have either the option to select where to load it or to load it before the tag by default.

I’ve adapted the code, basically all you need to change is passing that last parameter in wp_enqueue_script() ($in_footer) with a Boolean-Value of True!

Another Approach would be to include enqueue scripts into the render_callback argument of the register_block_type function (found here: wp enqueue script - Load CSS/Javascript in frontend conditionally if block is used - WordPress Development Stack Exchange). That would theoretically solve the limitation of only one js and one css file for every block (in 99.99999% of all cases one would be enough for a block I guess, but just wanted to point that out too) :smiley:

I did a quick test and it didn’t work in first place, so maybe that doesn’t work anymore but probably I did something wrong!

And last but not least, is there a possibility to also get that 'editor-script' argument? I’ve also tested that and it worked for me when using the same script, if using another script you would probably have to run through the register_script process again and you would need to implement a control inside of pinegrow. That’s nothing which I consider as too important but I think it would be cool to have the ability to write the javascript also for the gutenberg-editor so you get a more live-editing experience! Maybe for any future update? :slight_smile: