author feed having an issue on latest WP6.4 version

[janareddy]

Team,

The author feed Ex:(www.google.com/author/author-name/feed/) is having issue on WP6.4.

currently we are using PHP8.1 and WP6.1 on this combination author feed is working as expected.

Recently we are trying to upgrade to WP6.4 , PHP version will be same(PHP8.1) this combination is having issue on author feed.

Below is the error we are getting
Uncaught ValueError: max(): Argument #1 ($value) must contain at least one element

as per little debug it seems in feed.php on line number 720 max() command having issue , its expecting array but date string is passing.

please go through this link for more details ​https://wordpress.org/support/topic/having-an-issue-on-author-feed-on-wp-6-4/

as suggested i am raising a ticket here, could you please check this.

[hellofromTonya]

Hello @janareddy,

Welcome back to WordPress Core's Trac :) Thank you for opening this ticket and referencing ​the discussion in the support ticket.

as per little debug it seems in feed.php on line number 720 max() command having issue , its expecting array but date string is passing.

Hmm, I'm not seeing how a string is being passed to max() in the get_feed_build_date() function as $modified_times will always be an array. But that said, the error you noted indicates $modified_times is an empty array.

Passing an empty array to max() is a Warning on < PHP 8 or a ValueError on >= PHP 8. See it in action ​https://3v4l.org/AaEOD and more information is available ​in the PHP manual.

Looking at the code, this area of the code runs when there are posts to process. $modified_times will contain an array of the posts' 'post_modified_gmt' values. For $modified_times to be an empty array, the data in $wp_posts->posts would either be empty or not have 'post_modified_gmt' field / value.

I'm not seeing how this was introduced in 6.4 specifically. Wondering if the issue was existed on your site(s) previously, maybe as a PHP Warning in your server logs.

To help contributors investigate and reproduce the issue, need some more information please:

if you see the live feed page ​https://spearswms.com/author/janechurch/feed/ this is running on WP6.1 and no issue. when we update to WP6.4 on Dev branch.

• Was the site previously on WP 6.1 also running on PHP 8? Or was the upgrade to WP 6.4 along with upgrading to PHP 8?

• On the sites not running WP 6.4, are there PHP Warnings for max() in the server logs?

[janareddy]

The live site (​https://spearswms.com/author/janechurch/feed/ ) running on PHP 8.1 and WP 6.1

the branch we have tried is PHP 8.1 and WP6.4 (on this case we are getting error).

## Trac Ticket

See https://core.trac.wordpress.org/ticket/59956

## Description

get_feed_build_date() passes the result of wp_list_pluck() directly to max() without checking for an empty array. When the query's post objects lack the post_modified_gmt property, wp_list_pluck() returns an empty array and max() throws a ValueError on PHP 8.0+.

This happens in production when bots request RSS feed URLs (e.g. /author/{name}/feed/, /taxonomy/{term}/feed/) for terms or authors with zero published posts. The have_posts() guard on line 722 passes (the query object exists and has a truthy post_count), but the underlying post objects are incomplete — so wp_list_pluck( $wp_query->posts, 'post_modified_gmt' ) returns [].

On PHP 7.x this was a silent warning. On PHP 8.0+ it is a fatal ValueError that returns HTTP 500 to the crawler.

## The Fix

Wrap the max() call in if ( ! empty( $modified_times ) ). When the array is empty, $datetime remains false and falls through to the existing get_lastpostmodified( 'GMT' ) fallback on line 741. No behavioral change for feeds that have valid post data.

## Testing

Automated: Added test_should_not_error_when_modified_times_is_empty to tests/phpunit/tests/date/getFeedBuildDate.php. The test simulates a query where have_posts() is true but posts lack post_modified_gmt, and verifies the function falls back to get_lastpostmodified() instead of throwing.

Manual (production): Verified on a WordPress 6.9.4 multisite (PHP 8.4) with 1,175 artist taxonomy terms that had zero published posts on the main site. Before the fix, these feed URLs returned HTTP 500 with ValueError: max(): Argument #1 ($value) must contain at least one element. After the fix, all return HTTP 200 with valid empty RSS feeds. Normal feeds with posts are unaffected.

• Tested 12 edge cases: empty taxonomy feeds, populated category feeds, author feeds, comment feeds, main site feed, cross-subsite feeds
• Monitored debug.log — fatal errors stopped immediately after applying the fix (were firing every 10–20 seconds prior)
• Feeds with posts still return correct <item> elements and <lastBuildDate>

## AI Disclosure

AI assistance: Yes
Tool(s): Claude Code (Claude Opus 4)
Used for: Identifying the root cause from production debug logs, drafting the guard condition, and scaffolding the unit test. Final implementation, testing, and PR description were reviewed and edited by a human contributor.

[extrachill]

This bug caused a ton of 500 errors on my website. This fix should be included in 7.0.

Thanks so much for the thorough review @westonruter — really appreciate you showing up for this one. All five suggestions applied in 6b4c4c3d9d:

• ! empty( $modified_times ) → if ( $modified_times ) (will bookmark WordPress/performance#1219 for future contributions)
• Replaced the manual $wp_query property mutation with query_posts( [ 'posts__in' => [ $id ], 'fields' => 'ids' ] ) — much cleaner, and the 'fields' => 'ids' trick to make wp_list_pluck bail naturally is a nice pattern I hadn't seen before
• Added $this->assertIsString( $result ) before the strtotime() calls to narrow the string|false return type for PHPStan

Ready for another look whenever you have a minute.

@westonruter — investigating the feed bug here led me straight to a sibling defect on the XML sitemap side, and your "is this masking a lower-level issue?" question is exactly what flushed it out.

I've opened Trac #65375 with a clean-room reproduction. Short version:

A paginated core sitemap sub-page (wp-sitemap-posts-<cpt>-N.xml) is served HTTP 404 once N exceeds the blog (post) sitemap page count — even though WP_Sitemaps renders a valid <urlset> for that page. The status tracks the regular-post count, not the requested subtype.

Same structural pattern as this feed ticket: a virtual route whose status is decided by the unrelated dummy main query. The sitemap rewrite maps wp-sitemap-posts-<cpt>-N.xml → index.php?sitemap=posts&sitemap-subtype=<cpt>&paged=N with no post_type, so the dummy main WP_Query defaults to post. WP::handle_404() runs against that on the wp action and 404s once paged exceeds the blog page count — before WP_Sitemaps::render_sitemaps() runs on template_redirect and emits the correct XML. The renderer never resets the status back to 200.

The kicker: WP_Sitemaps::redirect_sitemapxml() used to be a pre_handle_404 guard that prevented exactly this, but it was deprecated in 6.7.0 when sitemaps moved to rewrite rules, and nothing replaced the bypass. Proposed fix in the ticket is to restore a pre_handle_404 short-circuit for sitemap/sitemap-stylesheet routes (the renderer already owns the legitimate empty-page 404).

Reproduction harness (Playground recipe, clean WP 7.0, no plugins) is attached to the Trac ticket. Figured you'd want the sitemap-lead heads-up given you caught the feed version of this.

Patch + tests up as a PR against trunk: WordPress/wordpress-develop#12019.

There seems to be going a lot of noise on this Pr with comments and references, so I'm a bit lost. Is this still relevant? From what I see, the change to get_feed_build_date() wouldn't be a bad thing to harden, although it is very unlikely that the issue would be encountered.

@westonruter I was back down the rabbit hole this weekend because I was getting tons of 500 errors again, and a related sitemap 404 error.

I might have stopped it from happening on my site via one of the downstream changes, but I have to check the logs.

I seem to be revisiting this every so often when working on my personal site and finding a massive debug.log file.