Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Page Navigation broken on Front Page #209

Closed
raamdev opened this Issue Jun 12, 2014 · 39 comments

Comments

Projects
None yet
5 participants
Owner

raamdev commented Jun 12, 2014

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

@raamdev raamdev added this to the Next Release milestone Jun 12, 2014

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.

BTW- latest WP version theme is Alyeska by Themeforest

@raamdev raamdev self-assigned this Jun 16, 2014

Owner

raamdev commented Jun 16, 2014

@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.

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/websharks/quick-cache/issues/209#issuecomment-46221174.

Owner

raamdev commented Jun 18, 2014

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.

Haver there been any reported problems with pro?

Owner

raamdev commented Jun 18, 2014

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.

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/websharks/quick-cache/issues/209#issuecomment-46504793.

Owner

raamdev commented Jun 19, 2014

@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).

Owner

raamdev commented Jun 19, 2014

@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?

Owner

raamdev commented Jun 19, 2014

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.

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.

Owner

raamdev commented Jun 21, 2014

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

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/websharks/quick-cache/issues/209#issuecomment-46766919.

Owner

raamdev commented Jun 23, 2014

@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?

@raamdev raamdev removed the needs testing label Jun 23, 2014

Owner

jaswrks commented Jun 23, 2014

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

Owner

jaswrks commented Jun 23, 2014

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.

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/websharks/quick-cache/issues/209#issuecomment-46880125.

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

Owner

jaswrks commented Jun 24, 2014

@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;
}

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

Owner

jaswrks commented Jun 25, 2014

@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!

@jaswsinc thanks. that worked and back in business!

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

Owner

raamdev commented Jun 25, 2014

@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.

Owner

raamdev commented Jul 1, 2014

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.

@raamdev raamdev modified the milestone: Future Release, Next Release Jul 1, 2014

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?

Owner

raamdev commented Jul 13, 2014

@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.

Owner

jaswrks commented Jul 13, 2014

@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.

@jaswrks jaswrks pushed a commit to websharks/comet-cache-pro that referenced this issue Jul 13, 2014

JasWSInc WP `redirect_canonical()` bug workaround. See websharks/comet-cache#209 130611b
Owner

raamdev commented Jul 13, 2014

@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?

Owner

jaswrks commented Jul 13, 2014

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.

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

Owner

jaswrks commented Jul 14, 2014

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.

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.

Owner

raamdev commented Jul 15, 2014

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

Thanks again!

@raamdev raamdev removed this from the Next Release milestone Aug 4, 2014

Owner

raamdev commented Oct 3, 2014

@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?

Owner

jaswrks commented Oct 3, 2014

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.

@raamdev raamdev closed this Oct 4, 2014

@raamdev raamdev removed their assignment Apr 28, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment