@anon66243189 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
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.
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.
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.
