Check __autoload() | Function | ClassicPress Documentation, then click View on Git, which leads to ClassicPress/src/wp-includes/spl-autoload-compat.php at 981da77ffa596fe3b1759c910cdb7b4021b03bc2 · ClassicPress/ClassicPress · GitHub which is not featuring the same code as in the doc, and more importantly - the code in the master GIT is not the same code as I have in any of my (up to date) CP installs.
In current CP install that file reads as it should, in versions prior to 5.3 this function still exists and the file is with code, not deprecated, on my instals I can see the code in the files as expected.
The only that I can explain this to myself is that master Git is not the same as stable tag 1.2.0
Which is IMO weird because master in Git reflects the last stable code, or am I wrong?
And if I am wrong, where can we link to so we get the actual up to date code in Git?
All releases are here:
For the stable 1.2.0 you can see the code here:
1 Like
Great
That means our master is not sync with our stable release and thus, all doc “view on GitHub” links are pointing to wrong source
Can I ask why we don’t keep master in sync with the release?
Isn’t this how generally the purpose of master is defined?
I might be missing something of course- it’s just how I usually do it.
I’ll either have to change the point links on doc or we’ll have to sync master regularly with latest stable release
The code in ClassicPress/ClassicPress gets built using (release-builder) into the code you see in ClassicPress/ClassicPress-release which is then ultimately what is pushed to api endpoints to be upgraded to.
To add, the master branch in the ClassicPress-release is the most up to date version of the code (ie. you will see we merged 1.3.0-rc1 into it), so for the docs page it may make more sense to pull the latest not pre-release tag from the release repo, which has its own tree:
https://github.com/ClassicPress/ClassicPress-release/tree/1.2.0
2 Likes
Yes, it shouldn’t point to master. That’s why at WP, it’s a release task to run the parser (once per release).
This has nothing to do with the parser.
To make that clear again, the parser does not run against any remote code.
It runs locally and the parser does get the right code, if you consult the DOC you can see it is correct.
What is not correct, is the link that points to git. I chose master because I thought master is … well, master. I stand corrected, and will point the thing towards the whatever last stable tag. This adds complexity because the link now needs to take a dynamic version number but it is of course doable.
Will amend the code asap on site.
1 Like
Ya sorry, probably should have mentioned this earlier, I don’t think it clicked until you asked the question above.
1 Like
This is done.
We probably should document the fact that in CP, we have both a global $wp_version (returning the forked WP Version number I believe it was 4.9.15 or so) and a global $cp_version, which returns the installed CP version.
And probably this is a good moment to think about providing a function for this that does not call remote like wp_version_check does and which would return non-useful data on a CP install.
I think this is important as has been mentioned prior by others:
We need to first document what we plan to change, then change it. Discovering later that we changed something for a non-core dev is just as annoying as discovering the WP User Object is a mess 
Anyway, resolved.
3 Likes