classicpress / classicpress-apis

ClassicPress API endpoints

ClassicPress: The CMS for Creators. Stable. Lightweight. Instantly Familiar.

ClassicPress is a community-led open source content management system for creators. It is a fork of WordPress 6.2 that preserves the TinyMCE classic editor as the default option. It is half the size of WordPress, contains less bloat improving performance, and has no block editor (Gutenberg/Full Site Editing).

For more information, see:

• The official ClassicPress website ›
• The ClassicPress documentation ›
• The ClassicPress governance ›
• Suggest features ›

Contributions

This project exists thanks to all the people who contribute and who have contributed in the past, whether as part of the long history of thousands of contributions to WordPress from many different people, or as contributions to ClassicPress itself.

Would you like to help? Here is how you can start ›

Sponsors

Corporate sponsors that believe in ClassicPress. Become a sponsor › All donations are tax-deductible in the United States.

Financial Contributors

Support the ClassicPress project by making a donation › All donations are tax-deductible in the United States.

Individuals

Organizations

classicpress-apis's Issues

Endpoints for translation

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

Setup API Endpoints

Please refer to: ClassicPress/ClassicPress-v1#238

Support forum petitions endpoint

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

Add checksums API

See: https://forums.classicpress.net/t/classicpress-checksums-api/1596

Please leave other links and information here.

Add setting to override API while testing

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?

Support PHP Migration check

Add support to check for the current valid PHP versions.

Linked to ClassicPress/ClassicPress-Migration-Plugin#87

Make update/upgrade endpoints pull from GitHub dynamically

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:

• English and non-English
• Latest version on a branch (4.8.x, 4.9.x)
• Older version on a branch with an update available (4.8.x, 4.9.x)

We also need to come up with a strategy for handling localized releases and alpha/beta/"final" release channels.

Update features API endpoint to use GitHub API

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"
}

Categorization

We have 3 categories: recent, in-progress, and help wanted

recent

Pull the most recent 10 open issues using the label "type: feature request" and the following statuses:

• status: discussion
• status: on hold
• status: need more info
• status: needs decision

When passing status label to the JSON file, please remove "status: ".

https://api.github.com/search/issues?q=is%3Aissue+is%3Aopen+label%3A%22type%3A+feature+request%22+repo:classicpress/classicpress

in progress

Pull open issues labeled "type: feature request" and the following statuses:

• status: has pr
• status: needs pr
• status: research plugin
• status: needs test
• status: needs review
• status: community reviewed

When passing status label to the JSON file, please remove "status: ".

https://api.github.com/search/issues?q=is%3Aissue+is%3Aopen+label%3A%22type%3A+feature+request%22+repo:classicpress/classicpress

help wanted

Pull the latest 10 open issues with label "help wanted".
When passing status label to the JSON file, please remove "status: ".

https://api.github.com/search/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22+repo:classicpress/classicpress

Clean up core API endpoints

We have two core endpoints that seem to be doing nothing:

• https://api-v1.classicpress.net/core/stable-check/1.0/
• https://api-v1.classicpress.net/core/version-check/1.0/

They correspond to WordPress APIs:

• https://api.wordpress.org/core/stable-check/1.0/
• https://api.wordpress.org/core/version-check/1.7/

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.

Add alpha/beta/RC channels for upgrades

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

Separate upgrade responses list into "release" and "nightly"

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:

• v1.x release
• v1.x nightly
• v2.x release
• v2.x nightly

Add API endpoint for feature votes

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

Add api.wordpress.org/core/importers/1.1

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.

Add API endpoint for "latest version"

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

Improve error handling in features endpoint

ClassicPress-APIs/v1/features/1.0/index.php

Line 97 in 0380058

send_response($tags);

This line should have the second parameter set to true to indicate an error.

Automatic PRs for new ClassicPress and WordPress versions

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:

New ClassicPress version addressed in #38

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

New WordPress version

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:

• 44e4315
• 02a9a5f

Initial plan for auto-updates and versioning

Here is the basic idea:

• Nightly versions can update to newer nightly , alpha, beta, or final release builds (if you're on nightly builds you're a developer, and you probably want to keep getting new nightly builds only)
• Alpha versions can update to newer alpha, beta, or final release builds
• Beta versions can update to newer beta or final release builds
• Final release versions can update to newer final release builds (without moving to a new semver major version i.e. 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