[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