6

I have a WordPress install using a Comodo SSL certificate. I have the WordPress HTTPS plugin installed and I'm using the AZ theme, and the admin is set to load over HTTPS. So far so good.

On the theme customizer, I get a perpetual loading icon (not to be confused with a WSOD). The AJAX call that brings back the homepage content is empty, save for the WP_CUSTOMIZER_SIGNATURE token. That is all the response includes. When I disable the WordPress HTTPS plugin (or otherwise disable loading the admin over SSL), the customizer works great. Disabling/enabling other plugins has no effect. This occurs with the stock Twenty Fifteen theme as well (pictured below).

Here is a screenshot of what I'm seeing in Firebug (and is reproducible across browsers, as well as on Browserstack VMs):

Screenshot of Firebug console in customizer view

In case it's relevant, the site is hosted on a DigitalOcean droplet, using ServerPilot. I have other WordPress sites hosted on the same droplet, and the other SSL-enabled one exhibits the same behavior. ModSecurity is not installed, to my knowledge, and I'm getting a 200 status code so I don't think it's this issue.

Also, the SHA-1 messaging appears to be a false positive, so far as I can tell (and I don't think Firefox is yet at the point of blocking content based on SHA-1 usage anyhow?). I don't think it's zlib.output_compression bug either, as I have turned it off explicitly to test, and attempted the fix listed in that ticket, which didn't work.

I haven't found anything that quite matches my problem, which makes me think there is something stupid I have overlooked. Any help is greatly appreciated, and please let me know what additional information may be helpful.

6
  • For my own curiosity, what console warnings/errors are you getting in Chrome? Right click > Inspect Element > Console
    – Jami Gibbs
    Commented Jul 3, 2015 at 15:27
  • Chrome behaves just like Firefox, so the console is empty except for the XHR entry. Commented Jul 8, 2015 at 23:55
  • Are you still experiencing this problem @KellyCarter, or did you manage to solve it?
    – Tim Malone
    Commented Jun 29, 2016 at 8:03
  • Still experiencing. :( Commented Jun 30, 2016 at 17:05
  • Based on what you wrote I'm sure you already tried this but did you turn on DEBUG in the wp-config file?
    – Fencer04
    Commented Jul 27, 2016 at 19:34

2 Answers 2

1

Based on your question, I assume this is the plugin you are using to enable SSL: WordPress HTTPS.

Considering that the plugin hasn't been updated in two years and their support questions haven't been resolved, there may be some compatibility issues with the latest version of WordPress (4.6 at the time of this writing). My recommendation to make sure your website's URL is running HTTPS everywhere.

THis can be done by executing the following SQL query in your database (phpMyAdmin):

UPDATE wp_options SET option_value = replace(option_value, 'HTTP_URL', 'HTTPS_URL') WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE wp_posts SET guid = replace(guid, 'HTTP_URL','HTTPS_URL');
UPDATE wp_posts SET post_content = replace(post_content, 'HTTP_URL', 'HTTPS_URL');
UPDATE wp_postmeta SET meta_value = replace(meta_value,'HTTP_URL','HTTPS_URL');

Replace the values with the following:

  • HTTP_URL > your HTTP link (http://some.site)
  • HTTPS_URL your HTTPS link (https://some.site)

This way, it prevents any mixed-content links from breaking things. I've also found a WordPress thread with a similar issue and not sure if you've already taken a look at it:

Theme Customizer Problem

1
  • After following these steps, I then had to disable the aforementioned WordPress HTTPS plugin, and the customizer began working again. Thank you so much! Commented Aug 24, 2016 at 18:58
0

ANSWER: This is due an inconsistency on your global URLs

I guess at some point the string customizer of your plugin doesn't recognize some elements that are still called through http instead of https, many plugins contains absolute paths instead of relatives so, in order to fix the whole platform: admin, content and includes you can do the following.

  1. Install a plugin called WP Migrate DB
  2. Once installed and activated Go to Tools -> Migrate DB
  3. The new url must be the same, and so the file path.
  4. Download the backup (why did I tell you this instead of just export directly of your phpmyadmin or dbms?, because is a safer way to get that info, that's all, in the export you can avoid some instructions to drop, this makes the "backup" an error proof method).
  5. Save it to an specific directory, alone, an uncompressed copy of it.
  6. In terminal go to that directory and execute the following command:

sudo find . -type f -name '*.sql' -exec sed -i '' s,http://yoursite,https://yoursite,g {} +

  1. Upload the new file importing it to your phpmyadmin or web dbms.

  2. The error must be gone.

IMPORTANT.

In case it didn't work you have your backup untouched copy remaining of step 5.

ADDITIONAL INFO. Did you check that the website root URL begins with https instead of http?

You can check that on Settings -> General

WordPress Address (URL)

Site Address (URL)

Good luck.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.