[wp-meta] [Making WordPress.org] #6039: Functions broken links at plugin editor

[Making WordPress.org]

#6039: Functions broken links at plugin editor
-------------------------+----------------------
 Reporter:  mehedi890    |       Owner:  (none)
     Type:  enhancement  |      Status:  closed
 Priority:  low          |   Milestone:
Component:  API          |  Resolution:  wontfix
 Keywords:               |
-------------------------+----------------------
Changes (by coffee2code):

 * priority:  normal => low
 * resolution:   => wontfix
 * status:  new => closed
 * component:  Developer Hub => API
 * type:  defect (bug) => enhancement


Comment:

 Thanks for the report!

 The case of `WP_Query` or any other class being requested as a function
 (and more broadly, any parsed post type that isn't found is looked for as
 any other parsed post type) as of [https://github.com/WordPress/wporg-
 developer/commit/fcfebee0d0d239a12818c44a496d3e8fecb5f140 wporg-
 developer/fcfebee]:

 > Redirects: Redirect 404 request to a single parsed post type to a match
 in another parsed post type.

 As for the issue of links to non-WP functions pointing to nonexistent Code
 Reference pages... it's not easily mitigated and probably not worth the
 effort to implement and maintain (especially for something not widely
 used).

 For this plugin editor functionality, Core uses
 [https://developer.wordpress.org/reference/functions/wp_doc_link_parse/
 wp_doc_link_parse()] on every .php file to extract functions. That is only
 modified by the 'documentation_ignore_functions' hook, and thus is a
 straightforward list of all used functions. No checks occur to see if the
 function belongs to WP or not. All functions blindly link to the
 api.wordpress.org/core/handbook/1.0/ endpoint.

 That endpoint does not do anything too intelligent either. If the function
 is a PHP function, it'll redirect to the php.net documentation for it.
 Otherwise, it assumes it is a WP function and redirects to the Developer
 Code Reference as if the function documentation existed. The endpoint has
 no knowledge of what is an actual WP function (and doesn't even load WP
 itself).

 Getting a 404 is the expected outcome for a non-WP class or function such
 as `WC()`. The endpoint couldn't possibly know what all non-WP functions
 relate to and where they are documented (assuming they are). So as far as
 the endpoint is concerned, that's probably as good as this will be.
 Ideally WP wouldn't link non-WP functions/classes (which happens before
 the endpoint is involved). However, WP wouldn't know anything about that
 without calling out to a different (and smarter) endpoint (and awaiting
 its response) or already having that information baked into WP or
 extracted from the running WP instance.

 Ultimately, I consider this is a wontfix, though I fully acknowledge the
 current situation isn't ideal.

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/6039#comment:4>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org