Debugging rssCloud on WordPress.com

README.md

I have a test application running at test.rsscloud.io on ports 80 and 9876.

The following code works:

curl --location --request POST 'https://brokenriverbooks.com/?rsscloud=notify' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'domain=test.rsscloud.io' \
--data-urlencode 'port=80' \
--data-urlencode 'path=/feedupdated-s8759' \
--data-urlencode 'registerProcedure=' \
--data-urlencode 'protocol=http-post' \
--data-urlencode 'url1=https://brokenriverbooks.com/feed/'

However if you change the port to 9876 it fails. For some reason the rssCloud plugin seems unable to hit ports that are not 80.

I've uncovered a couple of things regarding this.

1. The rsscloud plugin doesn't specify a scheme for the URLs so although it seems to work in some situations on wordpress.com on an up-to-date (6.1.1) self-hosted blog it always fails. "A valid URL was not provided"

2. wp_http_validate_url seems to only allow URLs with ports 80, 443, or 8080 so aggregators running on other random ports fail.

I logged into a test site with the RSS Cloud plugin (https://rsscloud.andysylvester.com/), then updated my test app to point to it (see https://gist.github.com/andysylvester/57400e6352529858a1dc8c1ced1f11b3), got the same response from the plugin that I got from my test WordPress.com site:

root@AndyDO-03:~/rssCloudSimple# node rssCloudTestOriginal06.js

testRssCloud v0.40 running on port 2222.

http://fedwiki.andysylvester.com

2222

/feedupdated

response: == ?xml version='1.0'?
notifyResult success='false' msg='Error testing notification URL : A valid URL was not provided.' (I removed the brackets around the XML response)
.

pleaseNotify: success == undefined, msg == "undefined"

Again, my test app was running on port 2222. I am guess that, from Andrew's earlier comment, port 80 probably works, but the plugin should be able to respond to other ports besides 80.

I'll see about reaching out to the plugin author about #1.

#2 will most likely be the norm but I'll mention it to the author as well.

Just saw your comment, could some other function besides wp_http_validate_url be used? Is it even necessary?

wp_http_validate is not used specifically by the plugin, but rather deep in the code, starting with the wp_safe_remote_get function. so they only want to make calls to "safe" URLs, so I'll mention it to Joseph Scott (who works at Automattic) in the email, but ultimately it will be his call.

Got it - thanks! Also, thanks for adding some comments on the WordPress.com forum post.

I updated my test app to use port 8080 per your earlier comment, the app was able to successfully register with the RSS Cloud plugin, and the test app got a response from the plugin when I made a post on the test WordPress site.

feedUpdated: url == https://rsscloud.andysylvester.com/feed/, now == 12/7/2022, 6:48:22 PM
theFeed == "rssCloud"
"Test post 048"

👋 Hi!

On the port front, I'm not inclined to change it. WordPress and the RSSCloud plugin have been working this way for more than 7 years.

The scheme issue seems to be new, or at least something that may have changed in the last 7 years. I'll unwind that code path more and see what falls out. The already suggested idea of defaulting to HTTP when no scheme is provided sounds like a reasonable way forward.

Separately, it looks like there are couple of spots in the plugin that need updating to run under PHP 8. I'll look into that closer and get an update out if needed.

Thank you!

@josephscott — nice to see you here… long time. 🤪

Joseph, thanks for participating in this thread! I think that the WordPress-supported ports that Andrew Shell discovered (80, 443, or 8080) should be added to the WordPress.com support page (https://wordpress.com/support/rsscloud/) and the RSS Cloud plugin page (https://wordpress.org/plugins/rsscloud/). This information is useful for aggregator developers (currently, FeedLand (http://feedland.org/) by Dave Winer is not recognizing RSS Cloud support from WordPress.com feeds, probably due to the port issue).

@andysylvester — can you say simply what the issue is from FeedLand’s point of view?

Here are items from my debug session (https://andysylvester.com/2022/12/04/rss-cloud-support-in-wordpress-com-not-working/):

===

2. Made a post (https://rsscloud4.wordpress.com/2022/12/04/test-post-007/) at 2:18 pm, no response to my test script.

3. Checked in FeedLand for new item, did not see it until 2:28pm (10 minutes later). In testing of other tools creating RSS feeds with rssCloud support, the item would appear in FeedLand within a few seconds. I have noticed that feed readers seem to take up to 30 minutes to detect that there has been a change in a RSS feed from WordPress.com or WordPress.org sites.

@andysylvester -- i'm no closer to understanding why it not work. if you have that info, please share. thanks.

@scripting -- I think that when FeedLand attempts to register a WordPress.com RSS feed with the associated site, or to register a WordPress.org RSS feed with a site using the RSS Cloud plugin, the registration fails, and so the RSS feed updates in FeedLand for these sites occurs when FeedLand detects that the RSS feed has changed (I assume through the use of polling).

In the debug post I included in my earlier comment and in this gist thread, I have demonstrated how registration can fail for the RSS Cloud server in WordPress.com and WordPress.org sites. Since I can update feeds using Drummer/Old School and FeedLand's feeds (which are both using Andrew Shell's rssCloud server in the cloud element in the RSS feed) and see the response in FeedLand within seconds, this leads me to think that (1) WordPress.com and WordPress.org sites can only accept registration from scripts/applications on ports 80, 443, or 8080, and that FeedLand is not sending registration on those ports, so the registration fails and updated posts do not show up within seconds of the post going live, or (2) there is some problem in the FeedLand rssCloud implementation. Since FeedLand is really the only feed reader application that supports rssCloud (aside from the recent work by Colin Walker (scripting/reallysimple#11)), and I can demonstrate that two other feed generating tools appear to work correctly with FeedLand rssCloud functionality, I don't think (2) is the correct answer. I think (1) is the correct answer.

@andysylvester -- what i'm taking away from this is that when FeedLand attempts to register with WordPress it fails.

Also FeedLand is not the only aggregator that uses rssCloud. Don't make assumptions that you have no data for.

Let's start here.

http://feeder.scripting.com/returnjson?feedurl=https://unberkeley.wordpress.com/feed/

feeder.scripting.com is a web service that shows you exactly what FeedLand will get when it reads the feed.

As you can see the cloud element is on port 80.

If I understand correctly, this feed will work because WordPress is working properly as long as it's port 80.

Correct?

https://rsscloud4.wordpress.com/feed/ and https://rsscloud.andysylvester.com/feed/

The issue is not with the content of the cloud element. I think the issue is that the WordPress rssCloud server will not accept the notification URL from an application if it is not on ports 80, 443, or 8080.

I think it is poor form to make a comment asking for help in a negative way and then delete it (as the email thread from this gist shows). Please stand behind your words. I would like to work this out, but when you do things like that, I get the feeling you want it all "your way". Since you are the developer of FeedLand, only you can see what is happening in the app beyond the Javascript console. I have supplied a lot of data showing my investigation of the problems with the WordPress rssCloud implementation, but I can only investigate things from "the outside" for the most part.

@scripting -- you are correct, River5 also supports rssCloud. If you know of other aggregators that support rssCloud, I would be interested in testing them against this WordPress issue.

Andy please I'm just trying to figure out what's going on. I deleted the question because I thought of a much better simpler way to ask it.

Steps I took:

1. Have a new blog hosted on WordPress.com (ex https://andrewshell.wordpress.com/)
2. Post a new blog post (ex https://andrewshell.wordpress.com/2022/12/09/test-post-1/)
3. Add RSS feed of blog to FeedLand (By pressing "+ Feed" button, pasting URL, then OK)
   1. Example feed https://andrewshell.wordpress.com/feed/
4. See the first blog post in FeedLand
5. Add a new blog post (ex https://andrewshell.wordpress.com/2022/12/09/test-post-2/)

What I expect to see:

1. Test post 2 should be listed in FeedLand shortly after posting it

What I saw:

1. Test post 2 took about an hour to show up in FeedLand

Andrew, that result is consistent with my debug session (https://andysylvester.com/2022/12/04/rss-cloud-support-in-wordpress-com-not-working/). I did some experimenting with River 5 as a debug tool this afternoon. When I ran it on ports 443 and 8080, I was able to see the RSS Cloud plugin site update within a few seconds (https://rsscloud.andysylvester.com/). However the WordPress.com site did not update (https://rsscloud4.wordpress.com/feed/). I will add some test code tomorrow to look at the WordPress.com rssCloud server response. My suspicion is that WordPress.com sites need to have the notification URL on port 80, but I will check this tomorrow.

Andrew -- I'm looking into your report now.

One tool you have to see how rssCloud is working re this feed is going to the Feed Info page for the feed.

http://feedland.org/?feedurl=https%3A%2F%2Fandrewshell.wordpress.com%2Ffeed%2F

The Last renew number is the last time FeedLand successfully renewed the notification request with the feed's cloud server.

At this time the number is 20 hours.

Just a piece of data.

You can also get FL to check the feed immediately, the conventional way by clicking on the Check Now link

A screen shot.

A report on my experiment in the next comment.

1. First, it's hard/impossible for me to step through this in the debugger because the local version of FeedLand that I use for testing is behind a firewall, and can't participate in rssCloud stuff. So I'm testing using the deployed server.

2. I did find and fix an error. It was getting a 301 response, permanent redirect After fixing, the redirect is taking place.

3. Another error shows up when renewing andrewshell.wordpress.com -- <notifyResult success='false' msg='No feed for url1.' />

going to look into this now

I added some debugging code, and had it display the request to the console before it sends it off to wordpress.com.

theRequest == {
    "url": "http://andrewshell.wordpress.com:80/?rsscloud=notify",
    "followAllRedirects": true,
    "maxRedirects": 5,
    "headers": {
        "Accept": "application/json"
    },
    "method": "POST",
    "form": {
        "port": "1670",
        "path": "/feedupdated",
        "url1": "https://andrewshell.wordpress.com/feed/",
        "protocol": "http-post"
    }
}

I think my next step is going to be to assume that it's the "form" that's tripping up the server? Couldn't hurt to use the default of body instead of form. This came up in recent work with the Mastodon API. Back in a bit...

BTW -- I see another problem. Every time feedland.js launches it might be assigned a different port.

This means that if it should crash and be relaunched, it might be assigned a different port when it is relaunched. Or when I install a new version as I am now doing every few minutes while I test this.

The upshot is that it will be sending notifications to the wrong port until the subscriptions are renewed within no more than 24 hours.

Another BTW -- this feature went in a few days before the product was feature frozen before release, and there was no one in the test group who had anything remotely like the experience Andrew has with rssCloud, so I did some simple testing and let it go, figuring at some point people who cared about rssCloud would show up and we'd do exactly what we're doing now. 😄

Dave, we determined from our tests against the WordPress plugin that it only works if the aggregator is on ports 80, 443, or 8080 otherwise, it considers it an unsafe URL. So sending port 1670 shouldn't work.

Here's the new request.

{
    "url": "http://andrewshell.wordpress.com:80/?rsscloud=notify",
    "method": "POST",
    "followAllRedirects": true,
    "maxRedirects": 5,
    "headers": {
        "Content-Type": "application/x-www-form-urlencoded"
    },
    "body": "port=1670&path=%2Ffeedupdated&url1=https%3A%2F%2Fandrewshell.wordpress.com%2Ffeed%2F&protocol=http-post"
}

And the wordpress server is responding, as before, with <notifyResult success='false' msg='No feed for url1.'>

At this point I don't see anything more I can do, it looks to me like the call is correct, and the error message seems to say it didn't find the URL in the request.

I'll look to see if I can identify anything wrong with the request call. The one thing that I know won't work is using port 1670 because of the unsafe URL filter that had been discussed previously.

@andrewshell -- aha. okay that explains what's going on.

@josephscott and I worked out this protocol quite a few years ago and he may still be tuned in.

It's easy to imagine another piece of software putting different constraints on what port FeedLand can run on.

The odd thing is that feedland.org is as far as anyone outside the server is concerned running on port 80. I wonder what would happen if I just forced the port to be 80. Do you think they're calling me back by IP address or by a reverse DNS call or..?

I love this bullshit, it's fun (no sarcasm). 😄

Or force it to be 80 if the domain we're talking to is on wordpress.com! ;-)

Oh the humanity.

Also if that is the problem they surely could provide a better error message. I thought from the message they returned that it was a syntax error of some kind.

Doing port 80 might work. I did notice that feedland doesn't seem to support the GET verification path (with challenge param) for pleaseNotify with the domain specified. (See http://walkthrough.rsscloud.co/#challengeParameter)

@andrewshell -- okay that goes on my todo list. :-)

i do have another project that i'm working on that i must move forward today, and i want to think about my next steps here, because i don't want to hack something in here, it has to be maintainable and documented, otherwise it's sure to break in a few months when i forgot what i did here. feedland is a very diverse piece of software and docs and maintainability are huge priorities.

andrew thanks for your help with this. i really enjoy working with you.

@scripting No rush on this, I agree it needs to be done correctly. One thing I found with testing is that the error you're getting might be an issue with request, and might even be deliberate. I haven't dug into its source code yet, but it appears that even when followAllRedirects is true, it doesn't look like the body of the POST is present when the second call is made.

If you make the same call against https://andrewshell.wordpress.com/?rsscloud=notify instead (notice the https) it returns <notifyResult success='false' msg='Error testing notification URL : A valid URL was not provided.' /> which was because of the port number. I think having the form parameter is cleaner and wasn't the culprit.

The unfortunate solution is probably not to use followAllRedirects: true and watch for 301 and 302 status codes, and resend yourself with the location value in the header.

By using this wrapper instead of calling request directly it looks like the call does what you'd expect.

function requestFollowRedirects(theRequest, callback) {
    theRequest.followAllRedirects = false;
    request (theRequest, function (err, response, body) {
        if (parseInt(theRequest.maxRedirects) > 0 && [301, 320].includes(response.statusCode) && response.headers.location != null) {
            const newRequest = Object.assign({}, theRequest, { url: response.headers.location });
            newRequest.maxRedirects--;
            requestFollowRedirects (newRequest, callback);
            }
        callback (err, response, body)
        });
    }

Andrew, thanks for sharing your work! I appreciate it. I am still planning to do some testing today, but it is apparent to me from your investigation that processing of rssCloud feeds from WordPress.com and WordPress.org sites is going to require some additional work beyond what is currently in FeedLand, and probably also in River5.

@andrewshell -- I've made the change in how FeedLand requests notification, it does its own redirection as illustrated by your example.

I am about to deploy it on feedland.org.

but i don't have enough information about the wordpress server to know what domain name it's using to address my server, for all i know they're using the ip address. if they use anything other than feedland.org to send the notification, port 80 will not work.

i might be willing to do a little customization just for wordpress.com servers, but not unless i know what i'm doing. i'm not willing to even experiment with this on a live server. so we're kind of at an impasse. but at least it should work with your rsscloud server, which i assume does not care what port i'm running on, so there's that. ;-)

The WordPress server follows the rssCloud spec. So since you don't specify the domain in your call, it does a POST to your IP address with the specified port. If you want it to go to feedland.org:80, you'll need to specify the domain name and handle the appropriate validate endpoint where it's a GET request with url and challenge parameters. See http://walkthrough.rsscloud.co/#challengeParameter

@andrewshell -- thank you. that's the info i was looking for. it's as if i didn't write those words myself. 😄

For reference, the WordPress safe request calls being limited to 80, 443, and 8080 happen inside WordPress core at https://core.trac.wordpress.org/browser/trunk/src/wp-includes/http.php#L589 - so this applies broadly across WordPress installs, including WordPress.com.

I have a new version of feedland.org running, it makes a pleaseNotify request using this request object.

{
    "url": "http://andrewshell.wordpress.com:80/?rsscloud=notify",
    "method": "POST",
    "followAllRedirects": true,
    "maxRedirects": 5,
    "headers": {
        "Content-Type": "application/x-www-form-urlencoded"
    },
    "body": "domain=feedland.org&port=80&path=%2Ffeedupdated&url1=https%3A%2F%2Fandrewshell.wordpress.com%2Ffeed%2F&protocol=http-post"
}

The upshot of this, as far as I know -- we should now be cool with wordpress.com's servers.

The way to test it, I guess is with a wordpress.com hosted site, try renewing its subscription and see what happens?

Is this correct?

So I subscribed to this feed.

http://feedland.org/?feedurl=https%3A%2F%2Funberkeley.wordpress.com%2Ffeed%2F

Now I'm going to add a test post and see what happens.

Note I couldn't follow this in the debugger so I don't know if we correctly handled the challenge parameter.

Houston we have liftoff.

I was able to test with my WordPress blog and can concur that it appears to be working now.

Andrew, I just did a test with my WordPress.com blog (https://rsscloud4.wordpress.com/feed/), and it took 60 minutes for the post to appear on FeedLand. Could you perform another test with your feed (https://andrewshell.wordpress.com/feed/)? I will do some additional tests with my WordPress.com blog and my WordPress.org blog with the RSS Cloud plugin. Based on my test, it seems that FeedLand is still having problems with RSS Cloud for WordPress.com blogs.

@andysylvester I tried it again, and it's still working. It's possible you ran your test before FeedLand resubscribed. I'd test it again if I were you.

BTW you can see how long it's been since the last cloud renew by going to the Feed Info page for the feed.

http://feedland.org/?feedurl=https%3A%2F%2Frsscloud4.wordpress.com%2Ffeed%2F

In this case it was successfully renewed 13 hours ago.

It sounds like things are working now, at least with WordPress.com feeds.

The RSS Cloud plugin itself does still need to be updated. I'll get an update for that out this week.

I've released an updated version of the RSSCloud plugin ( 0.5.0 ) - https://wordpress.org/plugins/rsscloud/ - that includes the PHP 8+ fixes and the default scheme of HTTP when none is provided. Let me know if anything else comes up.

@scripting, thanks for the pointer on the cloud renew time, that is helpful.

I did two test posts from my WordPress.com site just now (https://rsscloud4.wordpress.com/feed/), both posts appeared in FeedLand within several seconds, so FeedLand support of rssCloud is working for me now. Thanks @scripting and @andrewshell for your help!

@josephscott - I will go ahead and download the new plugin and give it a test - thanks!

@josephscott - I updated to version 0.5 on my plugin test site (https://rsscloud.andysylvester.com/), made two posts, they have not appeared on FeedLand yet. Is there anything you would like me to check? The FeedLand sub to this site was renewed 2 hrs ago, should I wait for the next renewal to try again?

First thing I'd check is to review the error logs for the site, just to make sure nothing went sideways.

Next, is there anything on the site that would interfere with the WordPress cron feature? And does the site get plenty of page views, to give an opportunity for the cron feature to run.

It might also be worthwhile checking on the cron jobs inside the WordPress install, a plugin like https://wordpress.org/plugins/wp-crontrol/ should be sufficient for that.

@josephscott I will look at those items, thanks for the suggestions!

Good morning! I decided that now that I have a working implementation again and it's fresh in my mind, I should write an example app in JavaScript that implements the aggregator side of rssCloud.

I believe I have it working for notifications via POST, but have hit a snag with the notifications via GET.

My code assumes there will be a challenge parameter, and that it will not be used for a "real" notification of an update, that it will only be used as part of the notification request. But it seems it is being used for notification, and when that happens there is no challenge parameter (which would make sense).

The example I'm testing with is unberkeley.wordpress.com.

I'm going to assume that the description above is what's going on, and be prepared for a call without the challenge parameter.

If you want to see the actual code it's in this file.

https://github.com/scripting/reallysimple/blob/main/demos/clouddemo/clouddemo.js

BTW, in reviewing the walkthrough -- I desperately want to rewrite it. It has become very dated, and the links to examples are broken. However I'm not sure I will have the time for that, all the more reason it's important to have a good working example out there.

Update: As I'm debugging it further -- the challenge parameter does appear to be there even for real pings, not test pings. Still looking into it.

It only took me an hour to find a missing break; statement.

I've been programming for 800 years and I still make beginner's mistakes.

Never mind. ;-)

I couldn't leave a comment on the reallySimple repo for clouddemo.js (it appears to be locked), so I am leaving a comment here with my report. I was able to run the app on port 443 and successfully register a WordPress.com site and a WordPress.org site using version 0.5.0 of the WordPress RSS Cloud plugin. When I ran my test script on the WordPress.org site, it worked, but I figured out that the WordPress.org site is caching the RSS feed, which explains why feed updates were not seen by FeedLand.

@josephscott - I have looked at this Stack Exchange post for ideas on disabling caching of WordPress feeds, if you have any better ideas, I am interested.

The code for clouddemo.js looks good, I am pleased that it could run on port 443, since I already had an app running on port 80 on my server and did not want to change it.

@andysylvester are your referring to the RSS blog/widget caching the results of a feed? That would be the other end of this, you would need something to trigger an invalidation of the cached feed.

@josephscott I am not sure what you mean by "RSS blog/widget". My understanding is that WordPress uses SimplePie to generate the RSS feed of a WordPress website/blog. It appears to be common knowledge that WordPress itself caches the RSS feed of the site (see https://amandagiles.com/blog/code-snippets/updating-wordpress-rss-feed-cache-time/). To me, this is a problem for using rssCloud with WordPress, since most feed readers will not display new updates from the site if the feed it retrieves has not changed, even if it receives a response from an rssCloud server that the site has updated. In my opinion, for rssCloud use, the caching should be turned off or reduced to 5-10 seconds.

Here is my anecdotal evidence supporting this: I made posts on my WordPress.org site using version 0.5.0 of the RSS Cloud plugin. I made 3 posts and received three responses from the plugin (see this gist). However, the posts did not appear in FeedLand. I checked the URL of the feed in my browser (https://rsscloud.andysylvester.com/feed/), it was updated. I then did a curl command of the feed, and it had not updated. I then went to the Dashboard for my site, went to Settings/Readings, and changed the value of "Syndication feeds show the most recent x items" from 10 to 5. After doing that, the curl command returned the feed I was seeing in my browser, and eventually the posts showed up in FeedLand.

Following up on your last sentence, I think that the RSS Cloud plugin should trigger an invalidation of the cached feed so that feed readers will get the most recent version of the feed. Otherwise, the RSS Cloud plugin notification does not provide any benefit.

Sorry, my previous comment was supposed to be "RSS block/widget".

In terms of the RSS feed updating, I've run a few tests on a stock out of the box WordPress site and didn't see any problems with the RSS feed updating right away.

What you described with the feed being updated when you viewed it with the browser but not updated when done with curl sounds like it could be a caching difference based on cookies. Were you logged into the site with the browser you used to check the feed?

I went back to the fresh stock WordPress install for testing and still didn't have a problem with the feed updating when viewed logged out or logged in, so I don't think this is sufficient to explain what you saw either.

Are there any other plugins on the site you are using to test? Can you try it with a fresh WordPress install with no plugins and check to see if the RSS feed updates as expected.

@josephscott @andysylvester --

Once I got the FeedLand implementation working with WordPress and @andrewshell's server, I created a very simple demo app that just does the rssCloud functionality in FeedLand anyone can test with our implementation, and see exactly what's going on. MIT License.

https://github.com/scripting/reallysimple/tree/main/demos/clouddemo

It also provides a reference implementation for people just getting started.

At some point I need to rewrite the walkthrough. It's not very well done imho (I am the author).

@josephscott - I was logged into the site, so I will check on that. I really appreciate your feedback, and will work on testing today.

@scripting - I was already aware of your implementation (see this link to comment above), so I assume you are really leaving your comment for the benefit of @josephscott. I used your app to help figure out my current issue with the RSS Cloud plugin. Since it appears you have removed your block of my account on the reallySimple repo, I will post further feedback on your reference app on that repo in the future.

Well, I see it didn't take long to restore the block of my account...

@josephscott - Yesterday, per your suggestion, I created a new WordPress site (https://scott2.andysylvester.com/) and disabled all plugins, then installed version 0.5.0 of the RSS Cloud plugin, and was able to successfully see posts appear within several seconds on FeedLand, which would indicate that the plugin is working. I also checked the feed in the browser and using curl, and both contained the correct content. This morning, I decided to do additional tests using my test app and Dave Winer's test app. Both apps were able to receive the notification from new posts. However, posts did not appear in FeedLand. I also checked the feed in the browser and using curl, and both contained the correct content.

When I looked at the output of my app, which uses the readFeed function within the NPM reallySimple package to get the feed, the first title in the feed it read was for test post 8, although I had created a new test post. This behavior continued even though I made several additional posts. In the posts, I captured info on each state of testing. To me, if FeedLand was not seeing any changes in the feed, I can totally understand that it would not display anything from the feed. As I have commented before, this seems like a caching problem, but I am not sure where to look.

I do not fully understand what is happening here, but this behavior has now occurred on two different WordPress sites using the latest RSS Cloud plugin. I would like to work this out, because WordPress is the major creator of rssCloud-enabled feeds, and I want to use rssCloud and WordPress in a new project. @josephscott, I am willing to keep posting to this thread, or in some other forum to work this out, I appreciate the feedback you have given me, and want to run this problem down if I can.

From what you are describing, I'm not sure that this is directly related to the RSS Cloud plugin. You mentioned that it worked out of the box, with the feed showing the latest data and pings going out to FeedLand.

To track this down I think you are going to need more data. I'd recommend adding logging to every step, that what you can confirm when a step went missing that you were expecting to happen.

@josephscott - thanks for getting back with me. I did see it work "out of the box", but then saw this caching issue when I was running some supplemental test scripts. I will add some logging and report back on what I find.

@josephscott - I apologize for taking so long to get back to you on this thread. I found that my hosting provider (Bluehost) had a site-by-site caching setting that I was not aware of. I turned caching off, and I also uncommented line 12 in rsscloud.php within the WordPress RSS Cloud plugin. After taking those two actions, I was able to see WordPress posts within a few seconds on FeedLand and a separate tool I created. More info is available here: https://andysylvester.com/2023/02/23/solved-my-problem-with-wordpress-caching/. Thanks for your helpful suggestions!