The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props mamaduka, swissspidy, antonvlasenko.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@swissspidy, I used the old Trac ticket as a reference. Should I create a new one?

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

It looks like an attempt was made to make the autosaves endpoint work for Templates and Template Parts (https://core.trac.wordpress.org/ticket/56922). These PHP unit tests are failing now.

How do we want to proceed here? Should we disable the PHP unit tests until these post types fully support autosaving?

Note: The autosaving is disabled on the client side - WordPress/gutenberg#64733.

@swissspidy, I used the old Trac ticket as a reference. Should I create a new one?

Yes. New milestone/release = new ticket. The old ticket is already fixed on a closed milestone and must not be reopened/amended for changes in a new milestone.

How do we want to proceed here? Should we disable the PHP unit tests until these post types fully support autosaving?

I suppose we have to make up our minds here :-)

Just so I understand correctly:

[56819] added proper autosave support for wp_template and wp_template_part because previously the endpoints were sort of broken. (Commit message says: "Consequently, when the post types template and template part were introduced in [52062], it led to the registration of REST API endpoints for autosaves and revisions with invalid URL structures.")

But the editor never actually supported autosaves for wp_template anyway...? 🤔 Is that because it's not desired, or because it was previously broken?

If the former, we should update the core code here accordingly. If the latter, we should update Gutenberg, because it apparently seems to be supported by core.

So, which one is it?

Based on the latest comments on 56922 and new ticket, it seems that autosaves aren't fully working for Templates and Template Parts.

cc @anton-vlasenko, @ironprogrammer

That one is labelled as an enhancement though, just updating the regex and adding some hardening.

The template parts and autosave endpoint still generate a warning. One I'm trying to fix in Gutenberg PR.

In any case, let's see what others think about this.

That one is labelled as an enhancement though, just updating the regex and adding some hardening.

Correct. This is an enchancement and not a blocker.

The template parts and autosave endpoint still generate a warning.

I'm looking into the issue, @Mamaduka.

But the editor never actually supported autosaves for wp_template anyway...? 🤔 Is that because it's not desired, or because it was previously broken?

@swissspidy, I believe it’s the latter, as the default autosave endpoint doesn’t work for templates and template parts due to their different URL structure. These custom autosave and revision endpoints were supposed to address this issue, but as it can be seen, they didn’t fully resolve it.

I suggest to wait for the Core fix to arrive and avoid disabling autosaves for templates and template parts, unless there are other reasons to do so for these post types.
I'm currently working on the Core fix.

I've fixed the issue with the autosaves endpoint.
The revisions endpoint is likely fixed as well, but I would like to write more unit tests to ensure it is fully resolved and to prevent it from occurring again.
The work is being done here: draft PR. The estimated time of completion is sometime tomorrow.

@Mamaduka, if you don't mind, I'm going to create a new Trac issue for this bug, as https://core.trac.wordpress.org/ticket/41172 doesn't seem to be an exact fit.

Thank you, @anton-vlasenko!

Core ticket: https://core.trac.wordpress.org/ticket/61970
GH PR: #7272

The PR is ready for review. The error occurs because the Editor is trying to fetch autosaves for a file-based template. Since file-only templates do not have any entities in the database, it is impossible to fetch autosaves (or revisions) for them.

My PR addresses this issue by changing the REST response code from 403 to 400 when the controller attempts to get autosaves (revisions) for a file-only template (template part) and also fixes the fatal PHP error.
Additionally, it adds more unit tests to cover the wp_template_part post type.

I would appreciate your review and approval, @Mamaduka and @swissspidy.

This PR resolves the fatal error issue, but it will not enable autosaves automatically.
Should the Editor first check if the template has a database entity, and if not, create one?

Closing in favor of #7272.