How to include assets properly (plugin)

[Wolfgang.Hartl]

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

[Wolfgang.Hartl]

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!

[Wolfgang.Hartl]

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.

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…

[matjaz]

@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.

[Wolfgang.Hartl]

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.
Thanks for your answer!!

[Wolfgang.Hartl]

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)

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?

[matjaz]

The latest PG Live 6.7.2 addresses the issues mentioned in this topic. See details below and please report any issues into their respective forum topics. Note, these features are considered Beta for now.

Pinegrow Live update log | Pinegrow Web Editor

[Pinegrow_Learner]

@Wolfgang.Hartl Hi. How are you? I am using a custom fse theme for the website. Now I am trying to use Pinegrow as a plugin. I have a empty project where I have edited the style.css file. I have selected the file as well as the folder to export. Yet I don’t see the style.css loading on the website. This css file have reset/normalize styling for all the pages.

[Wolfgang.Hartl]

Hey, I’m fine thanks!

Yeah that’s a bit tricky because normally Pinegrow exports the template files for your theme, and there you can easily add your own assets to the templates. However, in a Plugin you don’t have those template files to use, you only have Gutenberg-Blocks so Pinegrow wouldn’t know where to enqueue those styles and where not. As it was in my case, I didn’t want to enqueue those styles on the entire website, only on a specific CPT.

The mentioned “select to export” only exports the file, but doesn’t enqueue it anywhere in that case. You can check that if you have a look at the plugin-files, there it should be available.

With that being said you could try the following:

• If you have a custom FSE-Theme (which was created by you?) then the easiest way would be to add those global styles to your theme and enqueue it there

• you could enqueue it using wp_enqueue_style() in the custom.php file of your plugin!

• if you have a custom plugin-structure and only exported the blocks to a certain subfolder, you could go and enqueue it inside your plugin globally using again wp_enqueue_style()

• if you have one Gutenberg block which will appear on every page you could also add that stylesheet as dependency for that block using the block-settings.

Hope that there is at least one point which helps you!

Cheers

[Pinegrow_Learner]

Thanks for an indepth answer. It cleared all my doubts. I presume it won’t also be possible to replace woo template files via an pinegrow plugin?

[matjaz]

@Pinegrow_Learner

I presume it won’t also be possible to replace woo template files via an pinegrow plugin?

We will try to implement this for plugins, limited to using named templates in blocks with freestyle layouts.