Docs: Fully qualify the SimplePie cache type in a WP_Feed_Cache_Transient docblock.

[CallumBW95]

✅ Committed in r63181 (e2ae46d).

---

The @param annotation for $type on WP_Feed_Cache_Transient::__construct() documents the type as Base::TYPE_FEED|Base::TYPE_IMAGE. WP_Feed_Cache_Transient is declared in the global namespace and imports nothing, so PHPStan resolves the bare Base to \Base, which does not exist anywhere in core. That is the single parameter.unresolvableType occurrence in the baseline:

PHPDoc tag @param for parameter $type contains unresolvable type.
  src/wp-includes/class-wp-feed-cache-transient.php

Qualifying both constants fixes the reference. The annotation is the only thing that changes, so there is no behaviour to affect.

-	 * @param string                           $location URL location (scheme is used to determine handler).
-	 * @param string                           $name     Unique identifier for cache object.
-	 * @param Base::TYPE_FEED|Base::TYPE_IMAGE $type     Either `TYPE_FEED` ('spc') for SimplePie data,
-	 *                                                   or `TYPE_IMAGE` ('spi') for image data.
+	 * @param string                                                           $location URL location (scheme is used to determine handler).
+	 * @param string                                                           $name     Unique identifier for cache object.
+	 * @param SimplePie\Cache\Base::TYPE_FEED|SimplePie\Cache\Base::TYPE_IMAGE $type     Either `TYPE_FEED` ('spc') for SimplePie data,
+	 *                                                                                   or `TYPE_IMAGE` ('spi') for image data.

This empties tests/phpstan/baselines/parameter.unresolvableType.neon, so the file is deleted along with its includes entry in phpstan.neon.dist, per the instruction in the baseline's own header.

Where the annotation came from

SimplePie\Cache\Base carries the same line in the bundled library, at src/wp-includes/SimplePie/src/Cache/Base.php:39:

* @param Base::TYPE_FEED|Base::TYPE_IMAGE $type Either TYPE_FEED for SimplePie data, or TYPE_IMAGE for image data

There it is correct, because that file opens with namespace SimplePie\Cache; and Base resolves to the interface being declared. The line was carried across to the core implementation in r59141 (2024-09-30), the SimplePie 1.8.0 update that namespaced the library and updated WP_Feed_Cache_Transient to match the new interface signature. The destination file has no namespace and no use statement, so the shorthand stopped resolving at that point and has been baselined ever since.

The rest of the file already spells the interface out in full: the class declaration reads implements SimplePie\Cache\Base, the @since 6.7.0 line in this same docblock says SimplePie\Cache\Base, and save() below annotates array|SimplePie\SimplePie. Qualifying the constants makes the @param consistent with its neighbours rather than introducing a new convention.

Adding use SimplePie\Cache\Base; would be shorter, but only two files in the root of wp-includes/ use imports at all, both added recently, so a use statement here would be the novel choice. Fully qualifying keeps this a documentation-only change.

On the column widths

The type column widens by 32 characters, which pushes the longest line in the block to 137 characters. Keeping the @param name and description columns aligned is what the inline documentation standards ask for, and there is ample precedent: 47 @param lines in src/wp-includes/ are already 137 characters or longer, the longest being 189. composer lint passes on the file either way, so this is alignment rather than a constraint.

Testing instructions

1. On trunk, npm run typecheck:php reports [OK] No errors, because the occurrence is baselined.
2. Delete tests/phpstan/baselines/parameter.unresolvableType.neon and its includes entry, then run it again. PHPStan reports PHPDoc tag @param for parameter $type contains unresolvable type. in src/wp-includes/class-wp-feed-cache-transient.php.
3. With this branch applied, npm run typecheck:php reports [OK] No errors with the baseline gone and nothing new elsewhere. The baseline directory goes from 73 files to 72.
4. Regenerating confirms the baseline is genuinely empty rather than hand-removed:

   composer phpstan:baselines -- --identifier=parameter.unresolvableType
   

   It reports no remaining errors and leaves both deletions in place.
5. composer lint is clean on the changed file.
6. npm run test:php passes: 30853 tests, 4559514 assertions, 86 warnings, 44 skipped, exit 0, no failures or errors. Run against this branch at 996c6d6864.

Trac ticket: https://core.trac.wordpress.org/ticket/65817

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: tracing the unresolvable type to the missing namespace context, git log -S archaeology identifying r59141 as the origin, checking the bundled SimplePie source for the original annotation, surveying existing use statements and @param line lengths across wp-includes/, and drafting this description. The diagnosis, the choice to fully qualify rather than add an import, the baseline regeneration, and verification against full PHPStan, PHPCS and PHPUnit runs were reviewed and confirmed by me in a local development environment.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props callumbw95.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.