Make WordPress Core

Opened 4 years ago

Last modified 13 days ago

#22037 new defect (bug)

Customizer: Live preview fetches page but does not display

Reported by: marcoliverteschke Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.4.2
Component: Customize Keywords: reporter-feedback
Focuses: javascript Cc:


I just set-up a plain installation of 3.4.2. Configured it for multisite use. Set-up two sites, both working fine.

When going into a sites Appearance settings to customize the theme (TwentyEleven), the Customizer shows the control panel on the left, but the preview remains blank.

Firebug shows no Javascript errors.

It also shows, that a POST request is sent to fetch the front page and that the page is actually returned in the response. It appears the response is just not added to the right-hand preview area.

Change History (21)

#2 @wdfee
4 years ago

  • Cc wdfee added

same problem here and discussed on http://wordpress.org/support/topic/customizelive-preview-not-working
The related #21235 doesn't match it in detail. I'm also on a multisite install, but it doesn't work on mainsite, too.
I have two completely equal installations, one on local test server and one on remote live server. The local one works perfectly! But on remote everything is gone.

Server differences:
Local: Apache/2.2.22, PHP/5.3.15
Remote: Apache/2.2.21, PHP/5.3.10
Both installations WP 3.4.2, tested with different themes, including Twenty Eleven, all plugins deactivated.

As far as I could find out, the scripts are not enqueued completely.
If I comment this action hook in class-wp-customize-manager.php the result on my local running install is the same as on the blank remote. So if you others want to know what our problem is, comment out this:

add_action( 'customize_controls_enqueue_scripts', array( $this, 'enqueue_control_scripts' ) );

I haven't seen this way of enqueuing scripts like in this function in WordPress before:

public function enqueue_control_scripts() {
	foreach ( $this->controls as $control ) {

I didn't get the logic behind it yet...

#3 @wdfee
4 years ago

if I use an own theme with some controls calling new WP_Customize_Color_Control, I got a javascript error in firebug with WP 3.4.2:

TypeError: c.farbtastic is not a function

On my subsites I have more issues even on my local install.
After upgrading to WP 3.5-beta2 this error is gone and customizer on subsites is working.
But I don't want to upload the beta to my live site yet. There are other issues coming up with this beta, specially for multisite and domain mapping.
Last night I gave it a try, did the upgrade on remote - the problem of this thread (blank preview) persists - and downgraded remote again.

#4 @wdfee
4 years ago

I guess I'm the only one here who can compare directly: on my local site the customizer works, on remote it is blank. Like marcoliverteschke wrote, the POST is there, with firebug you can even see changes made by customizer in net or console panel -> POST -> HTML. It seems that just the iframe is not appended to the customizer-preview div.
using rev 22313 now (both on remote an local) with script debug on and theme twenty twelve on multisite main site.

I'm no expert in js script analysing - so maybe the developers here could give me a hint where to look at?
firebug console -> timeline confuses me a bit, so I used Safari-> web developer -> timeline:

remote network requests stop at after type: XHR
on local the next request after that would be type: Document about:blank

js requests stop on remote after 3times event "readystatechange" in jquery.js line 2
on local next js request would be script jquery.js

Uuh, wait, it is working on Windows7 / Google Chrome Browser!
So it seems to be a combination between browser specific and server.
In Windows7 / IE 9 it doesn't work and the URL in the browser address line stays on .../wp-admin/themes.php# instead of .../wp-admin/customize.php
With Mac 10.7.5 / Safari and Firefox it works on local but not on remote.

I could send you login details per PN or email for the remote site, if you want to test.

#5 @wdfee
4 years ago

  • Keywords needs-testing added

I think it's a jquery issue because it happens on a jquery request. I uploaded the uncompressed jquery 1.8.2 now, so you could better check breakpoints.

#6 @wdfee
4 years ago

Google Chrome on Mac is working, too.
IE9 on Windows the same as Safari 6.0.1 and Firefox 16.0.2 on Mac: Displays preview on local site, but not on remote site.

trying to get more out of Google Chromes Developer Panel -> Network with my info from above.

the critical step ist between

Name http://mydomain.com | Method POST | Status 200 OK | Type text/html | Initiator jquery.js:8416
Name about:blank | Method GET | Status Success | Type text/html | Initiator jquery.js:5766

It's the only step where Status is no number code but "Success" - maybe this is not compatible with all browsers?
Line 8416 is

xhr.send( ( s.hasContent && s.data ) || null );

before this there are browser specific adjustments, maybe there could also be something wrong.
Line 5766 is the step where the child node should be appended.

append: function() {
	return this.domManip(arguments, true, function( elem ) {
		if ( this.nodeType === 1 || this.nodeType === 11 ) {
			this.appendChild( elem );

#7 @wdfee
4 years ago

  • Keywords needs-refresh needs-patch added
  • Summary changed from Live preview fetches page but does not display to Customizer: Live preview fetches page but does not display

ok, I've found it! Now I need you developers to find the right solution:
it's in the /wp-admin/js/customize-controls.js line 363-373:

// Check for a signature in the request.
index = response.lastIndexOf( signature );
if ( -1 === index || index < response.lastIndexOf('</html>') ) {
	deferred.rejectWith( self, [ 'unsigned' ] );

// Strip the signature from the request.
response = response.slice( 0, index ) + response.slice( index + signature.length );

// Create the iframe and inject the html content.
self.iframe = $('<iframe />').appendTo( self.container );

You see, I've commented out the return because then it works in all mentioned browsers. I checked the signature variable, it's undefined, but I didn't had the time yet to figure out why and where it would be defined. This is the return that stops the customizer preview from displaying and just stops processing without errors.

#8 @wdfee
4 years ago

  • Keywords has-patch added; needs-patch removed

ok, found this, too. in /wp-includes/class-wp-customize-manager.php you defined the signature and added it with this action hook in line 336:

add_action( 'shutdown', array( $this, 'customize_preview_signature' ), 1000 );

If it's added to shutdown, the signature is posted, but not part of response, so the index is undefined. I changed it to

add_action( 'wp_footer', array( $this, 'customize_preview_signature' ), 1000 );

and similarly changed it on the remove_action hook on line 417. Now the signature variable is added to the footer of the response and lastIndexOf build correctly. But now it's added earlier than '</html>', so of course lastIndexOf smaller. I'm not sure, what the condition "index < response.lastIndexOf('</html>')" is for exactly, but I suggest to change it to <body>

// Check for a signature in the request.
index = response.lastIndexOf( signature );
if ( -1 === index || index < response.lastIndexOf('<body>') ) {
	deferred.rejectWith( self, [ 'unsigned' ] );

// Strip the signature from the request.
response = response.slice( 0, index ) + response.slice( index + signature.length );

// Create the iframe and inject the html content.
self.iframe = $('<iframe />').appendTo( self.container );

return then doesn't need commenting out anymore.

Last edited 4 years ago by wdfee (previous) (diff)

#9 @SergeyBiryukov
4 years ago

  • Milestone changed from Awaiting Review to 3.5

#10 @kovshenin
4 years ago

@wdfee I can not reproduce this on a clean install from trunk, running multisite in subdomain mode. Can you please clarify the exact steps to reproduce the problem if it still persists? I have tried several browser combinations with apache and nginx. Thanks!

#11 @kovshenin
4 years ago

  • Keywords reporter-feedback added; needs-testing needs-refresh has-patch removed

#12 @nacin
3 years ago

  • Milestone changed from 3.5 to Awaiting Review

No steps to consistently reproduce this. Moving out of 3.5.

#13 @SergeyBiryukov
3 years ago

Possibly related: #22430 (mentions a blank page in the customizer preview).

#14 @wdfee
3 years ago

sorry, I didn't set my mail address for notifications (did it now).
So, today I updated to 3.5 beta 3 and the problem still persists. Everything as described above.
I repeated my steps from comment:8, and it's working again.

Than I reverted it again, took the one line solution from nacin from #22430 and it's working, too! So this really is a zlib.output_compression matter. Have this in a plugin now, happy that core stays untouched :-)

#15 @stebok
3 years ago

Same problem here.

Wordpress 3.4.2 with Multisite with 3 blogs installed. Using subdomains. On 2 blogs, the customize button works fine. On the third blog, I see the left panel but right panel is blank. Possible issue is that the third blog has a domain mapped to it.

#16 @stebok
3 years ago

  • Cc stebok@… added

#17 @SergeyBiryukov
3 years ago

Seems like we have two distinct issues here:

  1. The issue with the domain mapping plugin (#21235). I guess this should be fixed in the plugin, unless it reveals some bug in core that can be identified and confirmed.
  2. The issue with zlib.output_compression (#22430). #18525 should fix that.

#18 @DrewAPicture
19 months ago

  • Focuses javascript added

Can this still be consistently reproduced in 4.0/latest trunk?

#19 @thefiddler
10 months ago

First time contributing here, so forgive me if I do it wrong. I've noticed that any site I use SSL (https) for the admin, the preview does not work. The little loading indicator just spins. For me it's been reproduce-able every time.

EDIT: I spoke to quickly. I tried on another site that has SSL and it worked fine. So I'm assuming it's a Divi issue and will take it up with ElegantThemes. Apparently previewing another theme doesn't circumvent whatever in Divi is causing the issue. I'd delete this, but don't see a way to. Apologies.

Last edited 10 months ago by thefiddler (previous) (diff)

#20 @peter.englmaier
7 months ago

I observed this behaviour with the current WP 4.3.1 release. Preview doesn't show, but firefox developer tools tell me, that the preview of the page has loaded. I do have SSL enabled for admin.

I found this workaround for the problem (after reading comment:17):

When I disable GZip Compression in the FarFutureExpiry plugin, the preview works normal again.

If you do not use FarFutureExpiry, give it a try.

I guess this trick is similar to what you do.

Is there a commit in trunk which addresses this issue or do you just want to ask generally?

#21 @westonruter
13 days ago

This issue should be resolved with discontinuing to load the iframe via Ajax and instead loading the natural URL in the iframe instead: #30028

Note: See TracTickets for help on using tickets.