[wp-trac] [WordPress Trac] #60992: Plugin management: AJAX plugin activation consequences

WordPress Trac noreply at wordpress.org
Tue Apr 16 07:20:31 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 louiswol94):

 What about plugins that have onboarding screens straight after plugin
 activation? Like WooCommerce, Yoast, Elementor etc. Expecting the user to
 refresh the page first seems like a regression in UX.

 Replying to [comment:6 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:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list