steevithak
Forum Replies Created
-
Forum: Fixing WordPress
In reply to: WP 5.3 Causing random 301 redirectsI filed a bug report on this one and we’ve made some progress. There is actually a bug. It causes 404/301 errors on valid blog posts due to a one day shift in the day value in the dynamically generated permalink from get_permalink() vs the real permalink associated with the post. The bug seems to only affect a small percentage of posts, likely only those with a timestamp near midnight where a change in time zone could shift the day up or down by one.
I found an experimental change that fixes the problem by reverting one line of code from 5.3 (I wouldn’t recommending making the change on a production site yet but I’m hopeful there will be some kind of real fix soon). Here’s a link to the bug report:
Forum: Fixing WordPress
In reply to: WP 5.3 Causing random 301 redirectsWOW, just made a breakthrough and found an interesting clue into the source of the bug! Over time, pages that used to get errors have started working and pages that were working a few hours ago are now getting errors. By capturing the URLs in the request header in the browser console and comparing them to the URLs in the page permalink display in the WP editor, I’ve found that the problem is due to a time mismatch in WP 53. There seems to be a time zone shift between the time WP uses to render the permalink in the live URLs used throughout the website and the permalink where the page really lives.
For example compare these two URLs:
https://www.steevithak.com/2018/07/22/ecotopia-by-ernest-callenbach/
https://www.steevithak.com/2018/07/23/ecotopia-by-ernest-callenbach/
The first one with a ’22’ in the day field is the real URL where the page really lives. It’s the URL that’s been indexed by Google. It’s the URL that was always used prior the WP 53 upgrade.
The second URL, copied from the permalink display in the WP editor, from after the WP 53 upgrade, has the wrong day – BUT – not all of the time! The day field varies between ’22’ and ’23’ depending on what time of day it is! Part of the day I get the page error and part of the day the page works depending which day WP sticks in the links it displays on the site for that page.
My conclusion is that WP is using the wrong time zone to render permalink times or blog timestamps. There’s some cross over between the time zone WP is using to build the live URL vs the Central time zone, where I live and which was used to put in the ’22’ when the page was created. Because midnight is out of sync between the two zones, there’s a period of time when it shifts between day 22 and 23.
There’s probably a line of code where WP uses the Unix epoch time to render the permalink from the timestamp on the blog post and it’s supposed to render it using the user’s local time zone but is instead rendering it either as straight UTC time or in some other wrong time zone. And since this worked on WP 52 and older, I bet you could find it by checking the source code diff between WP 52 and 53.
Forum: Fixing WordPress
In reply to: WP 5.3 Causing random 301 redirectsNo caching, seo, or redirect plugins are installed.
I use one of the Twenty* themes (or a slight variation on one, anyway)
I installed the Health Check plugin. I used it to turn off all other plugins and switch to the newest default theme. The problem still occurs with one slight difference. Instead of a 301 redirect I get a 404 with an error that says the page no longer exists. I’m guessing my live theme has a built-in redirect on the 404 page that sends users to the main page. Either way, though, it’s broken. The posts are actually in the data base and can still be seen in the editor view.
Thanks! 🙂
Thanks, I’ll give that a try! RedHat will continue to provide support for the RHEL and CentOS official MySQL versions until the respective RHEL/CentOS distros go EOL. And they will continue to back port all MySQL security patches and test for binary compatibility, so it’s safer for RHEL/CentOS users to stick with the official version until moving to CentOS 7.x in a few years. Installing a MySQL from an unsupported repo or, worse, installing a homemade version built from source, can create security issues. According to the WordPress site MySQL 5.6 is “recommended” but 5.1 is still fully supported by WordPress. WordPress usually follows the version supported by the Enterprise grade GNU/Linux distros, so we’ll look at moving when they change their requirements.
Looks like our MySQL is up to date. We’re running an Enterprise Grade distro, CentOS 6.9, and the provided MySQL is 5.1.73-8, which includes back ports of all the latest MySQL security updates. Can you clarify what Pods is doing that’s not compatible with this version? For security reasons, we’d prefer not to run an unsupported version of MySQL.
Forum: Plugins
In reply to: [GR Progress Widget] Error retrieving data from GoodreadsOh, awesome, doing a cron job during the night would be ideal. I’ll take a look at that.
Forum: Plugins
In reply to: [GR Progress Widget] Error retrieving data from GoodreadsWow, that was fast! Yes, that fixed it for me. I read the FAQ. No worries if it’s taking a bit longer to load. I have the widget there to show what I’m reading and what I’ve recently read, so I understand that means the “already read” shelf is going to keep getting bigger and slower to load over time, even if I only display a few of the most recent ones. Maybe the slowdown is an indication that Goodreads need some kind caching or indexing on their end to speed up queries. Anyway, thanks for the quick fix!
Hmmm… would you advise increasing the widget cache time from 1 hour to 24 hours on large shelves so it’s not reloading as much?
Forum: Plugins
In reply to: [GR Progress Widget] Error retrieving data from GoodreadsHi, thanks for the offer to take a look. You can see my wordpress here: http://steevithak.com
The gr-progress widgets are in the right hand column.
Widget that’s working uses shelf name: currently-reading
GR: https://www.goodreads.com/review/list/50632260?shelf=currently-reading
Widget that recently stopped working uses shelf name: read
GR: https://www.goodreads.com/review/list/50632260?shelf=read
My Goodreads user ID: 50632260
I’d rather not post the API key in a public forum; anyway it hasn’t changed and has been working fine for months (and continues to work in one of the widgets).I’ve started seeing “Error retrieving data from Goodreads. Retrying in 55 minutes.” on my site too, which has worked fine in the past. Has anyone made progress on finding the cause of this problem?
Forum: Plugins
In reply to: [GR Progress Widget] Error retrieving data from GoodreadsAny progress on this? I noticed I’m seeing the same problem on my site too lately. I have a page with two GR Widgets, a “reading” shelf and a “read” shelf. One continues to work normally but the second has started showing “Error retrieving data from Goodreads. Retrying in 60 minutes.” Nothing has changed on my end in months other than the recent WordPress core update and GR plugin updates (same PHP version, Apache version, etc). I’ve tried removing and recreating the widget but no change. Maybe we’re limited to one GR widget per page now? Or there’s a limit API accesses?
Forum: Plugins
In reply to: [GR Progress Widget] HTTPS support?Awesome, thanks for the quick reply!
Forum: Plugins
In reply to: [WP Popular Posts] What happen to “All Time” stats?Ok, I see it. Glad it’s still there! I wasn’t sure what that was from the name. Might want to include a description that says it shows the all time stats. Thanks!
OK, thanks for looking into it! Yes, I think a small tweak to the documentation would be the best answer then; to say it includes the first paragraph rather than the first line. And, no problem, I’ll write future goodreads reviews with that in mind and include a very short first paragraph.
You can see my blog here (Goodreads data is in the right column, scroll down to the “recently finished” shelf to see the problem):
And my Goodreads page is here:
https://www.goodreads.com/steevithak
Ideally, I’d like to be able to limit the review text to a specific number of characters, maybe the first 60 chars followed by an ellipses “…” but it seems like at most, the first sentence should be shown. Otherwise lengthy reviews are too big to fit.