Changes between Initial Version and Version 1 of Ticket #61040, comment 59
- Timestamp:
- 05/16/2024 03:41:06 AM (7 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #61040, comment 59
initial v1 5 5 In an effort to avoid a reversion and deliver a better solution in 6.6, I've split out the various opportunities discussed so far in this ticket, stack ranked them according to user need and reach, and recommend pursuing them further in separate tickets across successive releases. 6 6 7 **1. Immediate Need (6.6): Answering the Question, "What do I do next?" After Plugin Activation7 **1. Immediate need (6.6): Answer the question, "What do I do next?" after plugin activation 8 8 9 9 If teleporting users via redirect is no longer a suitable solution, then we ought to provide a clearly marked bridge for users to navigate from activation to onboarding themselves. By keeping the scope small and positioning a solution like the "Open" link as a progressive enhancement, we can avoid reverting Plugin Dependencies altogether and provide a solution that is even better than redirects in time for 6.6. 10 10 11 **2a. Iterative Improvement (6.6 or later): Plugin Dependencies Workflow**11 **2a. Iterative improvement (6.6 or later): Streamline the plugin dependencies workflow** 12 12 13 13 I appreciate that @alanfuller highlighted a few pain points, some of which @costdev clarified are already being addressed. As @afragen said in [https://wordpress.slack.com/archives/CULBN711P/p1715796668735969 Slack], the Plugin Dependencies feature has a long history that should be understood before making further changes. Because of that history, I recommend that improvements to the Plugin Dependencies workflow happen outside of this ticket. We should be mindful of how dependencies affect activation and onboarding, but in order to address Item 1 quickly, we are better off treating the plugin dependency workflow as a detour ''on the way'' to activation that doesn't necessarily restrict what happens ''after'' activation. 14 14 15 **2b. Nice-to- Have (6.7): Combine "Install and Activate" into one step on the Add Plugins screen.**15 **2b. Nice-to-have (6.7): Combine "Install and Activate" into one step on the Add Plugins screen** 16 16 17 17 This would be a small victory that reduces time to value and the steps necessary to activate a plugin, but it does not necessarily need to be coupled with Item 1. We still need to clarify how we are going to maintain the ability to "Install Only" if "Install and Activate" becomes the new default, which is likely to lead to debate. Therefore it is better approached as a separate issue in order to ensure Item 1 can be done in time for the 6.6 release. 18 18 19 **3. Someday: A full-fledged onboarding framework**19 **3. Someday: Add a full-fledged onboarding framework** 20 20 21 21 Some have rightly called out that adding an "Open" link or combining "Install and Activate" does not constitute a framework, to which I say maybe the scope of this ticket was too broad to begin with. This ticket was born out of discussion in #60992 specifically around the transition from plugin activation to onboarding. Item 1 addresses that need and should be our immediate focus for 6.6. Work towards a more complete onboarding framework should happen in concert with the [https://make.wordpress.org/core/2023/07/12/admin-design/ Admin Design] effort and should not be considered a blocker to Item 1.