JS-Loading / Optimization issues with CP 1.1.x

#1

After having setup several new CP installs lately, based on 1.1.x, I’ve repeatedly ran into issues concerning JS-loading / optimization, esp. with Autoptimize and the likes.

My current “workaround” is to disable Autoptimize, as its author seems to have gone somewhat into feature creep mode anyway, but its just a temporary solution.

So the most recent install included a direct switch from WP 4.9.9 to CP 1.1.1, and the errors were so numerous the client decided to switch back, for now. There were errors about data being served with the wrong mime type in the Admin interface, which I would neglect for, but esp. the jQuery loading issues in the frontend were … NOT SO trivial. This is the second installation, specifically with 1.1.1, that had this issue.

Have there been any changes with eg. the default loading sequence of jQuery and the likes?

cu, w0lf.

#2

We haven’t made any changes to the way JS is loaded.

Do the same issues also appear on WP 4.9.12?

#3

No, that’s the thing - it doesnt surface with WP 4.9.12 … else I wouldn’t be kinda puzzled about it :confused:

Now, its not just Autoptimize breaking apart, but Query Monitor, too. That happened before already, but as I did update it in one go to the latest version, I just attributed it to some minor incompatiblity, with a fresh release and massive changes et all … but this time, I didn’t update Query Monitor (besides fixing the usual db.php symlink), and it complained heavily about jQuery issues as well :frowning:

cu, w0lf.

#4

OK, I guess we need some more specific info about the JS issues (Screenshots, error messages etc) in order to move forward.

I haven’t seen the same thing despite using Autoptimize and Query Monitor on multiple sites. Are there any other plugins or third-party code common to the sites that are experiencing these issues?

#5

So I just compared the installations: Seems also not be related to the PHP version. Thought it might be an issue with 7.3, but the installation I tested with last is on 7.2 …

But: What all sites have got in common is WooCommerce, in various version numbers, but all of them 3.x, and below or equal v3.5.8, which was the last version without massive Gutenborg redecorations.

cu, w0lf.

#6

Plugin list of the latest site with issues., ie the one indicated in the starting post:

Query Monitor: von John Blackbourn & contributors – 3.0.1
404 to 301 SEO Redirection: von Fakhri Alsadi – 1.3
Eigene Felder: von Elliot Condon – 4.4.12
ARI Adminer: von ARI Soft – 1.1.11
Autoptimize: von Frank Goossens (futtta) – 2.3.4
Broken Link Checker: von Janis Elsts
Vladimir Prelovac – 1.11.5

Contact Form 7: von Takayuki Miyoshi – 5.0.2
Cookie Notice: von dFactory – 1.2.44
CW Image Optimizer Advanced: von Fabian Wolf – 1.2
Duplicate Page: von mndpsingh287 – 2.6
FacetWP: von FacetWP
LLC – 2.9.3

Far Future Expiration Plugin: von Tips and Tricks HQ – 1.4
Force Regenerate Thumbnails: von Pedro Elsner – 2.0.6
Google Analytics Dashboard for WP (GADWP): von ExactMetrics – 5.3.5
Head, Footer and Post Injections: von Stefano Lissa – 3.1.1
Hyper Cache: von Stefano Lissa – 3.3.5
Instagram Feed: von Smash Balloon – 1.9
WPBakery Visual Composer: von Michael M - WPBakery.com – 5.0
Kirki Toolkit: von Aristeides Stathopoulos – 3.0.33
WooCommerce Load More Products: von BeRocket – 1.1.1 – Nicht getestest mit der aktiven WooCommerce-Version
MotoPress and CherryFramework-3 Integration: von MotoPress – 1.3.2
MotoPress Content Editor Lite: von MotoPress – 3.0.1
OTF Regenerate Thumbnails: von Benjamin Intal - Gambit Technologies Inc – 0.3
Quick Page/Post Redirect Plugin: von anadnet – 5.1.8
Slider Revolution: von ThemePunch – 5.4.7.3
External Links: von Denis de Bernardy & Mike Koepke – 6.8.1
Shortcodes Ultimate: von Vladimir Anokhin – 5.0.4
TablePress: von Tobias Bäthge – 1.9
Testimonials: von WooThemes – 1.5.4
Tracking Code Manager: von IntellyWP – 1.11.7 – Nicht getestest mit der aktiven WooCommerce-Version
Widget Importer & Exporter: von churchthemes.com – 1.5.3
WooCommerce: von Automattic – 3.4.3 – 3.7.1 ist verfügbar
Yoast SEO: von Team Yoast – 7.7.1
YITH Infinite Scrolling: von YITHEMES – 1.0.9

Environment:

  • PHP 7.2.23
  • MySQL 5.6
  • memory limit: 256 MB
  • WooCommerce 3.4.3
  • Strato.de shared hosting package
#7

Plugin list of the other site:

AJAX Thumbnail Rebuild: von junkcoder
ristoniinemets – 1.13

Antispam Bee: von pluginkollektiv – 2.9.1
Autoptimize: von Frank Goossens (futtta) – 2.5.1
Boxers and Swipers: von Katsushi Kawamori – 3.12
Honeypot for Contact Form 7: von Nocean – 1.14.1
Contact Form 7: von Takayuki Miyoshi – 5.1.4
Hyper Cache: von Stefano Lissa – 3.3.9
Instant Images: von Darren Cooney – 4.1.0
Post Type Switcher: von John James Jacoby – 3.2.0
Quick Bulk Post & Page Creator: von tyxla – 1.0.4
Remove WooCommerce Nag: von DevAnswers – 1.1 – Nicht getestest mit der aktiven WooCommerce-Version
Save & Import Image from URL: von basteln3rk – 0.7
UI SSL Enforcer: von Fabian Wolf – 1.3.3
Webcraftic Updates manager: von Webcraftic – 1.1.1
Checkout Field Editor for WooCommerce: von ThemeHigh – 1.3.9
WooCommerce PayPal Checkout Gateway: von WooCommerce – 1.6.17
Germanized für WooCommerce: von Vendidero – 2.3.4
Booster for WooCommerce: von Algoritmika Ltd – 4.5.1
WooCommerce PDF Invoices & Packing Slips: von Ewout Fernhout – 2.3.4
WooCommerce Product Add-ons: von WooCommerce – 3.0.16 – 3.0.17 ist verfügbar
WooCommerce: von Automattic – 3.5.8
WP Rollback: von Impress.org – 1.6

Environment:

  • PHP 7.3.11
  • MySQL 5.5.5-10.2.22-MariaDB-log
  • memory limit: 256 MB
  • WooCommerce 3.5.8
  • Schokokeks.org “shared hosting” package
#8

I’ve had issues with Autoptimize re: JS loading. The problem was that I was using the script concatenation/minification feature and forcing the JS to the footer. This ended up breaking a few things that required JS in the head (or inline.) The solution was to exclude a few scripts from the concatenation/minification and all was fine again. There are also a couple of other settings in that same section which, if misconfigured, will break the JS. Not sure if this is related to your issue, but, could well be. Here’s what my JS options look like; I’m on Autoptimize 2.4.4 and it’s working great on my CP 1.1.1 site.

image
image.png784×529 22 KB

1 Like
#9

That could well be the problem. I’ve run into the same issue several times.

@fwolf would it be worth trying a slightly older version of Autoptimize? Also, it might be worth clearing the Autoptimize cache manually as I’ve found that the “Delete Cache” feature doesn’t always actually clear the cache. one last thing, you could also try increasing available RAM if your host allows it as you’ve got a fair number of plugins on each site.

#10

Already tried that - seemed to make no difference. Only disabling it helped :frowning:

That was my first thought, with the migrated site, too. But the other site is a clean, directly built from scratch. CP site, which also does not have file access issues (schokokeks.org is a really reliable, decent … hm … service provider) …

256 MB should be quite enough … even with the older, migrated site. One thing to note: The issue only surfaces really harsh when not logged in - and although my first guess was: Autoptimize is chumping up the admin scripts, although its configured differently … but that wasnt the case, either.

The other part is the issue with Query Monitor - even with some serious downgrades (and Autoptimize disabled), the issues continued to appear.

But on the other hand: wp-devil.de is also a CP 1.1.1 install, which is set up from scratch, but started with CP 1.0, also uses Autoptimize and Query Monitor, but does not have any of these issues … :confused: :thinking: :anguished:

cu, w0lf.

#11

I agree 256MB should be enough but, on occasion, I have needed to increase to 384MB especially when using themes with page builders.

Autoptimize has a “Also optimise for logged in users?” setting. If this is unchecked, then scripts are not minified or combined.

Regarding Query Monitor, according to the FAQ:

Query Monitor’s memory usage typically accounts for around 10% of the total memory used to generate the page.

I think it would be worth increasing the RAM (if you’re able to) just to rule that out.

And also check to see if you’re getting any PHP errors. in debug.log or error_log or however your system is set up.

1 Like