[wp-trac] [WordPress Trac] #26886: wp_enqueue_script doesn't load all scripts
WordPress Trac
noreply at wordpress.org
Thu Feb 19 16:49:55 UTC 2015
#26886: wp_enqueue_script doesn't load all scripts
-------------------------------+------------------------------
Reporter: alfredocubitos | Owner:
Type: defect (bug) | Status: reopened
Priority: normal | Milestone: Awaiting Review
Component: Script Loader | Version: 3.8
Severity: normal | Resolution:
Keywords: reporter-feedback | Focuses:
-------------------------------+------------------------------
Comment (by kraterdesign):
Replying to [comment:10 alturic]:
> So, WP itself conc's it at 128 chars. It's cutting script names off in
the middle of the script name, and you're chalking it up to FireBug or
some non-WordPress issue? WP >IS< the one conc'ing it at 128 chars it's
nothing BUT WP's problem.
>
> As for it being a plugin issue. I mean, unless a WP plugin can alter WP
Core functionality (I have no idea? It'd be kinda crazy to allow a plugin
to do so though) the only thing you can blame on the plugin is calling
scripts.
>
> Curious what you're thoughts are on at though, simply telling WP to by-
pass conc'ing isn't a fix nor should it be expected. Like I said, I simply
changed it from 128 to 3000 (arbitrary number) and all worked well I just
don't know what side-effects will happen from that.
Yes, it's split at 128 chars to form the url that's enqueued and output
into HTML. But when "/wp-admin/load-scripts.php?....etc" with the split
query strings is called by the browser, it first reassembles the split
string into one long string and only then loads the scripts from it. So
it's never an issue and the 128 limit is just for backwards compatibility
reasons with regards to the HTTP protocol AFAIK. I didn't realize this
myself until it was pointed out to me by dd32.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/26886#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list