Hendrik Lersch

That’s right. When you change your theme or plugins, it may happen, that some scripts or styles are not used anymore.

Nevertheless they will still appear in the lists, with a notice, that they can not found anymore (after update). You can left it there in case you activate the plugin again or use the old theme again or you can delete the entries.

Updating the lists via the button will not remove anything, only add new stuff or update existing stuff. If you click on “clear lists” the plugin database table will be cleared completely, so you can start clean.

Ok, i have done a couple of tests and you’re right. Page Speed Insights says that some CSS files are still “render-blocking”, they’re not saying that they are specifically in the header.

But anyway, the stylesheets were in fact all in the footer. i have checked it. So i think it’s more a problem of the page speed check, because it’s not a very common practice to move stylesheets into the footer of a site (besides it’s legit since HTML 5). On this page you can see, that google don’t recommend to move CSS into footer, rather than include the “above the fold” CSS inline into the code, so no file must be loaded (and block html rendering) for this part of the stylesheet.

I don’t really know, why google complain about these styles, when they were all in the footer of the site, because they were.. and not blocking anything. If you move all styles to the footer you can see it at page load, that the site appears unstyled for a short moment.

In my opinion it’s a very unrealistic suggestion from google and they also don’t follow it ??

Regarding the order of scripts, you only can control it by the order of the wp_enqueue_xxx functions, so if its later in the code, it will be print out later. The fourth parameter lets you only specify one or more dependencys that are needed in order to run the script. WordPress then makes an array of handles and sort it automatically, so any dependency script is printed above its dependents. The order of the dependents is irrelevant. But you can set one dependent to be the dependency of an other dependent.

But the main purpose is to set scripts that have to loaded first, i.e. jquery above any jquery plugin script.

I don’t plan to support any hardcoded inline scripts or styles. They should always be included the right way through the wordpress functions. Otherwise my plugin can’t handle it. Any plugin or theme developers should always use this functions like its mentioned in the codex.

Hello Karl,

are you sure the CSS files are not in the footer? Have you checked the HTML-code by yourself? I’ve never noticed anything like that in my tests. All files were correctly in the footer. Or in the header, depends on the settings.
Which tool have you used to check it?

Regarding the order of the files, it’s not necessary to change it. WordPress takes care that all scripts & styles will print out in the correct order, so that every master-file is above its dependents. You don’t have to be worry about that.

You may have mentioned that if you move a script or style from the head to the footer, all dependent files will move to. But if you the move a dependent script back to the header, the dependency of this script will also print out in the header. This is done by wordpress to make sure all scripts are functioning. But in the plugin list the dependency will still be listed in the footer.

Also the order within the plugin lists may differ from the print-order, because it’s the order before wordpress sorts them. I understand that this can be confusing. The only way to change the order right now, is to change the dependencies settings in the wp_enqueue_script or wp_enqueue_style functions. It’s likely that i make an option for that in a future version.

Inline Scripts or CSS can only be handled, if its correctly included via the functions wp_add_inline_script or wp_add_inline_style. Not if it’s hardcoded. I will implement an option to add inline code to any file.

I hope i could help you with some of your problems. Thanks for your kind words, that motivates a lot. ??

That should be the case actually. Anyone lower than an admin, shouldn’t even see the menu item, nor he should be able to call the plugin sites directly via URL.

Have you experienced anything like that?

Thats a difficult thing. I think the best way would be to use a third-party solution like mobiledetect, which is also used by the WP mobile edition plugin.

Since PHP cannot sraping screen sizes, any workaround would be very laborious, like the one from your link.

But the overall idea is good. I will look into it.. ??

I’m sorry, that i can’t help you. I don’t wanna exclude that i have overlooked something in the code, but it could even be an individual problem with your page configuration.

Maybe the problem fixes itself with one of the following releases. I will further improve the rules-system and assets enqueue process.

Could you please provide me more informations?

Which Buddyboss theme and which version of geodirectory plugin are you using?
Unfortunately i can’t find a file called “selectboxes.js” in the whole geodirectory plugin with the latest version.

And i can’t find a file with this name in the buddyboss themes i tested so far.

Could you also tell me, which script is not loaded (in HTML sourcecode) on that specific page, which is loaded up to 0.2.2 and what rules you are using for this script?

I will try to improve the whole processing of scripts but at the moment i can’t see any problem with the code.

Have you tried a reset of all lists? This should actually dont be necessary, but maybe do the trick. But you lost all your settings, which may be annoying.

Thanks, update is on the way. It not affects the functioning of the plugin but from now on i will do more tests, before i publish a new version.

Sry, but moving stylesheets to the bottom of a site is not possible, because wordpress doesn’t allow this at the moment (no group parameter in wp_enqueue_styles). I can only test if i can set the group parameter manually..

But it’s a lot harder to improve CSS in the way like improving JS, with all the “above the fold” and “critical or uncritical css” stuff. If you only move all CSS to the bottom, you have an unstyled site while rendering. That’s not very pretty ??
You have to separate the critical CSS and include it in the header (as file or inline). That can be tricky.

It’s even possible to load CSS async, but thats an other story..^^

wp-embed is a special case. I know about it.
The problem here is, that wordpress enqueues this file not like their other default files, namely directly through “wp_head” hook as far as i see.

I will try to find a solution..

Problem is solved now. Please update to the latest version.

Yes, like you have mentioned, this requires a per page control of scripts and styles.
This is actually not possible, but planned for a future release. ??

Hi, thanks for this “extensive” suggestion list. I will go through it step by step ??

change “unequal” to “not equal”

Yeah, maybe you have noticed, english is not my native language. i will change that in the next version ??

allow the order of js and css to be changed

I have think of it and will check it out, when i change the script-list to allow a better overview of the dependencys. maybe drag&drop..

allow multi selection of pages / posts / custom post types

Please, could you explain that a little more? i don’t get it.

allow entering of url for pages that are dynamic such as woocommervce checkout etc

Yes, vou’ve probably noticed, that only globally enqueued scripts are processed by this plugin. This has the simple reason, that wordpress register, enqueue and print scripts on the fly with each page load. So theres only two ways: Check only global scripts, e.g. from the frontpage of a site or check it on a per page basis and make it configurable via admin bar etc. Maybe i will make the second way as an additional feature.

allow own groups so that specific css / js can be grouped and then allow a group to have option of minify / combine

This will definitely be included.

enable change of url path for css / js so that they can be loaded from different CDN servers

Instead of changing the url of a registered script, it’s maybe better to give the user the ability to add custom scripts via backend and then deactivate the original script. This is already on my to-do list.

enable for admin backend pages / paths so css / js can be optimized / removed when not needed in backend

You mean the same list, but for backend scripts? Yes, that should be not a big problem. but this has the potential to break the admin panel, what makes it more complicated to resolve an issue, if you can’t disable plugins anymore etc.

admin backend option to enable / disable changes for current user

Current user means what? Because every logged in user is a current user ??
Or you mean whitelisting / blacklisting of user id’s?

ability to alter http headers for js / css eg expiry, cache, etag etc, also ability to reset cache settings for when js / css are updated

Will check it out..

You have the potential to have a great plugin that could help optimize wordpress content which you could sell with extra features. Good luck.

Thank you! I will try to improve it as best as i can to make it the (hopefully) best all in one solution for script handling for wordpress. We will see.. ??

Thanks for your feedback.

jquery migrate isn’t in the list, because i have grouped the jquery-core and jquery-migrate handles into one jquery handle, like wordpress did it itself internally.

They always have to moved together, otherwise it leads to trouble^^ Maybe i should make it clearer in the list.

Also i have take a look into the woocommerce repo. They enqueue their scripts mostly only on pages where they were needed. But WP Script Optimizer can actually only handle globally included scripts. That is in the nature of wordpress, because all scripts are registered, enqueued and printed on the fly with each page load. Unfortunately there is no persistent central database table, that includes all scripts of all pages.

So i currently can only check the scripts on the frontpage of a site. The only other way is a per page selection of scripts. I have considered that as an additional feature for scripts or styles that are not globally enqueued, e.g. via the admin bar or backend page edit window. But i wasn’t sure, if this is a much needed feature, because the main purpose of this plugin should be in fact, to configure global scripts, that are not needed on every page.

When it comes to minify/encrypt/concatenate, that will be of course selectable for each file or group of files.

Haha facepalm^^ I really didn’t notice that. Thank you very much ??
But i still can’t change anything, because of the problem from my last sentence in the first post.

I have sent an email to [email protected]. Hopefully they can help. This is a mistake, i won’t make twice^^