Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sage 9 - Enqueuing CSS and JS causes duplicates #62

Open
da-kicks-87 opened this issue May 4, 2021 · 6 comments
Open

Sage 9 - Enqueuing CSS and JS causes duplicates #62

da-kicks-87 opened this issue May 4, 2021 · 6 comments

Comments

@da-kicks-87
Copy link

In the block template files in the top comments, I have added the path for my main.css file for EnqueueStyle.
I do this so I can see the preview of the block on in the WP Block Editor.

I use multiple SASS files that are compiled to main.css (each .sass file represents a block). This is common practice for SASS.
When I use the browser inspector for the front website ,I see that the main.css is being enqueue for each Block I have on the page. This causes redundancy when using the the inspector when debugging the CSS.

Same issue I have with JS. I use my main.js to import other js files and I have Webpack compile it.

How do I get the block preview and not have duplicate CSS / JS enques when using SASS / Webpack?

@twinleafdev
Copy link

Having same issue. Any ideas?

@twinleafdev
Copy link

I ended up enqueueing the scripts for admin and not using the block template comments

add_action('admin_enqueue_scripts', function() { wp_enqueue_style('sage/main.css', asset_path('styles/main.css'), false, null); wp_enqueue_script('sage/main.js', asset_path('scripts/main.js'), ['jquery'], null, true); });

@da-kicks-87
Copy link
Author

I have tried that, it seems to be the step in the right direction but more CSS issues occur when doing do. The a stylings from my custom color pallet variables get applied to my WP Dashboard options. So for example the list of Post Titles in Dashboard will be pink instead of blue.

The more I use ACF Blocks the more I see how unintuitive they are versus the native WP Blocks are. It weird having to switch view modes, can't directly edit when it in the visual preview mode, "Inner Blocks" is confusing for clients, inaccurate preview etc...

I think for future projects I will go back to ACF "Flexible Content" and "Repeater" fields...

@robmeijerink
Copy link
Contributor

robmeijerink commented Jul 9, 2021

This field was not intended to put the main.css in, but rather seperate css files that only have css that this block should use. If you add multiple blocks of the same type, the assets will only load once. But if you use the same css file for different blocks, you will get duplicates.

I use this feature to include a css or js file that only has stuff the block needs, not to include the main.css here. Main.css should be your theme file, but not the block css file. Using one main.css file for all your css (including the block css) defeats the purpose of this field. (+ this is bad practice and decreases your pagespeed score)

@twinleafdev
Copy link

@da-kicks-87 I'm liking the custom blocks a lot more then repeater fields so far though I'm working on a fairly simple layout.

@da-kicks-87
Copy link
Author

@robmeijerink Thanks for this explanation.

But the main.css has global theme variables and styles that all the blocks would depend on for an accurate preview. The main.css would have to be loaded in some way. So how would one get around not duplicating that or causing conflict with the Dashboard CSS?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants