Functions broken links at plugin editor

[mehedi890]

I found some broken links at plugin editor. I'm currently using WordPress 5.8.3 version. Here is the list of Functions & Classes:

1. WC() ​https://developer.wordpress.org/reference/functions/WC/
2. WP_Query() ​https://developer.wordpress.org/reference/functions/WP_Query/
3. wc_get_checkout_url() ​https://developer.wordpress.org/reference/functions/wc_get_checkout_url/
4. wc_get_template_part() ​https://developer.wordpress.org/reference/functions/wc_get_template_part/
5. woocommerce_product_loop_end() ​https://developer.wordpress.org/reference/functions/woocommerce_product_loop_end/
6. woocommerce_product_loop_start() ​https://developer.wordpress.org/reference/functions/woocommerce_product_loop_start/
7. woocommerce_template_loop_price() ​https://developer.wordpress.org/reference/functions/woocommerce_template_loop_price/

Here is the attachments: ​https://prnt.sc/26ijpd7 ​https://prnt.sc/26ijrrh

[SergeyBiryukov]

Hi there, welcome to WordPress Meta Trac! Thanks for the report.

Just copying my response from ​#WP54891 for some more context.

It looks like most of these functions come from WooCommerce and not from WordPress core, so they don't exist in the function reference.

The ​Look Up button in the plugin/theme editor appears to send the function name to an endpoint like this:
​https://api.wordpress.org/core/handbook/1.0/?function=woocommerce_template_loop_price
which then redirects to the resulting URL.

Apparently the endpoint needs some adjustment to avoid linking WooCommerce functions to the WordPress core function reference.

[mehedi890]

WP_Query class is also in there
WP_Query() ​https://developer.wordpress.org/reference/functions/WP_Query/

I think this also needs to be fixed.

[SergeyBiryukov]

Right, the correct URL for WP_Query would be this one:
​https://developer.wordpress.org/reference/classes/wp_query/

[coffee2code]

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 ​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 ​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.