[wp-trac] [WordPress Trac] #60992: Plugin management: AJAX plugin activation consequences
WordPress Trac
noreply at wordpress.org
Mon Apr 15 13:59:00 UTC 2024
#60992: Plugin management: AJAX plugin activation consequences
--------------------------+------------------------------
Reporter: jeherve | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Plugins | Version: 6.5
Severity: normal | Resolution:
Keywords: | Focuses:
--------------------------+------------------------------
Comment (by benlk):
I'm going to propose a way forward, which doesn't involve reverting
#22316, but which involves adding additional functionality to WordPress.
I'm not prepared to implement this, so please consider it as a seed
crystal for discussion, not as an actual proposal.
Consider the three scenarios in this ticket, and how plugins handled
telling the user in non-AJAX that configuration is needed:
1. The plugin tells the user by sending the user to the configuration
screen.
2. The plugin tells the user by adding a small piece of text in the middle
of a long table.
3. The plugin expects the user to find the plugin's entry in the Dashboard
menu, click on it, and locate the configuration screen.
I'll add a fourth communication method, which has been controversial in
the past: an Admin Notice nag which only goes away once the plugin is
configured or deactivated.
Of these:
1. Option 1 is bad because, as most commonly implemented, it breaks bulk
activation.
2. Option 2 is bad for discoverability reasons.
3. Option 3 is bad for discoverability reasons, especially for plugins
which don't implement a top-level Dashboard menu item.
4. Option 4, the admin notice, is ''in my opinion'' the most-reliable
method of getting a message to the user, because it creates a persistent
to-do list item at the top of the Dashboard.
Here's my proposal:
1. Add a WP-REST API endpoint to return admin notices, building upon
#57791
2. On the frontend JS handler for AJAX plugin activation success/error,
add a post-activation check for Admin Notices. This should run after the
activation check as a separate request to the new REST API endpoint, in
order to ensure that plugins' code is loaded at runtime.
3. Dynamically insert Admin Notices in the usual spot.
This approach:
- gives the post-AJAX-activation screen feature parity with the screen
shown after a page reload: notices are now displayed
- doesn't add any new APIs for plugin developers
- doesn't require developers who rely on Admin Notices for configuration
nags to change anything
- does effectively endorse the use of Admin Notices for configuration nags
- does create a new REST API endpoint
--
Ticket URL: <https://core.trac.wordpress.org/ticket/60992#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list