saintandrews

Stef, I would be delighted if you would bring me up to speed on what you are talking about.

Thanks for responding.

0644; as I mentioned, the file hasn’t been altered in years, and WordPress has never revealed any problem with it.

It seems to me this problem shouldn’t be possible, yet it is.

FWIW, the exact syntax in the file right now is

define( 'MEDIA_TRASH', true );

I don’t see any misplaced or missing characters or spaces.

This obviously also begs the question of why true is not already the default. WordPress is, after all, a rather media-oriented CMS.

Thanks for the quick fix!

Sorry, I had no idea what you were seeking.

https://www.aleksandreia.com/comments/feed/

Sure.

The problem first exhibited itself to me here:

https://www.aleksandreia.com/2019/10/10/freespeechextremist-com/

As it happened, new comments made after the WPFC cache had been cleared finally did show up in the comment feed reader some eight or so hours later, but even newer comments still cannot be feed reader-fetched on demand as posts after your recent software update now can.

As I mentioned already, clearing the WPFC cache renders comments immediately available to the feed reader.

Not really.

WordPress has both a posts feed and a separate comments feed. You recently fixed the problem of the posts feed not updating for remote feed readers unless one manually cleared the WPFC cache. Now the exact same phenomena are occurring with the separate comments feed (which I was unable to check until now): until the WPFC cache is manually cleared, remote feed readers cannot see new comments to posts in the separate comments feed, even though manual cache clearing is now no longer necessary for them to pick up the new posts in the posts feed.

If you corrected the code for the separate comments feed at the same time you recently did with the posts feed, then obviously something else is afoot, although the solution still remains as simple as just clearing thw WPFC cache.

This problem apparently persists with the separate comments feed: although the post feed now updates automatically, the comments feed now require the WPFC cache to be manually cleared for a feed reader to find a new comment in the WordPress comments feed.

Thanks.

I have the identical problem with my (validated) site feed not updating until I manually clear the WPFC cache.

Brilliant. Yep, that fixed it.

Thanks.

/wp-login.php

But it has never previously thrown the login error message, only granted my whitelisted username and password access from the NF login screen to my logo-and-otherwise-customized WP one, displaying no error message, at which point I reenter my username and password, and I’m in.

In other words, when previously given my whitelisted username NF has simply presented me with my underlying WP login page exactly as it appears with NF disabled, no error message or anything else different.

OTOH, if I enter a random username and password on the external NF protection form, it simply refreshes itself, offering no other indications, patiently awaiting a whitelisted name.

Excellent. Thanks so much.

I have also been having nonstop 500 errors associated with WP Fastest Cache Preload Bot.

I’m simply interested in the ability to easily/automatically remove many noindex posts & pages from the sitemap. I’ve used HTML sitemaps before and see no reason why one wouldn’t suffice now. I’m primarily interested in keeping thin pages out of Google’s judgemental indexing eye and indexing confusion out of Google’s new beta Search Console.

In addition to the simplicity, the casual level of support Yoast historically provides for its free products is one of the reasons I’m shopping for a more enterprising sitemap alternative that might directly address and solve in the nearer term what has popped up now as an almost universal problem.

Given the way the new (beta) Google Search console treats noindexed pages that are in the sitemap I would find this extremely useful as well. Various SEO plugins are available to create the noindex meta tags, but there is also a header.php script available to add the noindex tag to all posts by designated category.

It’s possible to categorize all noindexed posts/pages as such, then filter by that category including post ID, then copy that to a spreadsheet, then distill just the post IDs, then paste those into your plugin – but you see the PITA involved.

Having that function built into the plugin (e.g., reverse reading header noindex meta tags, then excluding) would be brilliant.