WordPress.org

Make WordPress Core

Changes between Version 2 and Version 3 of Ticket #26886, comment 11


Ignore:
Timestamp:
02/19/2015 04:53:23 PM (5 years ago)
Author:
kraterdesign
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #26886, comment 11

    v2 v3  
    66> 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.
    77
    8 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.
     8Yes, 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. I didn't realize this myself until it was pointed out to me by dd32. So it's never an issue and the 128 limit is just for backwards compatibility reasons with regards to the HTTP protocol AFAIK.
    99
    1010The way this is done, as far as the successfully loading of scripts goes, it wouldn't matter if it was cut off at 12, 37 or 128. Since the query strings are merged before the script concatenator does anything with the script names, it would always work.