[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