classicpress / classicpress-apis Goto Github PK
View Code? Open in Web Editor NEWClassicPress API endpoints
Home Page: https://api-v1.classicpress.net/
License: GNU General Public License v2.0
ClassicPress API endpoints
Home Page: https://api-v1.classicpress.net/
License: GNU General Public License v2.0
Add a latest.json
file (and maybe a latest.zip
redirect too) that is refreshed along with the rest of the upgrade data. See: https://github.com/ClassicPress/ClassicPress-APIs/blob/c981cf1/v1-upgrade-generator/generate-upgrade-json.py
As ClassicPress/ClassicPress-v1#194 we need to add the translation endpoint.
The original code of wordpress for that is at https://meta.svn.wordpress.org/sites/trunk/api.wordpress.org/public_html/translations/
I am looking on that
This line should have the second parameter set to true
to indicate an error.
From ClassicPress/ClassicPress-v1#238:
Under https://github.com/ClassicPress/ClassicPress-APIs there are basic endpoints https://api.classicpress.net/core/stable-check/1.0/ and https://api.classicpress.net/core/version-check/1.0/.
These need to be made dynamic and pull information from GitHub about Releases zip files (with caching on the server), which we will use for update hosting initially.
We need someone to record and analyze the responses that come back from the WP core update endpoints for various WP configurations:
We also need to come up with a strategy for handling localized releases and alpha/beta/"final" release channels.
Looks like we're missing an API:
https://api.wordpress.org/core/importers/1.1/
This is a list of all the importer plugins. Since we're forking WordPress Importer plugin, we should have our own API and a list of plugins. This is where it's used in the core:
https://github.com/ClassicPress/ClassicPress/blob/22675efaf13b457f43f961809ca4ef202bf02dd7/src/wp-admin/includes/import.php#L145
This seems to be a simple JSON list.
One possible obstacle is core implementation may require some changes because ClassicPress Importer plugin will be listed in our directory. The "Install Now" button for this plugin might need to be changed to install the plugin from our directory instead of WordPress repository.
Let's build out a basic API endpoint that shows data from https://vote.classicpress.net/. We'll use this in the dashboard to replace WordPress events.
The response data should have three sections: most_wanted
, trending
, and recent
, matching the data on the site.
For now, the endpoint can just be a static response like the others. This will be enough to proceed with the UI implementation.
See also: ClassicPress/ClassicPress-v1#236
Please refer to: ClassicPress/ClassicPress-v1#238
See: https://forums.classicpress.net/t/classicpress-checksums-api/1596
Please leave other links and information here.
It should be easy to switch a ClassicPress site to receive updates from all beta versions, RC versions, and possibly alpha versions too. This is currently supported for nightly builds but not for any other "channels".
Add support to check for the current valid PHP versions.
https://api-v1-test.classicpress.net/upgrade/
The list of items here is quite long now!
We should separate it into two sections like "release" and "nightly" to make it easier to quickly find what you're looking for.
In the future there should probably be 4 sections:
With the new voting plugin finally installed we can swap out the api endpoint from the Fider archive.
most-wanted: https://forums.classicpress.net/c/governance/petitions/77.json?order=votes
trending: https://forums.classicpress.net/c/governance/petitions/77.json?order=latest
recent: https://forums.classicpress.net/c/governance/petitions/77.json?order=created
We have two core endpoints that seem to be doing nothing:
They correspond to WordPress APIs:
These look like static JSON lists. We should be able to set this up. There's no reason to have outdated endpoints. If we don't need them, maybe we should remove them.
Here is the basic idea:
1.2.3 => 2.0.0
)Open question: this means that all auto-updates will eventually funnel towards final release builds and stay there. Is this desirable? We may need an option for whether to stay on the same "release channel" (nightly, alpha, beta, final) or not (or the ability to "switch channels").
From @invisnet here are some possible auto-update before => after
versions (lines without =>
mean "no change"):
Step 1
======
1.0.0-alpha1+build.20181021 => 1.0.0-alpha1+build.20181021
1.0.0-alpha1+build.20181020 => 1.0.0-alpha1+build.20181021
1.0.0-alpha1 => 1.0.0-alpha1
Step 2
======
1.0.0-alpha1+build.20181021 => 1.0.0-alpha1+build.20181021
1.0.0-alpha1+build.20181020 => 1.0.0-alpha1+build.20181021
1.0.0-alpha2 => 1.0.0-alpha2
1.0.0-alpha1 => 1.0.0-alpha2
Step 3
======
1.0.0-alpha1+build.20181021 => 1.0.0-alpha1+build.20181021
1.0.0-alpha1+build.20181020 => 1.0.0-alpha1+build.20181021
1.0.0-alpha2 => 1.0.0-beta1
1.0.0-beta1 => 1.0.0-beta1
1.0.0-alpha1 => 1.0.0-beta1
Step 4
======
1.0.0-beta1 => 1.0.0-beta1
1.0.0-alpha2 => 1.0.0-beta1
1.0.0-alpha1 => 1.0.0-beta1
1.0.0-beta2+build.20181028 => 1.0.0-beta2+build.20181028
1.0.0-alpha1+build.20181021 => 1.0.0-beta2+build.20181028
1.0.0-alpha1+build.20181020 => 1.0.0-beta2+build.20181028
Step 5
======
1.0.0-beta2 => 1.0.0-beta2
1.0.0-beta1 => 1.0.0-beta2
1.0.0-alpha2 => 1.0.0-beta2
1.0.0-alpha1 => 1.0.0-beta2
1.0.0-beta2+build.20181030 => 1.0.0-beta2+build.20181030
1.0.0-beta2+build.20181028 => 1.0.0-beta2+build.20181030
1.0.0-alpha1+build.20181021 => 1.0.0-beta2+build.20181030
1.0.0-alpha1+build.20181020 => 1.0.0-beta2+build.20181030
Step 6
======
1.0.0-beta2 => 1.0.0
1.0.0-beta1 => 1.0.0
1.0.0 => 1.0.0
1.0.0-alpha2 => 1.0.0
1.0.0-alpha1 => 1.0.0
1.0.0-beta2+build.20181030 => 1.0.0+build.20181031
1.0.0-beta2+build.20181028 => 1.0.0+build.20181031
1.0.0-alpha1+build.20181021 => 1.0.0+build.20181031
1.0.0-alpha1+build.20181020 => 1.0.0+build.20181031
1.0.0+build.20181031 => 1.0.0+build.20181031
Step 7
======
1.0.0-beta2 => 1.1.0-alpha1
1.0.0-beta1 => 1.1.0-alpha1
1.0.0 => 1.0.0
1.1.0-alpha1 => 1.1.0-alpha1
1.0.0-alpha2 => 1.1.0-alpha1
1.0.0-alpha1 => 1.1.0-alpha1
1.0.0-beta2+build.20181030 => 1.1.0-alpha1+build.20181101
1.1.0-alpha1+build.20181101 => 1.1.0-alpha1+build.20181101
1.0.0-beta2+build.20181028 => 1.1.0-alpha1+build.20181101
1.0.0-alpha1+build.20181021 => 1.1.0-alpha1+build.20181101
1.0.0-alpha1+build.20181020 => 1.1.0-alpha1+build.20181101
1.0.0+build.20181031 => 1.1.0-alpha1+build.20181101
We need to modify JSON generator script to get data from GitHub, which is triggered periodically using a cronjob.
The following is a proposed JSON format based on the current API:
{
"recent": {
"data": [{
"title": "items->{}->title",
"status": "open",
"link": "items->{}->url"
},
{
"title": "items->{}->title",
"status": "open",
"link": "items->{}->url"
}
]
},
"in-progress": {
"data": [{
"title": "items->{}->title",
"status": "needs-pr",
"link": "items->{}->url"
},
{
"title": "items->{}->title",
"status": "has-pr",
"link": "items->{}->url"
}
]
},
"help-wanted": {
"data": [{
"title": "items->{}->title",
"status": "open",
"link": "items->{}->url"
},
{
"title": "items->{}->title",
"status": "open",
"link": "items->{}->url"
}
]
},
"link": "https://github.com/ClassicPress/ClassicPress/issues?q=is%3Aopen+is%3Aissue+label%3A%22type%3A+feature+request%22"
}
We have 3 categories: recent, in-progress, and help wanted
Pull the most recent 10 open issues using the label "type: feature request" and the following statuses:
When passing status label to the JSON file, please remove "status: ".
Pull open issues labeled "type: feature request" and the following statuses:
When passing status label to the JSON file, please remove "status: ".
Pull the latest 10 open issues with label "help wanted".
When passing status label to the JSON file, please remove "status: ".
This is a feature request.
I believe this can make it easier to test and have a few more testers on board and feedback.
The plugin uses the API to check what migrations are ‘officially’ supported. Locally that can be over-ridden with:
add_filter( 'classicpress_ignore_wp_version', '__return_true' );
Can we add this in settings to reduce the code requirement?
We should set up a bot to make new PRs to this repository when new ClassicPress or WordPress versions are released, to enable the new version for the migration plugin.
There are 2 cases to handle:
The ClassicPress migration plugin needs to use a ClassicPress build with a different structure, because WordPress can only do an upgrade from a zip file that contains a single folder named wordpress
. (Some history and links at ClassicPress/ClassicPress#148.)
To avoid an extra manual step in the release process, we generate these migration builds along with the nightly builds: https://github.com/ClassyBot/ClassicPress-nightly/releases
A new nightly build is released every day shortly after midnight UTC.
We need to create a PR against this repository every time the nightly build changes to a new base version number, indicating that a release has been done. Here is an example of such a commit: 348751d
An initial attempt at this was made in #36 and #38 but it needs more work before being committed, see 9a480d6 for more info.
When a new version of WordPress is released this also needs to be tested manually (because a new WP version could break the migration process) and then enabled.
An automated PR could be created for this too, though again it needs to be tested carefully before being merged.
Here are two examples of such commits, they should look a bit different depending on whether it was a major or a minor version of WordPress that was released:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.