#39482 closed defect (bug) (wontfix)
wp_customize_support_script() has a javascript comment which breaks one-lined html.
Reported by: | agrabush | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.7 |
Component: | Customize | Keywords: | |
Focuses: | Cc: |
Description
In wp-includes\theme.php, line 3019, there's a javascript comment:
// The customizer requires postMessage and CORS (if the site is cross domain)
This comment is printed inline in the html. If the html is stripped of tabs and newlines before output, this comment will comment out all the following code as well.
Suggestions:
Either remove the comment, or use the "/* */" comment style, so the comment has a proper ending.
Change History (15)
#2
@
8 years ago
I've seen several sites where the primary theme developer just strip newlines and tabs from the output by str_replace, not using any plugin.
And while there's nothing "wrong" with single line comments per se, for script output designed to be inlined in the html I'd say there's merit to not having the comment appear at all.
But if someone really likes their comment there, and feel it's important, then using the other style or maybe keep the comment only in the php (not echoing it out) would certainly be a prettier solution than having to build a plugin around the issue.
#3
@
8 years ago
- Keywords reporter-feedback removed
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
Sorry this is causing you a problem, but this really is an issue with the functionality that naïvely strips new lines from the output. It's easily fixed. JSMin correctly handled inline comments when it was first written 13 years ago.
This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.
8 years ago
#7
@
8 years ago
I'm of the opinion that if you are going to publish inline scripts with comments (which I don't think is proper for production), you should at least make sure it's a closed comment.
I think the guys reviewing this just had a bad day. WordPress should be available, not just assuming any newbie trying to optimize has loads of experience. I still have people asking me to help with this every month or two.
#9
in reply to:
↑ 6
@
7 years ago
Replying to madvic:
It is so hard to change comment
//
by/*..*/
?
It's not hard, but the same issue could happen in a plugin or theme, which would be hard to track down, so in the long run I think it's better to use proper minification tools that handle JS comments correctly.
#11
follow-up:
↓ 13
@
7 years ago
- Resolution wontfix deleted
- Status changed from closed to reopened
Site speed is of top concern for me. I use HTML compression on many of my sites, but this comment causes a lot of problems. JS Console error “Uncaught SyntaxError: Unexpected end of input”. Simply removing this comment would save me a lot of headaches. Why aren't we able to fix this issue?
Comment at line 3030 of wp-includes/theme.php: “ The customizer requires postMessage and CORS (if the site is cross domain)”
#13
in reply to:
↑ 11
@
7 years ago
Replying to dylanfitzger:
Site speed is of top concern for me. I use HTML compression on many of my sites, but this comment causes a lot of problems. JS Console error “Uncaught SyntaxError: Unexpected end of input”. Simply removing this comment would save me a lot of headaches. Why aren't we able to fix this issue?
Per SergeyBiryukov:
It's not hard, but the same issue could happen in a plugin or theme, which would be hard to track down, so in the long run I think it's better to use proper minification tools that handle JS comments correctly.
Any theme or plugin that outputs a single-line comment will face the same problem. Changing the script in core will fix this one symptom but the underlying problem will remain: the HTML compressor is faulty.
@agrabush thanks for the report. What is the software you're using which has a problem with such inline comments? If it is some minifier, to me it seems that it is at fault for not first stripping out comments. There's nothing wrong with a single line
//
comment that makes it preferable to the multi-line/* ... */
comment syntax.