You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 10, 2025. It is now read-only.
This has yet to be reproduced locally, the bug is described in these pages:
http://wordpress.org/support/topic/35-rc3-new-media-uploader-doesnt-work-with-go
ogle-mod_pagespeed <-- more illegal character. The file has a BOM in it,
perhaps MPS is serving something other than UTF-8? Perhaps we need to
propagate the charset?
https://groups.google.com/forum/#!msg/mod-pagespeed-discuss/r6lcoseTJks/IrQD04sQ
0PcJ <-- add media button didn't pop up the iframe overlay. Firebug showed a
malformed unicode character escape sequence but I have no idea what file it was
in.
http://wordpress.org/support/topic/add-media-button-stopped-working
http://wordpress.org/support/topic/yet-another-35-add-media-button-failure
http://osdir.com/ml/mod_pagespeed/2011-04/msg00009.html
https://groups.google.com/forum/?fromgroups=#!topic/mod-pagespeed-discuss/XpRASA
KbELA
The symptom is that some javascript does not run on people's pages such as the
add media page in the panel. When rewrite_javascript is disabled it works fine.
An alternate temporary fix is to disable wordpress js concatenation.
What I believe is happening is that the concatenated js has UTF-8 BOM markers
in the middle (at the insertion point of a new file) and mod_pagespeed is
somehow not propagating the correct UTF-8 charset. When the BOM markers are
seen with the wrong given charset, syntax errors are produced.
When wordpress concatenation is disabled, the BOMs would be in their proper
position, at the beginning of the individual js files, which might help the
parser even if mod_pagespeed fails to propagate the charset correctly.
Original issue reported on code.google.com by jkar...@google.com on 17 Apr 2013 at 5:48