SAT

Looks like we have the same problem on one of our sites.

Update: I was able to resolve the issue by setting a redirect from the old /feed/podcast/ URL to the new location of the podcast feed. I’m marking this issue as resolved.

I followed those steps, but it doesn’t appear to have changed the feed URL. When I go in to the post type podcasting section, it says, “Your podcast RSS feed:?https://www.redvillagechurch.com/sermons/feed/podcast/“

Okay, it looks like the issue was related to how I set up the Custom Post Type UI plugin (to replace what the site was previously doing with Toolset Types plugin). The new plugin set the “has_archive” value on the “sermons” post type to “false,” but it looks like the PowerPress documentation says needs to be switched to true.

However, when I switch that attribute to “true,” it looks like PowerPress creates a new RSS feed at a different URL:
https://www.redvillagechurch.com/sermons/feed/podcast/

But this is a different location from where the podcasting services have been expecting the feed to be. The correct URL should be this (without the /sermons/ section):
https://www.redvillagechurch.com/feed/podcast/

How do I update the PowerPress settings so that the custom post type podcast episodes get added to the main podcast feed and not a separate feed?

• This reply was modified 1 year, 3 months ago by SAT.

The feed was set up years ago using an old plugin to set up custom post types. The plugin was eventually abandoned and didn’t work with the latest version of PHP, so I replaced it with a different plugin that created custom post types. I think something in that process (either upgrading PHP or switching the custom post type plugin) is what made the podcast feed stop working but I don’t know how to fix it.

I also tried going in to the custom post type settings in Powerpress, and everything still looks right. But after I hit “save” again on the feed settings, I went back to the feed page and it looks like even the podcast episodes from a few weeks ago are now no longer showing up there.

https://www.redvillagechurch.com/feed/podcast/

It looks like running this database update fixed the issue. Thank you!

Okay, great. Thanks for letting me know.

Five of my sites gave WordPress white screens, apparently due to WP-Rocket Lazy Load. Disabled all plugins, then re-activated one-by-one, and I got this error when activating Lazy Load:

Fatal error: Uncaught Error: Class ‘RocketLazyLoadPlugin\Plugin’ not found in […]/wp-content/plugins/rocket-lazy-load/main.php:9 Stack trace: #0 […]/wp-content/plugins/rocket-lazy-load/rocket-lazy-load.php(75): require() #1 […]/wp-admin/includes/plugin.php(2288): include_once(‘[…]/l…’) #2 […]/wp-admin/plugins.php(192): plugin_sandbox_scrape(‘rocket-lazy-loa…’) #3 {main} thrown in […]/wp-content/plugins/rocket-lazy-load/main.php on line 9

It seems to be resolved for me. I’ve tested it on one of my websites (and I set the “cache lifespan” in the advanced settings to 0 days). It appears to be deleting out cache files older than 24 hours, which keeps the size of the wpo-minify folder fairly small.

The note on that setting says that keeping stale minify files is important for external page caching, but I am only using WPO for page cache, so I’m assuming that should be fine that I’m not keeping any stale cache files around.

@leandroprz – that makes sense to me because v3.2.1 just came out on Nov. 29, and it was around that time that the disk space started getting filled up on my server. And looking at the release notes, it does seem like there were significant changes to the minify cache in v3.2.1.

To make it clearer what I’m talking about, I’d like to give specifics of my server.

I have a VPS with 90GB of space (about 84GB usable for websites). I have 28 websites on the server, and they were consistently using about 60 GB of space before Dec. 1. Then, from Dec. 1 to Dec. 5, the amount of disk space I was using gradually shot up to 84GB, at which point it maxed out and sites started going down.

I literally deleted the wpo-minify folder on only 4 sites and disabled the WPO plugin on those sites, and my total “used disk space” went from 84GB to 42GB. So the WPO minify cache for just 4 sites was taking up half of the disk space on the whole server (and presumably would have kept going if I had more space available).

As I said before, all 4 of the sites that had major issues are older WP sites that have been recently updated / revamped, and the sites with more total blog posts had a more serious issue with the minify cache.

@bornforphp Is this snippet only just changing the expiry from 30 days to 3 days? How much space do you expect a days’ worth of cache to take up? For a ~300-400mb WordPress installation, the minify cache was taking up more than 10 GB.

Even if it was caching an entire copy of the website once per day (which it shouldn’t be doing, right?), it still shouldn’t be that big even if it was keeping 30 copies of it.

Maybe I’m missing something, but isn’t this folder just supposed to have minified (i.e. smaller) versions of JS and CSS files? That should be pretty small, right?

On a different site on the same server, for example, the wpo-minify folder takes up only 3mb. And that’s for a website that is about the same size (300-400mb WordPress installation). Another site, a WP installation just over 400mb, has a wp-minify cache just under 200mb.

I did notice a pattern that it seems like the issue is much worse for older sites with a lot of posts in them. The sites that have been newly created in the last few years don’t seem to have an issue with the wpo-minify folder.

I don’t mind trying the code snippet to see if it helps, but I’d like to understand a little more of what’s going on.

Thank you for your quick response!

If that’s the case, could you remove the field entirely, so others don’t get confused like I did? Or at least add a note in a label that says this won’t work until Google changes how it handles the data?