WordPress.org

Make WordPress Core

Opened 19 months ago

Last modified 17 months 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: Appearance Keywords: reporter-feedback
Focuses: Cc:

Description

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 (17)

comment:2 wdfee18 months 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 ) {
		$control->enqueue();
	}
}

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

comment:3 wdfee18 months 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.

comment:4 wdfee18 months 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.

comment:5 wdfee18 months 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.

comment:6 wdfee18 months 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 );
		}
	});
},

comment:7 wdfee18 months 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' ] );
	//return;
}

// 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.

comment:8 wdfee18 months 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' ] );
	return;
}

// 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 18 months ago by wdfee (previous) (diff)

comment:9 SergeyBiryukov18 months ago

  • Milestone changed from Awaiting Review to 3.5

comment:10 kovshenin18 months 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!

comment:11 kovshenin18 months ago

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

comment:12 nacin18 months ago

  • Milestone changed from 3.5 to Awaiting Review

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

comment:13 SergeyBiryukov17 months ago

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

comment:14 wdfee17 months 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 :-)

comment:15 stebok17 months 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.

comment:16 stebok17 months ago

  • Cc stebok@… added

comment:17 SergeyBiryukov17 months 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.
Note: See TracTickets for help on using tickets.