Add plugins endpoints

[TimothyBJacobs]

Introduces a set of plugin endpoints, intended to compliment the block directory searching endpoints.

Brings tests and endpoint code from tellyworth/wordpress-develop/add/rest-api/block-directory.

For some reason it seems like the filesystem isn't available when running tests.

Description

How has this been tested?

This has been manually tested and has some test coverage. Needs more test coverage and coverage on multisite.

Types of changes

New Feature

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR.

[TimothyBJacobs]

I pushed a commit that refactors the block directory install and uninstall endpoints to use the plugins controller. Ideally we'll drop those methods and the block directory would POST to the plugins endpoint.

One thing of note is the uninstall endpoint. It is performing a deactivation and uninstall in one request. As far as I know this can't happen in the WordPress UI typically. It can also lead to all sorts of weird errors since the request started with the plugin active and running its code, but ends the request without the plugin files. This would mean if that plugin would include any files on a hook that occurred after it got uninstalled, everything could blow up. I've left this for now, but I think we should drop it and do the separate status update to inactive and then delete.

[TimothyBJacobs]

Also, I dropped the item specific permission checks for activating and deactivating since that will be handled by the plugins controller. The purpose of those permission checks now is just to generate an Allow header which wouldn't have the plugin slug available.

I've also fixed the single activate_plugin cap check. It was operating on the plugin slug, but is meant to operate on the whole plugin file. This means we can't preemptively check it before doing the install if we are going to activate it in the same request. But we check it once the install is complete.

[TimothyBJacobs]

I've adjusted the tests to mark as skipped instead of erroring if they run into a permission error while we wait on #22515. The tests should all work if you run them locally.

I also started to add some multisite tests, but I couldn't get multisite tests to work using test-unit-php-multisite. AFAICT, it is still running the tests on a single-site setup and it seems like the ms-required and ms-excluded groups aren't respected. I've also marked those as skipped for now.

[spacedmonkey]

Review complete.

[TimothyBJacobs]

Thanks for the review @spacedmonkey! I've pushed commits or left comments for all of your feedback.

[spacedmonkey]

I think it is good first version. Once merged we can do some testing and tweak as required.

[TimothyBJacobs]

Once merged we can do some testing and tweak as required.

Definitely.

I've tested with the inserter and searching blocks and installing blocks all still works as normal in my testing. Going to go ahead and merge this.

[StevenDufresne]

Once merged we can do some testing and tweak as required.

Definitely.

I've tested with the inserter and searching blocks and installing blocks all still works as normal in my testing. Going to go ahead and merge this.

I am able to reproduce the issue that i mentioned in my review in master now. I'm curious, how did you test?