Abigailm

> Do you have any errors in your php error log?

I did not see any.

> What version of WordPess are you running?

4.61

> What verision of PHP are you reading?

5.6.23

> What is your include path?

.:/usr/lib/php:/usr/local/lib/php.:/usr/lib/php:/usr/local/lib/php

> Are you loading your site over http or https?

I had problems both ways.

I’d note that there are two sites, same server, that don’t seem to have any problem or issue with the upgrade. The main difference, other than different domain names, would be that each site has a different theme and combination of plugins.

Several sites produced the 503 error I described above; one site didn’t work but only displayed a browser error page rather than the Cloudflare page; and one site simply didn’t “take” — the Cloudflare v.3 installation wouldn’t retrieve or recognize the site in the settings area. That is the site that I tested both https & http on.

I have deleted the upgraded plugin on all sites with problems and restored to version 1.3.25 — so there’s not much more I can do to help.

I am very confused by the changes in the plugin and the lack of documentation or explanation – for example, why the upgrade doesn’t allow switching to development mode or reporting of spam comments.
So I won’t be re-installing the upgrade until all bugs are worked out and there is more documentation is available. (In other words, I can’t help you with testing at this point)

Bad news – I found another conflict — this one with a very popular and widely used plugin: The Events Calendar. (According to this site, 400,000+ downloads)

In the calendar month view mode, there is javascript that powers popups as the user hovers over specific events on the calendar. With the Alt WebP option enabled, it breaks the code on all browsers, leading to the code being displayed at the bottom of the page. The Console tells me that it’s throwing off an image not found error. So that’s one more site I can’t use this option with.

Not a big problem for me — but this is a problem you are more likely to run into with other users.

There are two sites with problems

The one that I first mention is a blog and source code shows it is declared simply as DOCTYPE html — so no XHTML issue. The problem is not with all images on the site, but shows up with the slider and thumbnails on the home page, particularly the thumbnails in a sidebar widget. There could very well be a problem with the script that runs the slideshow. I also found that CloudFlare Mirage leads to similar problems for display on a smart phone – so I just think that particular theme can’t really handle anything messing with the images on the home page.

The other site is a directory site with a large map on the home page, with pop-up boxes containing an image for each point on the map. That one very likely is an issue with coding, as on that site I see what you described — the page filled with script.

Anyway, I don’t think its worth chasing down. Both are themes that I am unlikely to use again on other projects. The only thing I would suggest– and it’s totally up to you — is a little bit of improvement on documentation for the Alt WebP option. The reason I mistakenly assumed that it simply didn’t work with CloudFlare is that CloudFlare was not specifically mentioned, and though CloudFlare is widely used and functions as CDN, it is a very different model than other CDN’s, with its own set of features that rewrite HTML on a page (such as the Rocket loader). So I just mistakenly assumed that there was a conflict somewhere coming from CloudFlare rather than recognizing that the issue was theme-specific.

Thank you so much for the quick reply. I tested it again and still had the same problem on Chrome- and I’m sure it’s not a caching issue because I can replicated it easily. However, the problem seems to be tied the specific theme. I am seeing issues with the slider and thumbnail images for that particular theme, and not seeing it elsewhere.

So I’ll go ahead and re-enable and check on the other sites and monitor it, and re-post if i see the problem elsewhere.

I appreciate the offer to help with troubleshooting, but this particular theme hasn’t been updated in quite a while, so probably not worth trying to address.

It’s been a while since I posted that comment.

I think I got things working the way I want (archived posts not visible on the front end to any users, whatever the privilege level) with this code:

function my_aps_default_read_capability( $capability ) {
    $capability = 'read';
    return $capability;
}
add_filter( 'aps_default_read_capability', 'my_aps_default_read_capability' );
add_filter( 'aps_status_arg_public', '__return_false' );
add_filter( 'aps_status_arg_private', '__return_false' );

Alex, I could be mistaken, but I don’t think that anything that was free before requires premium. I think the problem is that some features were rewritten in a way that impacts display. In particular, the upgraded version allows a choice of different header styles. In the free version there are 2 styles to choose from, with more styles available in premium. The previous version only had one style. But in order to give the choice, the templates were rewritten, with an accompanying change in configuration options.

I did the same as David (zulok) — I was frustrated but decided it was best to implement the upgrade, but deferred the task until a time when I could take things slowly and carefully, one step at a time. In the meantime I set my styles for my child theme in a staging site. I didn’t move to the production site until I had solved all of the display issues first in the staging site.

You can first try to make corrections to Theme Options.

To avoid the change to white text on hover, go to:

Appearance > Theme Options > Styling > Menu and look for the “Menu hover font color”

I think if you plan to keep upgrading the theme in the future, you are better off keeping all custom CSS in the child them rather than via theme options, to avoid the potential of an override with a future update.

That’s what has happened here: the recoding in order to support new formatting options apparently has abandoned some of the earlier options. The same thing happened with the upgrade to 3.5, only in that case it was a significant rewrite of the CSS for the bootstrap slider — see https://wordpress.org/support/topic/problem-with-boostrap-slider-caption-after-theme-upgrade

That’s what is holding me back on upgrading on my live site. I am thinking that I need to move any customizations I have made via the back end into the child style.css …or else I will just be facing the same problem again in 6 months or whenever the authors decide to go to 3.7.