Make WordPress Core

Opened 11 years ago

Last modified 3 years ago

#22037 new defect (bug)

Customizer: Live preview fetches page but does not display (show error message)

Reported by: marcoliverteschke's profile marcoliverteschke Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.4.2
Component: Customize Keywords: needs-patch
Focuses: javascript Cc:

Description (last modified by westonruter)

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.


Per duplicate #28227:

When Customizer can't load due to an error, there's no indication as to what's going on. It would be nice if some information was presented instead of seeing a blank screen on the right side.

Change History (36)

#2 @wdfee
11 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 ) {
		$control->enqueue();
	}
}

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

#3 @wdfee
11 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
11 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
11 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
11 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
11 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' ] );
	//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.

#8 @wdfee
11 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' ] );
	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 11 years ago by wdfee (previous) (diff)

#9 @SergeyBiryukov
11 years ago

  • Milestone changed from Awaiting Review to 3.5

#10 @kovshenin
11 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
11 years ago

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

#12 @nacin
11 years ago

  • Milestone changed from 3.5 to Awaiting Review

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

#13 @SergeyBiryukov
11 years ago

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

#14 @wdfee
11 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
11 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
11 years ago

  • Cc stebok@… added

#17 @SergeyBiryukov
11 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
9 years ago

  • Focuses javascript added

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

#19 @thefiddler
9 years 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 9 years ago by thefiddler (previous) (diff)

#20 @peter.englmaier
8 years 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.

@wdfee
I guess this trick is similar to what you do.

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

#21 @westonruter
8 years 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

#22 @westonruter
8 years ago

  • Milestone changed from Awaiting Review to 4.7

#23 @westonruter
8 years ago

This is another place where a notification area would be helpful, to add a message when the preview fails to send a ready message to the controls. See #35210

This ticket was mentioned in Slack in #core by jorbin. View the logs.


8 years ago

#25 @westonruter
7 years ago

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

This issue will have been fixed in the patch for #30937 where the customizer now loads using a natural URL on the iframe[src] (#30028) instead of using an Ajax request.

Please test: grunt patch:https://github.com/xwp/wordpress-develop/pull/161

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


7 years ago

#27 @westonruter
7 years ago

  • Milestone changed from 4.7 to Future Release

Thinking about this some more, the changesets patch actually probably won't help this because it is now retaining the original method for using iframe replacements for both refresh and navigation. If an iframe window never finishes loading so that the customizer preview can send its ready message, then the pending iframe won't become active.

So I think we may need the notification area (#35210) after all to communicate that there is an error loading the preview.

#28 @westonruter
7 years ago

  • Milestone changed from Future Release to 4.7

Putting back in 4.7 since this is a defect and can be addressed during beta.

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


7 years ago

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


7 years ago

#31 @westonruter
7 years ago

  • Milestone changed from 4.7 to Future Release

Punting.

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


7 years ago

#33 @westonruter
7 years ago

  • Keywords has-patch removed

Let's scale the ticket back to just update the customizer JS to detect for when the customizer preview fails to load and output whatever can be gleaned as to the cause, and to then output this information as an error on the console.

#34 @westonruter
7 years ago

#28227 was marked as a duplicate.

#35 @westonruter
7 years ago

  • Description modified (diff)
  • Keywords needs-patch added; needs-testing removed
  • Summary changed from Customizer: Live preview fetches page but does not display to Customizer: Live preview fetches page but does not display (show error message)

#36 @celloexpressions
3 years ago

To clarify, the scope for this ticket is now to display an error message when the preview fails to load for an reason. Something should be displayed as a user-facing error, and potentially include any console errors or other information if possible.

The next steps are to create a patch (with a proposed design) and/or a design mockup.

Note: See TracTickets for help on using tickets.