Page Navigation broken on Front Page

[raamdev]

There have been several reports that the page navigation on the front page became broken after the latest Quick Cache update (v140605). For example, clicking the "Previous posts" link at the bottom of a listing of blog posts on the front page doesn't actually lead to page 2 of the blog posts, but rather just has the effect of reloading the home page. Once on Page 2, however, the navigation links seem to work fine.

I have been unable to reproduce this problem, however I'm still gathering information and will update here when I know more. The fact that two separate people reported the same problem warranted the creation of a GitHub issue to track this.

---

Reported here:
http://wordpress.org/support/topic/latest-updated-broke-my-blog-navigation
http://wordpress.org/support/topic/page-2-and-beyond-not-loading
https://websharks.zendesk.com/agent/#/tickets/3006
https://websharks.zendesk.com/agent/#/tickets/2845
http://wordpress.org/support/topic/quickcache-conflicts-with-newspaper-theme-no-navigation

[davidcpa135]

Very similar problem. It drops the two right items on my main menu and the middle menu item. Most pages (except the home page are ok until cache expires) the menu items are deleted from the wordpress Appearance-->Menu section. Disable the plugin and menus (once links are replaced) are fine. This is a very good plugin and would like to to keep using.

[davidcpa135]

BTW- latest WP version theme is Alyeska by Themeforest

[raamdev]

@davidcpa135 Thank you for the additional info! This is an odd bug and any extra help figuring this out would be greatly appreciated. You said:

Disable the plugin and menus (once links are replaced) are fine.

Could you explain what you mean by "once the links are replaced"?

If you could provide me a list of steps to recreate this issue, that would be very helpful for me.

[davidcpa135]

Raam,
What I meant was that the menu items would be erased from the wordpress menu setup. “Replacing the links” means that I recreated the primary menu item(s) with a link to its post or page.

Please let me know if questions remain.

From: Raam Dev [mailto:notifications@github.com]
Sent: Monday, June 16, 2014 3:10 PM
To: websharks/quick-cache
Cc: David Conley
Subject: Re: [quick-cache] Page Navigation broken on Front Page (#209)

@davidcpa135https://github.com/davidcpa135 Thank you for the additional info! This is an odd bug and any extra help figuring this out would be greatly appreciated. You said:

Disable the plugin and menus (once links are replaced) are fine.

Could you explain what you mean by "once the links are replaced"?

If you could provide me a list of steps to recreate this issue, that would be very helpful for me.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/209#issuecomment-46221174.

[raamdev]

I just attempted to reproduce this issue using the Weaver II theme (version 2.1.12) and Quick Cache Pro v140605 and I was NOT able to reproduce the issue (that combination was reported here as causing problems.). The "Older posts" link on the home page works as expected.

Still unable to reproduce this issue.

[davidcpa135]

Haver there been any reported problems with pro?

[raamdev]

Haver there been any reported problems with pro?

I'm not sure I understand the question...

I've tested the Weaver II theme against both Quick Cache (LITE) and Quick Cache Pro, and I'm unable to reproduce the problem.

[davidcpa135]

Raam,
Sorry to be unclear. What I meant was if I knew buying Pro would fix my problem, I’d do it in a heartbeat. Here’s some data from the server side. Could any of these settings or specs be the problem?

[cid:image001.png@01CF8BA1.440D1FA0]

From: Raam Dev [mailto:notifications@github.com]
Sent: Wednesday, June 18, 2014 6:53 PM
To: websharks/quick-cache
Cc: David Conley
Subject: Re: [quick-cache] Page Navigation broken on Front Page (#209)

Haver there been any reported problems with pro?

I'm not sure I understand the question...

I've tested the Weaver II theme against both Quick Cache (LITE) and Quick Cache Pro, and I'm unable to reproduce the problem.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/209#issuecomment-46504793.

[raamdev]

@davidcpa135 It looks like the image you tried attaching did not come through. I don't believe GitHub supports attachments via email, so you'll need to drag-n-drop that into the comment box from the web interface.

What I meant was if I knew buying Pro would fix my problem, I’d do it in a heartbeat. Here’s some data from the server side.

I can't say that Pro would fix the problem, as I haven't been able to reproduce this problem with Quick Cache LITE or Quick Cache Pro. Until I find a way to reproduce the bug, I have no way of troubleshooting.

If it would be possible for you to setup another WordPress install on your server, running the same theme and set of plugins, and if I could get an admin login for that test site, that would definitely help me track down what's causing this issue. You can submit private details here (link expires in 24 hours).

[davidcpa135]

[raamdev]

@davidcpa135 Thank you for that info. I don't see anything there that might cause such an issue. Can you tell me if you're having the problem with the "Next" page link on the home page redirecting to the home page instead of going to page 2 of posts?

[raamdev]

I just installed Weaver II Pro v2.1.13 with Weaver II Theme Extras v2.2.10 and Quick Cache v140605 and I was unable to reproduce the problem as described here.

[Power-1st]

Hi, Raam Dev. I'm Power-1st, maybe you remember me, I just tested again, the same plugins and theme on my localhost (127.0.0.1), when I updated QC pro v140104 to v140605, the QC pro was still normal and worked fine. So I don't think it should be compatible or conflict with my wordpress, Perhaps the upgrade caused QC database wrong.

[raamdev]

@davidcpa135 Can you tell me what web host you're using?

[davidcpa135]

Miva merchant

Sent from my Verizon Wireless 4G LTE Tablet

-------- Original message --------
From: Raam Dev notifications@github.com
Date: 06/21/2014 6:44 PM (GMT-05:00)
To: websharks/quick-cache quick-cache@noreply.github.com
Cc: David Conley david@cpatax.net
Subject: Re: [quick-cache] Page Navigation broken on Front Page (#209)

@davidcpa135https://github.com/davidcpa135 Can you tell me what web host you're using?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/209#issuecomment-46766919.

[raamdev]

@jaswsinc I have narrowed down this bug to wp_main_query_postload() on this line in includes/advanced-cache.tpl.php, as you suspected, specifically to the is_front_page() check.

It looks like you added the wp_main_query_postload() function in April. Could you take a look at this code and let me know if you have any ideas why is_front_page() is causing issues here?

[jaswrks]

Great! Something to go on. I'll take a look.

[jaswrks]

Just took a quick look. Nothing jumping right out at me yet. I was still unable to copy the settings from that site and reproduce it in a default WP theme. Still baffled for now. I'll take a closer look later.

[davidcpa135]

Please keep us in the loop. Would like to reinstall but it’s trashing my menu.

From: JasWSInc [mailto:notifications@github.com]
Sent: Monday, June 23, 2014 2:04 PM
To: websharks/quick-cache
Cc: David Conley
Subject: Re: [quick-cache] Page Navigation broken on Front Page (#209)

Just took a quick look. Nothing jumping right out at me yet. I was still unable to copy the settings from that site and reproduce it in a default WP theme. Still baffled for now. I'll take a closer look later.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/209#issuecomment-46880125.

[Power-1st]

Thanks for your help! If you need any test, just tell us! and I want to point that 140104 work fine, but 140605 is wrong

[jaswrks]

@raamdev I used the details you provided earlier and then tracked this down a bit further to a particular line in the WordPress core related to redirect_canonical(). Seems to be a WordPress bug. This line has a conditional that doesn't quite make sense to me yet. Seems like a hackety hack they are using there to me. It looks for the queried object already being set; which can occur anytime a plugin calls upon is_front_page(). So obviously it's creating some issues here under the right conditions.

This might not impact the WordPress Core without a plugin. However, add the right plugin to the mix where 'page' == get_option('show_on_front') && $wp_query->queried_object->ID == get_option('page_on_front') and voila; you have the buggy behavior being reported here. Not really the fault of Quick Cache at all (or any theme either); it's just this line in the WordPress core is not considering all possible scenarios.

I think we just need to find a way to work around this for now and then report it to WordPress. While I found the line causing an issue, I will still need to learn more about this routine in order to propose a suggestion about how to have it corrected. If you beat me to it please let me know.

---

Quick Fix for Site Owners

Create the following directory and file.
/wp-content/mu-plugins/wp-bug-fix.php

<?php
add_filter('redirect_canonical', 'wp_bug_fix__redirect_canonical');
function wp_bug_fix__redirect_canonical($url)
{
    if(strpos($_SERVER['REQUEST_URI'], '/page/') !== FALSE)
        return ''; // Prevent the bug from occurring.
    else return $url;
}

[sathyabalu]

Do i need to clear cache to see the effect of the fix?. I added the above fix and don't see any change.

[jaswrks]

@sathyabalu So sorry. I was missing the !== FALSE up there. I've just updated that bug fix code in the my last post to include an additional scenario. Please try this again and let me know if you have any further trouble. Thanks!

[sathyabalu]

@jaswsinc thanks. that worked and back in business!

[davidcpa135]

Apologies for asking a basic question but does the above fix require a closing php tag?

[raamdev]

@davidcpa135 We don't mind basic questions at all. :)

The closing ?> PHP tag is not required. See also, Instruction separation:

The closing tag of a PHP block at the end of a file is optional, and in some cases omitting it is helpful when using include or require, so unwanted whitespace will not occur at the end of files, and you will still be able to add headers to the response later. It is also handy if you use output buffering, and would not like to see added unwanted whitespace at the end of the parts generated by the included files.

[raamdev]

Punting this to the Future Release milestone as this issue will require more time to investigate the WordPress bug that is causing this strange behavior.

For now, site owners can use the quick fix Jason posted here.

[Power-1st]

Thanks for guys help! I have an other question, Can you fix this issue in the next version? Or whether we should delete this file (wp-bug-fix.php) when we update to the next version?

[raamdev]

@Power-1st We're still researching the correct way to go about "fixing" this. It appears that this is more a bug with WordPress Core itself, so it will take some time to research a proper fix. When a fix is released, you should delete the wp-bug-fix.php file, yes.

[jaswrks]

@raamdev It looks like Nacin was aware of this issue about two years ago, but it would seem it did not get fixed. I'm referencing his comment here: https://core.trac.wordpress.org/ticket/21602#comment:7

I am taking a closer look at this now.

[raamdev]

@jaswsinc Thanks for the Pull Request. I'm going to accept that temporary workaround and push it out with the next update to Quick Cache.

Do you see any potential conflict if a site owner has already implemented the Quick Fix you mentioned earlier? I know it's not necessary to have both in place, and from what I can tell there would be no conflict. Will the sky fall down if a site owner upgrades to the next version (with the fix you submitted in your PR) and already has the Quick Fix in place that you suggested earlier?

[jaswrks]

Great! Thank you Raam :-)

Will the sky fall down

No, it should do just fine. The wp-bug-fix.php will not be necessary once a site owner has the latest, but leaving it would do no harm either.

[Power-1st]

There‘s not some influence or conflict on us if we leave the "wp-bug-fix.php" there?

[jaswrks]

There‘s not some influence or conflict on us if we leave the "wp-bug-fix.php" there?

Once you get a notice in your WP Dashboard that the next release of Quick Cache is available, you could delete the wp-bug-fix.php file if you like. Leaving it won't hurt anything, but it won't be necessary once the next version of QC is made available.

[Power-1st]

Thanks for your reply! The next release of Quick Cache will fix this issue? I mean if QC will fix the issue of Page Navigation broken on Front Page, of course we'll delete the wp-bug-fix.php. But if the issue is still there, the file is necessary for us.

[raamdev]

@Power-1st Yes, the next version of Quick Cache will include a workaround for this issue.

[Power-1st]

Thanks again!

[raamdev]

@jaswsinc Since we integrated your 'temporary workaround' into v140725, do you see any reason to keep this issue open? I haven't heard any more reports of this issue since we implemented the workaround.

When you say 'temporary workaround', do you just mean temporary until WordPress fixes the underlying bug? If so, since that hasn't happened in 2 years I'm not sure we can expect that WordPress bug to ever get fixed.

Should we just close this issue for now?

[jaswrks]

I haven't heard any more reports of this issue since we implemented the workaround.

Cool. Agreed! :-) We are aware of this now, that's the biggest thing.