Updating entry for function

I have submitted a PR to help make CP compatible with PHP 8: see https://github.com/KTS915/ClassicPress/commit/35569f24ca78f87d75c67c57f96d6ba3b5844ce8.

But we also need to update the documentation for the relevant function, which is _wp_delete_tax_menu_item.

This is what we currently have: https://docs.classicpress.net/reference/functions/_wp_delete_tax_menu_item/

And this is what it should be updated to: https://developer.wordpress.org/reference/functions/_wp_delete_tax_menu_item/

Is there a Github repo somewhere, where I can submit a PR? (If so, I couldn’t find it just now.)

1 Like

@smileBeda can correct me if I am wrong, but my understanding is once it is merged and released as part of a release it should automatically be updated (after we upgrade the docs site). I don’t believe there is any extra PR required to update it outside of that :slight_smile:

1 Like

Unfortunately parsing the code is a very time intensive task even if done with wp cli.
Thus, we cannot do that online on the live server.

We have to install a local copy of the site, an exact 1:1 copy. Then we have to run the parser (obviously using the latest, updated stable CP version). That will regenerate the Code Reference.

Then we can export and import those with an import tool I have installed on the live site.

This is the current process. It can only be done after the actual stable release is out (in other words, once CP is available as a stable release 1.3.0 in this case, and the master of git is been updated with that as well.)

NOTE:
If it where so that zero line numbers of the code changed whatsoever then we would not need to do this process. (I mean: code may change, but position in file could stay the same).
But this is almost never the case, thus the process needs to be run at least each “major” update of CP (which luckily there aren’t that many).
NOTE2:
After the first re-import of data from local parser to online site, technically, we wont have to re-import the whole bunch of code ref’s anymore next time but only those which changed since lasts export/import. This however assumes that we use the import tool I tested and none other (at least, I do not know of any other import tool that has this feature)

WP Itself solves that with jetpack and some cron events etc, which is basically the same, just more distributed and thus also more complex.

However, be it how it is, we will not have to keep track of the changes made in code.
The parser will do this all for us. We just need to re-run it and re-import things using a 1:1 copy of the live site, that’s it.

The release process for WP includes a task to run the doc parser, so the Code Reference is updated.
If we don’t have a documented release process, maybe that should be established.

2 Likes

Why not have the code parser run on the server every day or every week as a background job?

2 Likes

I thought it was an involved process to get the output into the docs site. And why would it need to run when nothing changes between releases?

If this is not a security and performance concern to run on the server, we could at least run wp parser create . --user=user_id_here
But the online instance is not ready for this, it misses the plugin and the theme also was adapted to not run the parser - as opposed to the local instance.

I thought this would be Major performance issue to run online (it takes like an hour locally at least to complete).

Certainly if this is no headache with performance and security, it might be the smarter solution, of course.

1 Like

If this is true then it needs to be fixed.

A job could run every day that checks if there is a new stable release, and if so, re-runs the parser on that release.

Security definitely needs to be analyzed more: how could someone break this and what would we need to look out for? My guess is that someone would need to push through a malicious PR and get it included in a release. Definitely not impossible, especially as CP continues growing over time.

Performance shouldn’t be a problem because this would run as a background job, not as a web request associated with someone visiting the site.

2 Likes