Plugin management: AJAX plugin activation consequences

[jeherve]

This change was introduced in #22316 (changeset r57545 ).

---

When a site owner activates a plugin on their site, 2 things may happen:

• The plugin's feature may be available right away.
• The plugin may require some configuration before it can be used ; this is often handled via options on a custom Settings screen created with the Settings API.

There were typically 3 ways site owners learn about such settings screens:

1. Upon activating the plugin, they are redirected to the settings screen. This is often done via the activated_plugin hook ( ​ reference ). It has been around since WP 2.9.
2. Upon activating the plugin, they are redirected to the Plugins list table, where they see a "Settings" link next to the plugin they just activated. This is often done via the plugin_action_links_{$plugin_file} hook ( ​ reference ), introduced in WP 2.7.
3. Upon activating the plugin, they are redirected to the Plugins list table and scan their WordPress navigation menu to search for the new menu item, and thus the next step in the setup.

These 3 paths to plugin configuration are no longer available in WordPress 6.5.

Indeed, starting in WordPress 6.5, we no longer refresh the page on plugin activation ; the plugins are activated via an AJAX request. As a result, the plugin's code (settings screen registration, hooks) aren't run until the site owner refreshes the page or navigates to a different page.

This seems like a regression in the user experience, and something we should fix.

[roytanck]

I'd argue that we'd need to consider alternatives for options 2 and 3, but 1 interrupts bulk activations and is imho quite obnoxious.

[jeherve]

Replying to roytanck :

1 interrupts bulk activations and is imho quite obnoxious.

Yes, this is probably something that would need to be addressed separately. This problem is currently tracked in #40252 .

[thisisandrewpalmer]

Let's not consider the User Experience here and just think about Devs. I don't know any one user and I have 500 hosted websites. That the user installs multiple plugins at once. Who initiates these ideas I wonder? Users are now confused as to what to do after installing a plugin now.

[alanfuller]

Replying to roytanck :

I'd argue that we'd need to consider alternatives for options 2 and 3, but 1 interrupts bulk activations and is imho quite obnoxious.

And also easy for plugin developers to detect bulk activation and not initiate a wizard.

That fact that some developers don't is not a valid reason to make set more difficult for users.

[thisisandrewpalmer]

Just revert, I see no issue - the multiple plugins install issue is a devs issue, we want users to use WordPress who have no code experience. It's all in the messaging ​ https://wordpress.org

[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

[stevejonesdev]

I also noticed an issue with the "Activate/Install Now" button not updating until the page refreshes. After the plugin is activated and the button text changes to Active, it stays an active link and doesn't change the HTML markup to the disable button element. You can actually click the "Active" button link again even though it visually appears disabled and it will redirect to the main plugins page.

Active state markup:

 <a class="button button-disabled" data-slug="duplicate-post" href=" http://activation.local/wp-admin/plugins.php?_wpnonce=89f0a7c70e&amp ; action=activate&amp;plugin=duplicate-post/duplicate-post.php" aria-label="Yoast Duplicate Post 4.5 activated successfully." data-name="Yoast Duplicate Post" data-plugin="duplicate-post/duplicate-post.php">Active</a>

After manually refreshing the page:

 <button type="button" class="button button-disabled" disabled="disabled">Active</button>

[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 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

[alanfuller]

If you don't revert...

Scenario 1)

User leaves 1 star review for plugin, "No idea what to do next after activation."

Plugin Devs response, sorry nothing I can do about it, that was a WordPress core unilateral decision to reduce usability.

.. you revert ..

Scenario 2)

User leaves a one star review, "Your wizard breaks bulk activation and that is horrible."

Plugin dev, thanks for your feedback, I can fix that ( and plugin Dev simply detects bulk activation as many do and resolve their usability issue )

[justlevine]

Seems there's a bit of conflation between what needed for a viable UX, and what some devs are (ab)using those hooks for.

Premise: there is no justifiable use case for forcing users into an onboarding wizard after activating a plugin. There are dozens of reasons why a user would not want to setup a plugin as soon as they activate it.

The proper pattern is to use an Admin Notice, informing the user they must complete setup. (Its beyond the scope to get into the irony about the positive correlation between plugins that abuse admin notices and have forced onboarding wizards).

With redirect hijacking aside, we're now left with the justifiable issue of guiding people to the next actionable step from the plugin activation screen.

A simple, non-intrusive solve that's also forward-compatible with whatever other reactive Admin UI updates would be changing the success notices to add something along the lines of 'Go to your <link>Dashboard</link> to see the changes'.

A step up from this would be allowing users to provide an activation_success_message that could be displayed on the screen. This would also fill the gap caused by the lack of new links in the Admin Menu/Bar

Neither offers as comprehensive a solve as @benlk's suggestion for an Admin Notices REST API, which I love, but can only assume will also be required by future Admin UI updates anyway - and as a result likely hard to implement beforehand without it turning into tech debt.

[alanfuller]

I don't like the idea of admin notices, they are so abused the users zone them out, there are even plugins to get rid of them.

To me the best solution is the button.

When you look search the button says install now, you click that and the button is active and says activate, you click that and you get a very passive response greying out the button, it actually is hard to understand that is a success.

Ideally, plugin Devs should be able to hook in there and set the next button action, e.g. [ Go to Settings] or [run install wizard]

This is then in the user 'work flow' and gives them clear options to proceed if they want.

[jeherve]

Replying to justlevine :

With redirect hijacking aside, we're now left with the justifiable issue of guiding people to the next actionable step from the plugin activation screen.

Yes, I think it may be best to focus on that specific issue in this ticket. As we can see from the discussion above, we could talk about many different approaches to plugin onboarding / redirect hijacking / whatever we may want to call it. I don't think that should be the main point of this ticket though. The issue at hand is, when you activate a plugin, you no longer have any guidance as to what to do next.

This is true regardless of the plugin, and whether that plugin needs onboarding or not.

• If your plugin registers a CPT, the dedicated admin menu will not appear until you refresh.
• If your plugin registers a settings page, that page will not be visible or accessible until you refresh.

A step up from this would be allowing users to provide an activation_success_message that could be displayed on the screen. This would also fill the gap caused by the lack of new links in the Admin Menu/Bar

I'm afraid the current implementation will not allow us to do that, since even if plugin authors were to hook into a potential new filter, that code would not run until a page refresh.

A simple, non-intrusive solve that's also forward-compatible with whatever other reactive Admin UI updates would be changing the success notices to add something along the lines of 'Go to your <link>Dashboard</link> to see the changes'.

I wonder if it would be possible to have 2 different post-activation behaviors based on the plugin's details:

• If the plugin has a declared dependency, keep the behavior introduced in WordPress 6.5 ; site owners remain on the Plugin install screen and install other plugins.
• If the plugin does not declare dependency, redirect site owners to the Plugins screen like we did in WordPress 6.4 and earlier. This option would offer a similar result to your proposal, except site owners would not have to read and click to be redirected and thus refresh the screen.

[justlevine]

Replying to jeherve :

Replying to justlevine :

A step up from this would be allowing users to provide an activation_success_message that could be displayed on the screen. This would also fill the gap caused by the lack of new links in the Admin Menu/Bar

I'm afraid the current implementation will not allow us to do that, since even if plugin authors were to hook into a potential new filter, that code would not run until a page refresh.

Sorry I should have been more explicit. The recommendation here is to send the activation success message in the ajax response. It's a half measure that's not as drastic as a full-blown Admin Notices API.

[thisisandrewpalmer]

I am finding this discussion very frustrating, The solutions offered here, should have been discussed before someone took it upon themselves to make this major change. I am befuddled to say the least. Just revert it, if it's good enough for Woo after making a bad decision, its good enough for us, right?

[flixos90]

I agree that this ticket is not the right place to discuss better alternatives for plugin onboarding, despite it being a valid and necessary discussion.

Activating plugins via AJAX without reloading the page is breaking expected behavior, and I'm not sure whether this was considered when plugin dependencies were introduced.

@afragen @costdev Can you share any context here you may have? So far I tend to think the AJAX activation part needs to be reverted.

[tomsitespot]

Replying to thisisandrewpalmer :

I am finding this discussion very frustrating, The solutions offered here, should have been discussed before someone took it upon themselves to make this major change. I am befuddled to say the least. Just revert it, if it's good enough for Woo after making a bad decision, its good enough for us, right?

Agree 100%. The old method of redirecting might be a bit over the top from a dev perspective, but you have made the plugin activate experience worse for regular people.

If not revert (we all make mistakes, let's just undo and try again) Why not introduce a new single_activate hook or something for when only 1 plugin is activated? Or an ajax message.

To have an Activated message and the admin Menu doesn't even update is embarrassing.

[benlk]

Sounds like there are two questions here:

1. Whether to revert the entire AJAX activation feature
2. What features would be needed to support plugin activation workflows in an AJAX activation workflow — and whether it would be easier to add those features instead of first reverting the AJAX activation feature.

[alanfuller]

Put simply - 6.5 broke a major part of the WP eco system but the impact was missed in testing and thus should be reverted.

Once reverted discussions can be had about improving the user experience.

[costdev]

@flixos90
@afragen @costdev Can you share any context here you may have? Activating plugins via AJAX without reloading the page is breaking expected behavior, and I'm not sure whether this was considered when plugin dependencies were introduced.

This was considered and the change in behaviour was noted in the ​ Merge Announcement post and in the ​ Dev Note .

So far I tend to think the AJAX activation part needs to be reverted.

Although a revert sounds like the right approach, a straight revert of AJAX additions isn't feasible due to the fact that modal-based activation requires AJAX activation (also note that modal-based activation is also available on Plugins > Installed plugins dependency links). Rather than revert, it may be a matter of being more restrictive in the selectors used so that only the Activate Now button in the modal triggers the AJAX activation.

Another approach could be to refresh the page when the Activate button is clicked outside of the modal.

Happy to discuss the above approaches or look at others so we can get a UX fix ready ASAP.

[afragen]

When working out the workflow with @azaozz and @costdev we found that specific plugin activation redirects resulted in a poor experience in installing and activating with plugin dependencies. One of our discussion points was a redesign of the iframe plugin installation/activation process.

[flixos90]

Thank you for your replies @costdev @afragen.

Follow up question: Why does any of the functionalities need AJAX? I would think anything we do via AJAX we could also do via hitting a specific "action URL" and then redirecting back (like was done before)?

Regarding the plugins redirecting, I tend to agree this is a poor pattern. IMO the more pressing reason to fix this is that plugins with a new admin menu item, admin notice, or admin pointer no longer can show these right after activation.

[costdev]

Follow up question: Why does any of the functionalities need AJAX? I would think anything we do via AJAX we could also do via hitting a specific "action URL" and then redirecting back (like was done before)?

Redirecting on the install page/outside the modal
Installing and activating dependencies is a multi-step process. Retaining a redirect within or outside the modal would mean users are redirected from Plugins > Add New to Plugins > Installed plugins /onboarding for each dependency, then have to navigate to the install page again, repeat for each dependency, and finally for the dependent.

Redirecting inside the modal
Post-activation redirection within a modal (whether dependency or dependent) leads to either plugins.php or onboarding experiences inside the modal. We had near-immediate consensus that this was both horrible visually and for UX.

Redirecting only for plugin card buttons
Much of the code for the install/activate buttons is the same for the plugin cards on Plugins > Add New and in the modals. We felt that being able to install and activate multiple plugins without being removed from the Add New context was beneficial, and that navigating to any other page would display either the onboarding, or the plugin's menu items, which would lead to their onboarding (the problem being: How does the user know to refresh/navigate away, and why should they?). - That's where a possible approach comes in of being more restrictive in the selectors so that the Activate button in plugin cards redirects as it did previously, which means the multi-step process of installing/activating dependencies remains the same as it is now, while individual installation/activation remains as it did before 6.5.

[jorbin]

While there isn't a patch or specific approach yet, I do think this is something that should be resolved in 6.5.3 so milestoning it as such.

[DrewAPicture]

As is common with changes to WordPress, there seem to be several competing interests in play here, all ignoring some aspect what was actually fixed and/or broken in the first place.

Background

As I recall (other core developers can feel free to correct me), the ability to install and activate multiple plugins (or just one plugin) from this screen was originally introduced somewhere around the 4.2 release as part of the "shiny updates" project.

At the time, we had initially allowed activations from this screen, but the presence of activation redirects caused the activation part to be reverted pending a decision about what to do about the ability for the redirects to interrupt the flow.

Later, plugin activation support was added to this screen, though still with no handling for potential interruptions. Now as of the 6.5 release, the activation redirects have been prevented and this UI for the very first time since its introduction does exactly what it was built to do.

Discussion points

With this background in mind, what I have to say next may appear controversial: it seems obvious to me that allowing the multi-installation flow to be broken with activation redirects never should have been possible in the first place. Preventing redirects today is a feature, not a bug.

That said, it also seems obvious that preventing the redirects has raised some new key questions worth full-throated discussion eleswhere:

1. Can or should WordPress facilitate a more seamless entry into an onboarding flow? If so, how?
2. Should/can WordPress be doing more to reflect successful activation, such as by refreshing menus, etc.?

Ideas

I was talking about this with a colleague today, @ohryan, and something he said stuck with me:

"... from a UX perspective, that "install" and "activate" would be two separate actions is pretty unexpected. Most software we're familiar with doesn't operate that way."

I agree with this. Actually, now I wonder why we can't just change the "Activate" button for plugins that register an activation redirect to something like "Start Set Up" or similar that gives an AYS warning when it tries to leave the page. Food for thought.

[flixos90]

@DrewAPicture I tend to agree with you regarding the redirects. However I don't think the discussion here should focus on that. The changes also prevent admin menu items, admin notices, admin pointers, or any other arguably more legitimate ways to expose a plugin's configuration UI to show up right away. That to me is the core of the problem here.

[costdev]

@flixos90 @DrewAPicture What do you think about re-enabling the redirect only for the Activate buttons in the plugin cards to resolve this for 6.5.3, and address redirect removal in favour of "live" (AJAX/Interactivity API basically) admin menus, notices, pointers, etc as part of / a follow-up to the admin redesign project?

That means we could resolve this issue for now, while not relegating further UX improvements to maybelater limbo.

[flixos90]

Replying to costdev :

@flixos90 @DrewAPicture What do you think about re-enabling the redirect only for the Activate buttons in the plugin cards to resolve this for 6.5.3, and address redirect removal in favour of "live" (AJAX/Interactivity API basically) admin menus, notices, pointers, etc as part of / a follow-up to the admin redesign project?

That sounds like a solid solution to me. Let's also Open a follow up ticket for the latter, unless there already is one.

Previously, plugin activation on the Plugins > Add New screen was performed using AJAX, no longer performing redirects. This meant that users would not see a newly activated plugin's menu items, admin notices, or other UI elements until the user refreshed or navigated to another screen.

This isolates AJAX activation to the "View details" / "More details" modals so that when activating a single plugin by clicking Activate in its plugin card on the Plugins > Add New screen, a redirect will be performed.

[costdev]

​ PR 6398 implements the solution outlined in this comment .

[costdev]

Testing Instructions

These steps define how to reproduce the issue, and indicate the expected behavior.

Steps to Reproduce

1. Navigate to Plugins > Add New .
2. Search for WooCommerce .
3. Click Install Now .
4. 🐞 Click Activate .
5. Deactivate and delete WooCommerce.
6. Apply ​ the patch .
7. Build core.
8. Navigate to Plugins > Add New .
9. Search for WooCommerce.
10. Perform a hard refresh to ensure the cache is cleared.
11. Click Activate .

Expected Results

When reproducing a bug:

• ❌ The Activate button should activate WooCommerce without refreshing the page.

When testing a patch to validate it works as expected:

• ✅ The Activate button should activate WooCommerce and redirect, either to the WooCommerce onboarding experience, or to Plugins > Installed plugins , depending on whether the _wc_activation_redirect transient is set to one (1 = show, 0 = don't show)

[afragen]

I've tested the PR in the Docker WP local dev environment, doing a complete reset (database reset) and rebuild between tests.

With the PR installed the Activate button in the plugin card redirects to the Woo setup page. In any of the plugin modals on plugin-install.php or plugins.php the Activate button does not redirect but a redirect occurs on the next page load.

This seems to be a good compromise and more work can be done during the coming admin redesign.

[roytanck]

If we want to eventually move away from refreshing the page, would it be possible for the activation AJAX call to return an optional message? This message could be filterable (through a PHP hook), with only text and links allowed (KSES)?

Plugin authors could then use add_filter to return something like "Thank you for activating MyPlugin, click here to configure its options.". The plugins page should then obviously display the message.

[costdev]

@roytanck In terms of whether it's possible, definitely. We already have the wp.updates.addAdminNotice() method in JS, so something like this would be pretty straightforward to implement:

• In the PHP AJAX callback: apply_filters( 'wp_plugin_activated_message', '', $status['plugin'] ) and add a non-empty message to the response (sanitized/escaped as needed)
• In wp.updates.activatePluginSuccess() : If not inside a modal and a message is present, output the message via wp.updates.addAdminNotice( { className: 'notice notice-success', message: response.message } )

Though as you said, if that approach was used, it would be something for after this ticket, in a future major release as the hook would be an enhancement and would also require uptake by plugin authors.

In theory, a default message and action could be used for 6.5.3, like: [plugin] activated successfully. < a>Manage plugins/Reload the page/something</a> . This would add the missing messaging whose absence is currently breaking the flow.

Thanks for testing @jeherve! To test the modals, click any of the "View details" or "More details" links in plugin cards on Plugins > Add New .

Would love to test this as well, but I'm just not as informed on testing Core PRs. The Playground option seems like an awesome way to "Democratize Core PR Testing" but the current implementation needs tweaking it seems:

Thanks for the further testing and feedback!

So the modal definitely shouldn't redirect on activation or close because when installing dependencies, this creates a very cumbersome flow. What we need is a way for users to know how to move forward. In that regard, I think this is where the wp.updates.addAdminNotice() could come in. We already show admin notices for plugin activation elsewhere, so this has an established precedent. Showing a notice to let the user know the plugin is activated, with a link to plugins.php ("Manage Plugins") would provide the user with that information, and plugins like WooCommerce will trigger their onboarding experience on the next page load anyway (this is also true of FTP/WP-CLI-based/manual upload installation/activation).

@flixos @DrewAPicture What do you think about extending this patch to add an admin notice with a link to plugins.php , providing messaging and effectively making the redirect a manual action via click, to maximise information and user control?

this creates a very cumbersome flow.

Indeed, I can see that. We basically have one screen aiming to start 3 different flows:

1. Search > Install > Activate
2. Search > Install > Activate > Configure (create new post in CPT, change settings, ...)
3. Search > Install > Activate > Search > Install > Activate > ... > Configure (create new post in CPT, change settings, ...)

What we need is a way for users to know how to move forward.
In that regard, I think this is where the wp.updates.addAdminNotice() could come in.

The notice seems like a nice way to let the user know about the next step without interrupting the flow. With that in mind, maybe this PR should be abandoned in favor of just the notice, displayed after each AJAX plugin installation.
That notice could be a standard one for now for 6.5.3, and it could then be extended / customizable by plugin authors in 6.6, based on the ideas discussed on the ticket?

The notice seems like a nice way to let the user know about the next step without interrupting the flow. With that in mind, maybe this PR should be abandoned in favor of just the notice, displayed after each AJAX plugin installation.

That notice could be a standard one for now for 6.5.3, and it could then be extended / customizable by plugin authors in 6.6, based on the ideas discussed on the ticket?

Yep, that makes sense.

Though rather than abandon this PR, I'll keep it open, and open another PR for the admin notice so that the different approaches, maybe even both together, can be considered for inclusion in 6.5.3.

[JeffPaul]

Sharing a ​ possible mockup from @kevinwhoffman on Twitter showing a "Configure" button that appears in the WordPress plugin card after it has been activated.

[jason_the_adams]

Hello folks! 👋

Chiming in here from the StellarWP side (though not necessarily representing everyone's opinion). A number of our products rely on the redirect for onboarding our products. I certainly appreciate the nuance of the "feature" as it's really just the best point for plugins to do that, but is by no means a first-class feature of WordPress and therefore has interesting side-effects given the scenario in which the plugin is installed.

For that reason, and since the admin-side will be changing in the not too distant future, it makes most sense to me for WordPress to have a first-class way of registering an onboarding URL with WP. That way, WP can determine when and how it's presented to the user based on the installation context. If the "Activate" button is clicked, for example, then the user can be redirected — or perhaps be replaced with a new "Setup {Plugin Name}" button. If WP-CLI, then perhaps it shows up as "Setup {Plugin Name}" beneath the "Updates" in the left-hand menu.

I'm just riffing, of course. I don't think WP needs to provide a framework for the onboarding. I think it could simply start as registering an onboarding URL that an admin is intended to go to once.

[azaozz]

Replying to flixos90 :

Regarding the plugins redirecting, I tend to agree this is a poor pattern.

Yes, thinking the same. Also, as mentioned above, a redirect away from the Plugins screen would break the workflow when installing and activating plugins with dependencies. That would result in a somewhat mediocre UX.

IMO the more pressing reason to fix this is that plugins with a new admin menu item, admin notice, or admin pointer no longer can show these right after activation.

A bit unsure if showing a new admin menu item or admin pointer right after activation is critical. At that moment the user is still on the Add New Plugin screen. Seems new menu items and/or pointers would be far more useful when the users go to the Dashboard or the plugin's settings screen after the plugin has been activated.

Having a way to show a notice or warning would be really good though. It will help to keep the users informed about next steps, or eventual problems.

Plugin activation on the Plugins > Add New screen is performed using AJAX, no longer performing redirects. This means that users will not see a newly activated plugin's menu items, admin notices, or other UI elements until the user refreshes or navigates to another screen. Without adequate messaging and direction, users may be unsure of what to do next.

This shows an admin notice when a plugin is activated from its plugin card or modal, informing the user that the plugin was activated, and that some changes may not occur until they refresh the page.

This also displays the admin notice on Plugins > Installed plugins when a dependency is installed by modal from its dependent's plugin row.

The benefits of this approach are:

• AJAX-based activation remains as was intended by the Plugin Dependencies feature, and originally intended by the Shiny Updates feature.
• The user is informed that changes may not occur until the page is refreshed.
• The user's flow isn't assumed, and the user retains the choice of whether to continue installing and activating plugins, or to refresh the page.

[costdev]

In a case of perfect timing and actual coincidence, I just finished working on a ​ PR 6401 to retain AJAX-based activation and add a notice based on ​ feedback on PR 6398 as Ozz posted his comment above .

More details are in the description of ​ PR 6401

[costdev]

Testing Instructions for ​ PR 6401

These steps define how to reproduce the issue, and indicate the expected behavior.

Steps to Reproduce/Test

1. Navigate to Plugins > Add New .
2. Search for WooCommerce .
3. Click Install Now .
4. 🐞 Click Activate .
5. Navigate to Plugins > Installed Plugins .
6. Deactivate WooCommerce.
7. Apply ​ the patch .
8. Build core.
9. Navigate to Plugins > Add New .
10. Search for WooCommerce.
11. Perform a hard refresh to ensure the cache is cleared.
12. Click Activate .

Expected Results

When reproducing a bug:

• ❌ The Activate button should activate WooCommerce without refreshing the page, but doesn't inform the user of what they may need to do next.

When testing a patch to validate it works as expected:

• ✅ The Activate button should activate WooCommerce without refreshing the page, and a notice should appear to inform the user of what they may need to do next.

Additional testing option

• Deactivate WooCommerce, then instead of clicking the Activate button in its plugin card, click its More Details link and click the Activate button inside the modal. The admin notice should appear on the screen behind the modal.

The notice is displayed nicely, whether you're activating via the main page or via the modal. However, I do not think it will be noticed when folks install plugins via the modal, since they first have to exit the modal and scroll up to the top of the page:

​ https://github.com/WordPress/wordpress-develop/assets/426388/67d6ac66-abe5-4b7f-9193-10d53d720919

Maybe the notice should appear in the modal in this scenario?

Thanks for the feedback @jeherve!

By default, adding an admin notice to the bottom of the modal means it'll appear in place of the disabled Active button, shown below.

@karmatosed Would you have time to offer your thoughts on whether this is fine, or if we should make some CSS tweaks so that the notice and the disabled Active button appear side-by-side?

[costdev]

Adding design-feedback to reflect the current status of ​ PR 6401 .

[davidbaumwald]

#61033 was marked as a duplicate.

[adrianduffell]

Hello folks, I'm chiming in from the WooCommerce side. First of all, thank you for making it easier for users to install multiple plugins at once. WooCommerce previously had a redirect to automatically start the setup flows after plugin activation. Since the 6.5 release, we are seeing 20% less usage of the setup flows now that it fails to trigger. This is concerning to us because it means a large amount of users never truly start their journey with our plugin despite their intention to do so by activating it.

I agree the redirect pattern is disruptive to users who are installing multiple plugins at once. I would be in favor of a first-class way for plugins to register their onboarding URLs and have WordPress provide a new configure button (as shared above in https://core.trac.wordpress.org/attachment/ticket/60992/Configure-button.jpg ), to help guide users to the next step. Additionally, I think it would also be helpful to users for WordPress to continue surfacing this button in prominent locations until configuration has been completed, to help with cases where users leave the plugin screen without being aware of the button.

In the meantime, I think an advisory notice on the plugin screen suffices as a short-term fix for the next point release.

[kevinwhoffman]

Another possible use for a standard "Configure" link is in the Plugins list table.

[kevinwhoffman]

I realize the short-term fix may be headed in a different direction, but I wanted to add some considerations about the "Configure" link mockup that was previously shared.

As a standard link in the Add Plugins search results

This "Configure" link concept was designed to be timeless rather than something that only applies to onboarding after activation. This means the "Configure" link can be present whenever an already active plugin card appears in search results, providing one-click access to configuration. It should always point to the page where the plugin can be configured, not just for first-time onboarding. If the plugin wants to include logic on that page that detects whether a first-time wizard UX is needed, that's up to the plugin to decide.

As a standard link in the Plugins list table

The "Configure" link could also be in the Plugins table where every plugin currently does this differently. For example, Yoast has two separate links—one for first-time config and one for settings. Much like "Deactivate" is a standard link for all plugins, we have an opportunity to establish a standard "Configure" link for configuration. So whether you encounter the plugin in search results or the Plugins list table, you are always one click away from configuration. Everyone knows how to deactivate a plugin; it should be just as obvious to configure it.

Defined in the plugin header

Allowing plugin authors to define a Configuration field in the plugin header means that the value could be used by core in multiple contexts including the plugin cards and list table described above. Simply define the field and it's available for use.

Generic enough to work everywhere

I chose the term "Configure" intentionally because we know that some plugins are configured on their own top-level WP Admin pages, others are nested under WP Admin > Tools, and others still are nested under WP Admin > Settings. For example, calling the link "Settings" implies you would be linked to the WP Admin > Settings or one of its child pages, which is not always the case. "Configure" is a generic term that can point anywhere in WP Admin and still make sense.

Simple fallback

If a Configuration field is not defined because a plugin like Hello Dolly has no configuration, then core can continue to show the disabled "Active" button in the plugin card and omit the link from the Plugins list table.

[afragen]

Instead of yet another plugin header, since the method of initiating these setup redirects is via the register_activation_hook() function, perhaps this function can be expanded to include a URL as a passed parameter? Such as

 register_activation_hook( $file, $callback, $url = '' )

Perhaps this would be an associative array like array( 'woocommerce' => <redirect URL> ) then a method of loading each ensuring that the redirect URL is opened.

Just thinking out load.

We really should create a ticket for any onboarding solutions as this would be an enhancement.

[jorbin]

We really should create a ticket for any onboarding solutions as this would be an enhancement.

I completely agree. Behold, #61040

In order to ensure this bug can be best fixed in 6.5.3, I think it's best to keep the discussion here around tightly scoped fixed.

As of now, this is targeted for 6.5.3 which is scheduled for 7 May. If there is going to be a new string added, I would like to provide at least a week for the translators but ideally as much time as possible.

[faisal03]

I'm inclined towards the non-AJAX-based approach, which involves redirecting or refreshing upon activation, as it offers more advantages than disadvantages. If we revert to this method, plugin owners and developers won't need to adjust their existing redirection setups, ensuring that their onboarding processes continue to function smoothly for users. Additionally, this approach makes all necessary CPTs and settings pages available after the refresh.

However, if reverting isn't feasible, I'm open to the idea of incorporating a "Configure" link upon successful activation of the plugin.

[esilverstrike]

It was mentioned in a support ticket I have on WordPress.org that this ticket may be related to my issue. The details can be found here:

​ https://wordpress.org/support/topic/plugin-updates-fail-with-error-message-but-are-actually-successful/

Please check the link for full details. To summarize, plugins with licenses update, but always produce an error message. Translations have the a similar problem but do not update. There are a number of people with this issue.

I’ve skimmed through the ticket. My knowledge about how WordPress works at the code level when dealing with plugin updates/installs at is minimal.

Obviously something has happened which caused my issue which has possibly corrupted something and preventing the update process with licenses to fail at some level.

FYI I do have other websites with a similar stack which update just fine.

What I am worried about is when this ticket is “fixed”, the potential corrupted that can happen which was caused by the issue mentioned in this ticket doesn’t get fix and thereby my site continues to have this plugin update issue. (if they are indeed related)

Thanks

[jeherve]

Replying to esilverstrike :

It was mentioned in a support ticket I have on WordPress.org that this ticket may be related to my issue.

It may indeed be related to the changes introduced in WordPress 6.5 as part of the work in #22316 . I would recommend debugging the problem further (I've responded in the thread to help you do just that) to try to find out more.

If it does turn out to be linked to the changes introduced in #22316 , you would need to open a new Trac ticket explaining the issue, since the problems you're experiencing are different from the plugin installation changes we're discussing in this ticket.

[jorbin]

I spent some time today testing PR #6401 and I'm not sure that the notice at the top of the page is going to be sufficient to inform users. It feels easy to miss, especially on small screens where you are most likely to have scrolled down the page. I wonder if it would be best to be brought inline to the card?

[costdev]

Thanks for testing @jorbin!

So we have a few instances in which a user should be informed of a plugin's activation:

1. After clicking Activate in a plugin's card.
2. After clicking More details to open a plugin's modal, then clicking Activate .
3. After clicking on a dependency's More details to open the dependency's modal, then clicking Activate .

If the notice for modal-based activation is displayed in the modal, this can inform the user with the same message. However just note that if a user closes the modal without reading the notice, they'll have no way to read it again, which is where a top-of-the-page notice can be useful. What do you think?

In-plugin-card notices are already supported in Core for error messages so this should be straightforward enough to implement.

[devsahadat]

The AJAX-based plugin activation in WordPress 6.5 removed page reloads but also caused confusion for users due to the lack of clear post-activation guidance. The proposed solutions, like adding a 'Configure' button or displaying inline notices after activation, aim to address this issue. Leveraging the WP-REST API to deliver admin notices dynamically can further enhance user guidance. In the long term, introducing a standardized way for plugins to register onboarding URLs can provide a clear path for users without burdening developers. Prioritizing user experience alongside technical efficiency will lead to a better user transition during plugin activation.

[chrisbadgett]

This release made the loading of the LifterLMS setup wizard no longer load on activation. Similar to WooCommerce, the setup wizard on activation is an important part of the new user onboarding flow.

The ability to flow instantly from activation into setup and configuration without distraction is an important need for platform-level and complex plugins.

With the latest changes:

1. A notice is added to the top of Plugins > Add New , with a button to refresh the page.

2. A notice is added to the bottom of a plugin's modal, which replaces the previous Active button, and the notice contains a button to refresh the page.

A notice has not been added to the plugin's card as this felt noisy in testing. The notices detailed above are definitely needed, so these were kept.

[swissspidy]

#61062 was marked as a duplicate.

This tests well for me.

A notice is added to the bottom of a plugin's modal, which replaces the previous Active button, and the notice contains a button to refresh the page.

What would you think about aligning the button to the right, so it effectively replaces the "Active" button?

@jeherve What would you think about aligning the button to the right, so it effectively replaces the "Active" button?

I've pushed a commit that aligns the button to the right of the notice. This keeps it in context with the notice's message. Let me know what you think. 🙂

I like that, it looks better imo:

I think we could do one last thing with the non-modal view, to address this feedback from @aaronjorbin on the ticket:

I'm not sure that the notice at the top of the page is going to be sufficient to inform users. It feels easy to miss, especially on small screens where you are most likely to have scrolled down the page. I wonder if it would be best to be brought inline to the card?

-- https://core.trac.wordpress.org/ticket/60992#comment:60

Either we could bring the notice to the card, or at least scroll up the page?

@jeherve I spoke to Aaron about not adding a notice to the plugin card and he agreed that having a notice in three places would be quite noisy. Scrolling up the page might frustrate users who didn't want to have to scroll back down 😅. Ideally, with the admin redesign, we'll have a snackbar/toast-style notice which should improve the UX here.

@aaronjorbin Are you happy with how things are shown in ​ this comment , or is there anything else you'd like to see?

[kevinwhoffman]

My understanding of the pull request is that the "Refresh Now" button will simply reload the current page, allowing any plugin menus and notices to appear. This does not feel like an adequate replacement for those plugins that were relying on redirects to initiate onboarding. We can debate whether redirects were ever an appropriate solution, but the reality is that users installing a new plugin are most likely going to configure it as a next step. The redirect solution—with all of its flaws—provided that logical next step.

The proposed "Configure" link also provides a direct path to configuration without the drawbacks of redirects, allowing the user to decide what happens after activation with a clear path to initiate configuration.

The "Refresh Now" button in the PR does not provide a similar direct path to configuration, instead leaving it up to the user to refresh the page and hunt down the appropriate admin menu to initiate configuration. Plugins that register menu items under Tools or Settings will have no noticeable presence on the page even after refreshing.

As a result, I worry that plugins will add more glaring admin notices at the top of the screen as a way to catch the user's attention and lead them into an onboarding experience where they would have previously relied on the redirect.

In summary, the admin notice with a "Refresh Now" button is an improvement over doing nothing after clicking "Activate," however the net result is still a regression in terms of plugin configuration.

[alanfuller]

Doesn't the refresh trigger the activation hook?

Certainly my testing indicates it does.

"I spoke to Aaron about not adding a notice to the plugin card and he agreed that having a notice in three places would be quite noisy"

What I dont understand is why not put the notice inside the card, when you have dependent plugins the notice is inside the card replacing the reviews.

[kevinwhoffman]

If the "Refresh Now" button accomplishes the redirect just by triggering the activation hook on the next page load, then we still have an issue of user control. Say the user does not refresh the page and instead decides they are going to view their Posts, Pages, or any other screen in WP Admin. That choice is going to trigger the redirect into an onboarding screen they explicitly chose not to visit (which is how WP 6.5.2 behaves today). Alternatively if they do choose to "Refresh Now" then the expectation is that the current page actually refreshes, not that it it might lead to an onboarding experience depending on which plugin was last installed. In an attempt to halfway cater to the use of redirects, we now have multiple situations where a user ends up somewhere they didn't expect to go.

[jorbin]

Sorry for not having brought this back here right after we talked so I'll summarize what @costdev and I had talked through.

There are three places we could consider for a notice right now: Inside the model, inside the card, and at the top of the page. All three have some sort of drawback, but having the same information presented in three places is going to negatively impact users and create information overload. The idea of putting it in the model and at the top of the page is that it is a short term fix for the time from 6.5.3 until a better solution can be developed (though #61040 ).

Additionally, The reason why auto-redirecting isn't a good option right now is the question of when do you do that in a multi install process? If your goal is to install a plugin with a dependency, should that dependency redirect you away from installing the plugin you wanted to install to begin with?

[alanfuller]

Replying to kevinwhoffman :

If the "Refresh Now" button accomplishes the redirect just by triggering the activation hook on the next page load, then we still have an issue of user control. Say the user does not refresh the page and instead decides they are going to view their Posts, Pages, or any other screen in WP Admin. That choice is going to trigger the redirect into an onboarding screen they explicitly chose not to visit (which is how WP 6.5.2 behaves today). Alternatively if they do choose to "Refresh Now" then the expectation is that the current page actually refreshes, not that it it might lead to an onboarding experience depending on which plugin was last installed. In an attempt to halfway cater to the use of redirects, we now have multiple situations where a user ends up somewhere they didn't expect to go.

This is true, what the 'user' expects is when they hit 'activate' that the plugin 'activates' which from a user persepctive includes the onboarding experience.

But for technical reasons I don't pretend to understand we can't achieve that as reverting is not possible.

[alanfuller]

Replying to jorbin :

Additionally, The reason why auto-redirecting isn't a good option right now is the question of when do you do that in a multi install process? If your goal is to install a plugin with a dependency, should that dependency redirect you away from installing the plugin you wanted to install to begin with?

Isn't that down to the developers of the multi dependency plugins to work out.

Maybe I don't quite get the reasoning behind multiinstall in the first place. And that is my fault for not really following that development.

Please correct me if I'm wrong, but it seems pretty niche to me.

Lets say I build a plugin that depends on another plugin, then I would code it so I wouldn't start my onboarding until the other plugin is active, this is easy to by setting an option on activation hook and deleteing when the conditions of onboarding are met.

The 'issue' arising when the plugin I'm dependent on has it's own onboarding, but the reality is either it would be a plugin I control or a plugin that Ihave a close enough relationships with the developer we could share a scheme.

However, I'd love to know how many plugins of the 60,000 use or plan to use multi plugin dependencies.

[costdev]

Maybe I don't quite get the reasoning behind multiinstall in the first place.

Prior to WordPress 6.5, it was common for users to install a dependent, activate it, then be greeted with a notice that they needed one (or on occasion more than one) other plugin. They'd often then click a link to the install page, install, activate, then find their way back to the dependent they actually wanted to use. This meant users navigating between multiple screens, plugin authors using various patterns (i.e. inconsistency for users), and so on. In that regard, some recent assertions that only developers install multiple plugins at once is somewhat inaccurate as users actually can often find themselves installing an addon first then finding out that they have to go through a process similar to the above.

Plugin Dependencies was (continuously) requested for a very long time (by all types of users), and while as we see from this ticket it didn't land perfectly, it's gone a long way towards delivering on this and we want to see issues like the one raised in this ticket have a path forward (such as these PRs, plus #61040 ).

Please correct me if I'm wrong, but it seems pretty niche to me.

There are quite a number of plugins that depend on others - For example, addons for ​ WooCommerce , ​ Contact Form 7 (and all other forms plugins) , ​ Elementor , and so on.

However, I'd love to know how many plugins of the 60,000 use or plan to use multi plugin dependencies.

Since 6.5 released, there are currently ​ 259 publicly-queryable plugins that return a result for "Requires Plugins: " (I haven't manually checked all 259 to verify it's always the new header though). That's a decent start given it's only been a few weeks, and I'd expect to see that number grow at a similar rate in the near future as more people become aware of it (e.g. as more documentation is added as need is identified).

[kevinwhoffman]

Replying to alanfuller :

This is true, what the 'user' expects is when they hit 'activate' that the plugin 'activates' which from a user persepctive includes the onboarding experience.

I don't actually think a user expects to be redirected. If you put an "Activate" button in front of a new user who has just installed a plugin, they should expect that it does exactly what it says—it activates the plugin. It should not redirect to an onboarding experience without the user's consent. In addition to a redirect being unexpected, it makes it difficult to install multiple plugins or dependencies of plugins in consecutive order.

Experienced WordPress users have come to expect a redirect when activating certain plugins out of sheer repetition. In the absence of a convention that provides clear direction to the user, plugin developers have decided over time that it is better to teleport the user to their own desired location rather than hope that the user finds their own way.

In contrast, the "Configure" link gives control back to the user by allowing clearly labeled controls to do exactly what they say they will do without surprises: Install > Activate > Configure.

In order to keep this ticket focused on the short-term solution, I'm going to shift further discussion of the "Configure" link to #61040 .

[alanfuller]

@costdev

Was just thinking about a plugin dev perspective on the admin notice, is there, will there, can there be an easy, consistent method to overide the noticeData.message so specific plugins can override? e.g. Plugin xyz activated,refresh page to visit settings / start onboarding, so those plugin that already have redirects can just filter so the user is not totally unexpectedly thrown into a settings / onboarding

 var noticeData = { id: 'plugin-activated-successfully', className: 'notice notice-success', message: sprintf( /* translators: %s: The plugin's name. */ __( 'Your custom %s was activated successfully. Some changes may not occur until you refresh the page.' ), response.pluginName ) };

[jeherve]

Replying to alanfuller :

is there, will there, can there be an easy, consistent method to overide the noticeData.message so specific plugins can override?

That may not be an easy option right away, since at that point, the plugin's code has not run yet. Info in the plugin header may be a way to work around that. #61040 goes into that into more details.

[alanfuller]

Silly qestion perhaps, but is there a way to specify pull request in .wp-env ?

e.g.

 { "core": "WordPress/wordpress-develop#6401",

( which doesn't work of course )

[jorbin]

@alanfuller I'm unsure about wp-env, but you can use the docker env that ships with core and is
​ documented in the readme . Using the github cli, you can clone ​ https://github.com/wordpress/wordpress-develop and run gh pr checkout 6401 .

[jorbin]

​ https://github.com/WordPress/wordpress-develop/pull/6401 is looking good. I haven't done a full code review so I'm not adding commit just yet, but I think for a short term fix this is the right direction.

[jorbin]

Once it's committed and backported, #polyglots should be given a heads-up about the new string so it can get translated before 6.5.3

[audrasjb]

Replying to jorbin :

Once it's committed and backported, #polyglots should be given a heads-up about the new string so it can get translated before 6.5.3

The ideal would be to ask Meta team to make the new strings available for translators on translate.w.org the day after RC1 is released so we have a couple days to translate it before May 7th. But of course a quick heads-up on the #polyglots slack channel would be nice, too.

[ironprogrammer]

Thanks, everyone, for all the effort put into this so far! 🙌🏻

Test Report

Patch tested: ​ https://github.com/WordPress/wordpress-develop/pull/6401
Testing instructions: https://core.trac.wordpress.org/ticket/60992#comment:47

Environment

• Hardware: MacBook Pro Apple M1 Pro
• OS: macOS 14.4.1
• Browser: Safari 17.4.1, Google Chrome 124.0.6367.94
• Server: nginx/1.25.5
• PHP: 8.2.18
• MySQL: 8.0.27
• WordPress: 6.6-alpha-57778-src
• Plugin used for testing: WooCommerce (WC)

Actual Results

• ✅ Activation from Installed Plugins page (main list) redirects to WC setup.
• ✅ Activation from Add Plugins page shows admin notice to refresh ( Figure 1 ),
• ✅ Activation from Add Plugins > More Details modal shows notice to refresh in footer of modal ( Figure 2 ).
• ✅ Clicking the notices' "Refresh Now" buttons began the WC plugin setup, or refreshed the page when setup had already been started/completed.
• ⚠️ After new WC activation, opening the More Details modal before "refreshing" (via notice button, navigation, or manual refresh) results in the WC plugin setup wizard starting inside the modal. This could affect compatibility with plugin post-install redirects, though, to be honest, I'm unsure if this is an implementation bug or should be resolved by extenders. ​ See this link for a demonstration of this unexpected behavior .

Additional Notes

• Used wp transient set _wc_activation_redirect 1 between tests to mimic a ​ new WC install .
• Safari + 1Password extension users may experience an issue whereby the new notice does NOT appear. If your JS console has the error Retrieving "b5x-stateful-inline-icon" flag errored: timed out - falling back , this is due to a ​ known 1P extension bug . Disable the extension to work around the issue.

Supplemental Artifacts

Figure 1: New admin notice in header.

Figure 2: New notice in modal footer.

[costdev]

@ironprogrammer Thanks for testing!

Indeed, when the _wc_activation_redirect is set to one (or any other truthy value), the next page load will load the onboarding screen. Note that this is also true of a WP-CLI-based activation.

This is certainly an unfortunate issue if a user opens the modal after activating the plugin, though I expect this to be a relatively rare occasion. I believe any change needed to stop this happening would need to occur in WooCommerce itself.

Given the work in #61040 , I think it's likely that a solution to this issue will come about by an extender implementing the resulting framework. As I understand it, it's our intention is to deliver on the framework for WordPress 6.6, so this rare occurrence would then only be possible for 6.5.x releases.

[jorbin]

​ https://github.com/WordPress/wordpress-develop/pull/6401 isn't the cause of the behavior @ironprogrammer describes, that is what is happening currently as well and I agree with @costdev that this is something that WooCommerce and other plugins with similar behavior cause. I still think this is ready for commit.

[jorbin]

In fifty-eight thousand and eighty-one :

Plugins: Show an admin notice on successful activation.

Plugin activation on the Plugins > Add New screen is performed using AJAX, no longer performing redirects. This means that users will not see a newly activated plugin's menu items, admin notices, or other UI elements until the user refreshes or navigates to another screen. Without adequate messaging and direction, users may be unsure of what to do next.

This shows an admin notice when a plugin is activated from its plugin card or modal, informing the user that the plugin was activated, and that some changes may not occur until they refresh the page.

Follow-up to [57545] .

Props costdev, jorbin, jeherve, flixos90, joedolson, ironprogrammer, audrasjb, alanfuller, kevinwhoffman, devsahadat, afragen, adrianduffell, azaozz, jason_the_adams, JeffPaul, webdevmattcrom, DrewAPicture, justlevine, stevejonesdev, benlk, roytanck.
Fixes #60992 . See #22316 .

[jorbin]

Reopeing for consideration to backport to 6.5.3

[joedolson]

Reviewed for backport.

[jorbin]

In fifty-eight thousand and eighty-three :

Plugins: Show an admin notice on successful activation.

Plugin activation on the Plugins > Add New screen is performed using AJAX, no longer performing redirects. This means that users will not see a newly activated plugin's menu items, admin notices, or other UI elements until the user refreshes or navigates to another screen. Without adequate messaging and direction, users may be unsure of what to do next.

This shows an admin notice when a plugin is activated from its plugin card or modal, informing the user that the plugin was activated, and that some changes may not occur until they refresh the page.

Follow-up to [57545] .

Reviewed by joedolson.
Merges [58081] to the 6.5 branch.

Props costdev, jorbin, jeherve, flixos90, joedolson, ironprogrammer, audrasjb, alanfuller, kevinwhoffman, devsahadat, afragen, adrianduffell, azaozz, jason_the_adams, JeffPaul, webdevmattcrom, DrewAPicture, justlevine, stevejonesdev, benlk, roytanck.
Fixes #60992 . See #22316 .

[smub]

I appreciate the core team working to add a Refresh button here, but I feel this is adding extra friction and complexity for beginners / non-techy users.

One of the best parts about WordPress is that we have always prioritized in building for the 95% but unfortunately in this situation, we have regressed in our values and are catering to the needs of 1% at the expense of adding friction and complexity for the larger user base.

Based on my experience working with beginner users, vast majority of users and site owners DO NOT bulk install plugins and most don't have a clue of what WP CLI even is.

Heck installing even a single plugin and configuring it to work properly is a tall order for many.

This is why a guided onboarding wizard, some sort of visible walk through, tooltips or admin notice is needed immediately to help the user Get Started. It also has to be prominent enough, so a new user who's not familiar with the UI of WP admin can identify what they should do next.

All of this is fairly normal behavior in mobile apps, SaaS platforms, and frankly most other software that's built today. When you first get a New Mac, you have an onboarding wizard. It doesn't require you to refresh a screen or click a button to see what you'll be greeted with next. Getting a new Mac is similar to setting up a new website.

When you install plugins on your Mac (i.e Dropbox or another extension), it's done ONE at a time -- most normal folks / beginners don't multi-task in the way a Pro user might. And as you'd expect, any app that you install, in this example Dropbox will open up a guided setup wizard (which in plugins we call onboarding wizards). This ensures that your computer can sync to the cloud and your files are secure.

This is the behavior that any user who uses any type of modern technology has come to expect. Most folks DO NOT use the command prompt, and GUI exists for a reason -- to make technology accessible to all.

It's completely normal and I'd say expected from the majority of users (who are non-techies) that when they install a plugin like WooCommerce or another, that they are immediately taken to the NEXT step like we used to, so they can accomplish the job that needs to be done (i.e add a store to their site). We need to learn from the Jobs to Be Done Framework here.

IMO as the first step, it'd be better for us to REVERT to the old way where the activation allows the plugins to trigger the onboarding wizard vs. requiring a user action of any sort (like it was done before).

Yes in the short-term, this breaks the dependency challenge which is of course an important concern. I know this because Thomas at AM built TGMPA library, but in an attempt to fix a problem that's small on a relative scale, we're creating a much bigger problem right now which affects the ease of use of the most critical aspect of the WordPress platform (plugin ecosystem).

Long term, it would be ideal for us to think of a solution that looks at plugin installation and activation with different jobs to be done framework / use-case in mind. For example, we should think about bulk activation experience differently because bulk activation is the smaller use-case here ... and perhaps we can allow plugin authors a function / way to deal with a different type of experience for "Power Users" who are performing bulk tasks on sites. Along the line, we can think of a different filter / hook for dependency plugin user experience / flow. Batching all plugin installs & activation as one user experience is akin to taking an hammer and treating every problem like a nail.

We need to work together and uphold the values that made WordPress as good as it is today by ensuring that we always prioritize the needs of 95% and that ease of use for non-techy / avg. user remains central in every decision that we make. We're doing this in many areas of the WordPress project right now such as the Block Editor which is bringing the project forward as well as the Data Liberation initiative, but unfortunately in this plugin activation scenario we have seen regression. We shouldn't be afraid to undo / rollback to fix the problem we introduced vs. settling for a less than ideal solution.

I have left the same comment on #61040 since that's where the discussion has moved on to but also adding the comment here since this ticket is followed by more individuals with the power to perhaps undo vs. pushing the change above live in the next release.

[joostdevalk]

It looks like everyone here agrees that we need a better solution. I have thoughts, which I will add to #61040 , about how we could make this all better, but the current situation is... underwhelming from a UX point of view, and I think we should just revert and then come back with a better solution for everyone. I might add that even when we add a better solution like the one proposed in #61040 , we can't break the current flow for at least a few more majors; we need to give all the plugins time to adjust.

The way I look at it this was a hard deprecation that wasn't announced properly. We should only do those when security is at stake, I see no reason to do them for anything else.

https://core.trac.wordpress.org/changeset/58081

[hellofromTonya]

#61269 is a follow-up to this issue, which is currently targeted for 6.5.4

[hellofromTonya]

In fifty-eight thousand two hundred and fifty :

Upgrade/Install: Restore Activate button's href native behavior.

Restores the Activate button's href native behavior by changing the AJAX activation handler introduced in 6.5.0. It restores the pre-6.5 behavior of clicking the "Activate" button, i.e. navigates the user to the button's href (i.e. to the plugins.php UI).

Why?

Feedback was given after shipping [57545] in 6.5.0 (but was unknown during the development and testing cycles) revealed significant impacts for plugins who's users valued the onboarding / configuration experiences.

6.5.3's [58081] and [58083] added a new user action / step to the workflow. Though helpful, it did not fully resolve the impacts.

For the minor, this commit seeks to restore only the "Activate" button's href pre-6.5 native behavior to resolve the regression.

The next phase of the Add Plugins workflow can then continue in a major release to gain the benefits of a full major to move it from ideation through the development phases. (See #61040 ). The questions of redirect, how / should configuration be in the workflow, etc. can best be explored and experimented with in a major.

Follow-up to [57545] , [58081] , [58083] .

Props costdev, jorbin, hellofromTonya, afragen, kevinwhoffman, azaozz, adrianduffell, beaulebens, hmbashar, illuminea, ironprogrammer, jjj, lopo, louiswol94, mikachan, nerrad, mukesh27, peterwilsoncc, pooja1210, smub, swissspidy.

Fixes #61319 .
See #22316 , #60992 .

[hellofromTonya]

With a new direction in the 6.5.4 minor to restore the Activate button's href (see #61319 / [58250] ), the changesets committed for 6.5.3 are now dead code and will not be rendered.

After discussing in ​ Make/Core slack , consensus is to revert both [58081] (on trunk ) and [58083] (on 6.5 branch).

​ Quoting @costdev:

Sure, 68081 (trunk) and 68083 (6.5) should be reverted. They are part of a solution that did not achieve the intended result fully, and have been replaced, not extended, with a different solution for 6.5. If we want to introduce them later, then we still have the code stored in history to save us some time.

As @jorbin ​ noted :

I'm not sure if it will be a clean revert since [58250] also changed some of these lines, but I would support reverting the functionality

I'm reopening this ticket to prepare the reverts. I may need to create a PR first if the reverts are not clean, as Jorbin noted.

Also resetting the keywords.

[hellofromTonya]

In fifty-eight thousand two hundred and fifty-four :

Upgrade/Install: Restore Activate button's href native behavior.

Restores the Activate button's href native behavior by changing the AJAX activation handler introduced in 6.5.0. It restores the pre-6.5 behavior of clicking the "Activate" button, i.e. navigates the user to the button's href (i.e. to the plugins.php UI).

Why?

Feedback was given after shipping [57545] in 6.5.0 (but was unknown during the development and testing cycles) revealed significant impacts for plugins who's users valued the onboarding / configuration experiences.

6.5.3's [58081] and [58083] added a new user action / step to the workflow. Though helpful, it did not fully resolve the impacts.

For the minor, this commit seeks to restore only the "Activate" button's href pre-6.5 native behavior to resolve the regression.

The next phase of the Add Plugins workflow can then continue in a major release to gain the benefits of a full major to move it from ideation through the development phases. (See #61040 ). The questions of redirect, how / should configuration be in the workflow, etc. can best be explored and experimented with in a major.

Follow-up to [57545] , [58081] , [58083] .

Reviewed by jorbin.
Merges [58250] to the 6.5 branch.

Props costdev, jorbin, hellofromTonya, afragen, kevinwhoffman, azaozz, adrianduffell, beaulebens, hmbashar, illuminea, ironprogrammer, jjj, lopo, louiswol94, mikachan, nerrad, mukesh27, peterwilsoncc, pooja1210, smub, swissspidy.

Fixes #61319 .
See #22316 , #60992 .

[hellofromTonya]

Whoopsie, in chatting with @jorbin, reclosing this ticket and opening a new one. Why?

Since #60992 was completed on a closed milestone my thought is a new ticket for historical tracking purposes. (with a see to the original ticket on the commit)

[hellofromTonya]

In fifty-eight thousand two hundred and fifty-seven :

Plugins: Revert r58081 show an admin notice on successful activation.

With a new direction in the 6.5.4 to restore the Activate button's href (see [58250] ), the changesets committed for 6.5.3 (see #60992 ) are now dead code and will not render the admin notice on successful plugin activation.

This commit is a clean revert of r58081 .

Follow-up to [58250] .

Props swissspidy, azaozz, costdev, jorbin, hellofromTonya, afragen.
Fixes #61331 .
See #60992 , #61319 .

[hellofromTonya]

In fifty-eight thousand two hundred and fifty-eight :

Plugins: Revert r58083 show an admin notice on successful activation.

With a new direction in the 6.5.4 to restore the Activate button's href (see #61319 / [58250] ), the changesets committed for 6.5.3 (see #60992 ) are now dead code and will not render the admin notice on successful plugin activation.

This commit is a clean revert of r58083 .

Follow-up to [58250] , [58257] .

Reviewed by jorbin.
Reverts [58083] on the 6.5 branch.

Props swissspidy, azaozz, costdev, jorbin, hellofromTonya, afragen.
Fixes #61331 .
See #60992 .