Regression – Update breaks .php page on site

  • Resolved df7729

    (@df7729)


    7 months, 1 week ago

    Updated last night and users came in with problems: “Content Encoding Error” or “certificate error”

    It’s a .php outside of wordpress in the website root that just loads in the wordpress headers and then uses normal html / php for the body:

    <?php 

require_once(DIR_ROOT.'/wp-load.php');
add_action('wp_head', 'norobots', 0);
function norobots() {
echo ("");
}
get_header();
?>
....
<?php
get_footer();
?>

    When I reverted to the backup and didn’t update wp-optimize things work fine.

    Note that if I was logged in to wordpress admin account everything worked fine, if not logged in, it was broken.

    • This topic was modified 7 months, 1 week ago by df7729. Reason: add note
Viewing 13 replies - 1 through 13 (of 13 total)
  • Plugin Support vupdraft

    (@vupdraft)

    Can you try deactivating and reactivating all of your plugins?

    Thread Starter df7729

    (@df7729)

    What I did was revert back then upgrade everything except wp-optomize and the page loaded fine, I don’t want to upgrade again until you confirm it should work by creating the same type of .php page outside of wordpress.

    Plugin Support vupdraft

    (@vupdraft)

    Do you have gzip compression enabled? Can you try disabling it in WPO then updating WPO. It’s possible that you already have it enabled on the server or Zlib compression or another plugin and this is causing a conflict.

    Thread Starter df7729

    (@df7729)

    I should point out that I’ve used wp-optimize for a couple years with no problem before this update. Also the only problem I found was with the page outside of wordpress that loaded the wordpress headers (If I prevented loading header it worked as well).

    Also if logged in as admin, there is no problem, if trying from a user not logged in then the blank page with browser warning (showing in browser debugger).

    Plugin Support vupdraft

    (@vupdraft)

    Would I be able to have your site URL?

    Thread Starter df7729

    (@df7729)

    I tried upgrading to 3.4.2 and it destroyed the non wordpress .php page that just loads the wordpress headers again. I tried changing gzip setting, no difference, I had to restore a backup. Have you tried creating the .php sample I sent above to see if it works for you?

    • This reply was modified 4 months, 3 weeks ago by df7729.
    Plugin Support wpmansour

    (@wpmansour)

    Thank you for your patience. We’ve attempted to replicate the issue on our end by creating a similar .php page outside of WordPress that loads the WordPress headers. However, we were unable to reproduce the “Content Encoding Error” or “Certificate Error.” The page worked fine both for logged-in and logged-out users.

    Once activated, can you try clearing the cache, including server caches? Are you using Cloudflare or any CDN?

    Thread Starter df7729

    (@df7729)

    No, nothing special – I have just stayed on the old version – I’ll have to setup another site to test and provide link…

    Thread Starter df7729

    (@df7729)

    Good News – the latest update works!!

    Thread Starter df7729

    (@df7729)

    Sorry – I was wrong – I forgot that it works if I’m logged in, only if not logged in to wordpress is it broken. I’ll check that staging site again too…

    Thread Starter df7729

    (@df7729)

    I have a staging site setup that causes it – I had to add additional php files the main page includes. So you can now see it first hand and log in to find the cause/conflict. How do we set that up?

    Thread Starter df7729

    (@df7729)

    It was really weird, If I added an include to a file (I tried renaming it even making it a blank code of .php file), it would start the problem, even though it includes other files fine.

    I was able to exclude the /pagename.php from the cache in wp-optomize, now it works. So not sure why the new version starting causing problems, but these type of pages shouldn’t be cached anyway, it should be only items under wordpress itself.

    Plugin Support wpmansour

    (@wpmansour)

    Thank you for your detailed updates. Based on the information you provided and our recent tests, it appears that the issue is indeed related to the WP-Optimize cache settings affecting your external PHP page. Since excluding the /pagename.php from the cache resolved the issue, here’s the precise solution to implement this permanently:

    1. Go to your WP Admin Panel ? WP-Optimize ? Cache ? Advanced settings.
    2. In the “List URLs that should not be cached” field, add /pagename.php (replace pagename.php with your actual page name).
    3. After excluding the page, clear the cache to apply the changes. Navigate to WP Admin Panel ? WP-Optimize ? Cache and click on “Clear Cache”.

    This should ensure that WP-Optimize does not cache this specific PHP page, resolving the content encoding and certificate errors for users who are not logged in.

Viewing 13 replies - 1 through 13 (of 13 total)
  • You must be logged in to reply to this topic.