WyrdNexus

@bartgatsby Because of the complexity of moving entire paths, it can be very difficult for anyone to troubleshoot plugin conflicts.

If you review the details of Script Handle, not all optimized scripts will necessarily be included in the list. This can be for a number of factors. After a cursory review of Discus Conditional Load’s loader, it looks like much of the scripts are not included via wordpress register_script or enqueue_script. Any scripts included by circumventing those wordpress built-in function do not have a handler, and cannot be excluded.

As the Discus plugin is dynamically generating the javascript, via PHP, this conflict is unlikely to be resolved, as it would require major changes to the core of one of the plugins.

Your best bet would be to hire someone to try to tweak Speed Booster Pack for you, but I would expect that to require a minimum of 10 hours of dev.

If any of the image-paths in your css use any of the following, you may want to look at my solution:

• Full paths (starts with https://)
• Cross-domain (includes images from another site)
• Absolute path (starts with /)

Code Tweak for sbp_rebuilding_css_urls()

You can check if this applies to you by doing a view-source, and checking the paths in css declarations like: src: url( ... );

If that fix may work for you, in the url you will find a relative path to your css directory, followed by the actual path, i.e.:
Instead of src:url(https://blah.com/img.jpg);
You will have src:url(/wp-content/theme/css/https://blah.com/img.jpg);
OR
Instead of src:url(/images/img.jpg);
You will have src:url(/wp-content/theme/css//images/img.jpg);

… if you find either of the above in the css generated by Speed Booster Pack, then my fix should work for you.

@photocrati (Cais)

Thank you for your answer. I must say, your work is awesome, and deserving of great respect.

However, “protecting the user from themselves,” is not a good reason not to provide some method other than DB-Admin efforts. After all, expecting users to dive into a DB without messing everything up, is a far worse transgression than allowing them to delete their work (with a warning and option).

Whatever happened to the clean uninstall that Nextgen used to do?

There it is… finally got it.

$css = preg_replace("/url(?!\(['\"]?(data:|http:))\(['\"]?([^\/][^'\"\)]*)['\"]?\)/i","url({$css_dir}/$2)",$css);

This should resolve the issue, and avoid other plugin conflicts.
Please let me know the results of testing.

Needs more review. The regex is definitely not quite right though.