Introduction
This project has had many incarnations, first was the http://drupal.org/project/plugin_manager project in contrib, then #395472: Plugin Manager in Core: Part 1 (backend) and the related issues. This push got us almost to the point of completion before Adrian wrote up a review of it at http://groups.drupal.org/node/24709, which caused some of the authors and contributors to rethink the architecture.
Dries, myself and Adrian met and decided to provide a very limited spec which:
- Is possible to finish by D7 code freeze
- Provides a minimally viable product
- Can be disabled by people who do not want it active on their site(s)
We've created this new issue and its sub-issues to have a fresh start since the previous issues may at this point be confusing, and are incredibly long and hard to follow.
What is outlined here is final and has Dries's approval. This is not to say you can't get suggest stuff you want to see differently implemented, but it is up to Adrian and myself to take a call on it, and we will not increase the scope. This is not because we want to be jerks or power mongers, it's because we want this done by September 1st. At DrupalCon, there will be a BoF where we can scheme phase 2 stuff. Cool?
What we are trying to do (by sep 1st)
Allow Drupal administrators to install new modules on their site and update existing modules without knowing how to use an FTP client or SSH. This will open up the user base of Drupal and make evaluation easier. It is also hoped that will lead to greater stability in contributed modules as they get wider non-developer adoption.
What we are not trying to do (by sep 1st)
(but would love to do in the future)
- Multi-site installs upgrades
- Multiple repository sources
- Version control integration
- Circular dependencies
- Install profile integration
- Backup and recovery
- ... add your feature here
Of course, the more work we all do, the more we get done.
The Backlog and User stories
This project consists of 2 Epics (overarching goals) and a series of stories which fulfill those Epics. For each story, there will be one or many issues which fulfill it. For us to reach a minimally viable product, all of our Must Have (P1) stories must be complete.
Epics for D7 Code Freeze
As a Drupal admin, I should be able to keep my Drupal contributed modules and themes up to date without knowing how to use an FTP client or SSH.
As a Drupal admin, I should be able to browse the available modules and themes on Drupal.org, and paste a URL to a release archive or upload a release archive onto my site and have it be uploaded to the module or theme directory (but not enabled).
Stories and related issues to complete before D7 code freeze
Users using PM should not have PM crash if a contrib module is faulty after an upgrade / install so that there is a chance of fixing it from the GUI
As an Admin, I can upload a tarball containing a plugin, or specify a url to a package and install it
As an Admin, I want to update my modules and themes from my browser so that I don't need to use FTP or SSH directly
What started out as an attempt to make small patches ended up in one honking patch:
#538660: Move update manager upgrade process into new authorize.php file (and make it actually work)
Because we can't get anything committed 1/2 way, it was kinda difficult to split this one up. That being said, it seems to work pretty well, so we just need reviews to get it in.
Follow up issues:
Comments
Comment #1
catchupdate.php refactoring is already in progress at #233091: Move code from update.php into includes/update.inc and #536150: Move more functions to update.inc.
Comment #2
JacobSingh CreditAttribution: JacobSingh commentedYeah, I'm aware of both of these, but I don't think they cut it all the way.
The patch in #536150: Move more functions to update.inc seems to only move one or two functions, we really need them all moved. At any rate, I'll update the description.
Comment #3
dww@JacobSingh: #536150 only moves two functions since #233091 moved about 10. ;)
Nice write up on the effort, sounds completely do-able. Thanks! I'll attempt to be helpful wherever possible, but my time is really tight over the next few weeks.
Comment #4
yched CreditAttribution: yched commentedI wasn't aware this was in the scope of the previous "plugin manager in core" threads. Sounds tricky for "modules" that come as bundles of modules (CCK, Views, Ubercart...) ? Enabling all ubercart modules sounds like a bad idea...
Comment #5
webchickSubscribe. Thanks a lot for your hard work on scoping this, folks!
Comment #6
catchAgreed with yched on enabling modules. Running update.php, that's handy, enabling a module, I'd rather make people do that themselves.
Comment #7
webchickComment #8
int CreditAttribution: int commentedSubscribe
Comment #9
Anonymous (not verified) CreditAttribution: Anonymous commentedSubscribe
Comment #10
xmacinfoAwesome! I'll try to set some time aside to test out these feature and help as much as I can. :-)
Comment #11
joshmillersubscribe
Comment #12
JacobSingh CreditAttribution: JacobSingh commentedBadly need some help here folks! Please ping me on IRC / contact form / here to find out what if you aren't sure.
Best,
Jacob
Comment #13
mattyoung CreditAttribution: mattyoung commentedsubscribe
Comment #14
mcrittenden CreditAttribution: mcrittenden commentedSubscribe.
Comment #15
mcrittenden CreditAttribution: mcrittenden commentedComment #16
eigentor CreditAttribution: eigentor commentedUgh what has happened to the plugin manager? Feels like something serious. Still would understand if Jacob just could not take it anymore.
Comment #17
SeanBannister CreditAttribution: SeanBannister commentedSub. I'm ready to test any upcoming patches.
Comment #18
pwolanin CreditAttribution: pwolanin commentedwe need the patches written too...
Comment #19
int CreditAttribution: int commentedWe just need to porting the update.patch(#395474: Plugin Manager in Core: Part 2 (integration with update status)) to a new page (new module)..
I don't have the skills to help JacobSingh on this. (#536630-12: [Meta issue] Plugin manager for D7 code freeze spec)
So I'm thinking that this is out of drupal 7?
Comment #20
int CreditAttribution: int commentedNice, this is one of the 10 exception in code freeze on 7 September.
Comment #21
jp.stacey CreditAttribution: jp.stacey commentedThese 10 exceptions are also detailed here: Saturday DrupalCon Paris code sprint (Google Docs).
Using the 10 exceptions I am putting together a list of tickets on that Google Doc that people can refer to for Saturday's code sprint. Would a d.o book node be a better place for it? Will others be able to edit it easily, or can documentation only be edited by particular d.o users?
Comment #22
int CreditAttribution: int commentedadd tag
Comment #23
JacobSingh CreditAttribution: JacobSingh commentedHey folks,
I'd like to do a BoF on Friday during the keynote and extending to lunch if people want. Let's try to meet at the registration desk @ 10:00.
My goal is to identify where we are at, and setup a new punch list. I'm also going to be working on git, am using it for the
#538660: Move update manager upgrade process into new authorize.php file (and make it actually work)
If anyone wants to collaborate on my github for this issue, it is here: git://github.com/jacobSingh/drupal.git
See you there!
Jacob
Comment #24
int CreditAttribution: int commentedI don't understand why is a new issue?
This is duplicate? Won't Fix? or the two are different?
Comment #25
JacobSingh CreditAttribution: JacobSingh commentedThis issue is just an overview, it's not really something that will have code on it.
Comment #26
dcoun CreditAttribution: dcoun commentedsubscribing
Comment #27
jp.stacey CreditAttribution: jp.stacey commented@JacobSingh will try to be there. Otherwise, let us know for the Saturday code sprint if there are small chunks of work we can tackle.
Comment #28
xmacinfoThis is a meta issue tracking several issues. Modified the title accordingly.
Comment #29
Chris CharltonSubscribing. I dreamed about this many, many times.
Comment #30
mzuther CreditAttribution: mzuther commentedHi!
I'm currently busy writing my Ph.D. thesis, so I don't have time to look whether this has been said before or whether this is the correct place... :(
But I had a super-simple idea that would make administration much easier in Drupal 7, especially for people whose sites fall into the "What we are not trying to do (by sep 1st)" category.
Right now, when I have to update Drupal core, it takes me four or five runs and a lot of clicks to disable all my modules (because of dependencies), not to mention the part of my brains needed to remember which modules I used. If the above idea was in effect, it would instead take me two clicks with a mouse, while being almost a no-brainer... ;)
Thanks for listening,
Martin
Comment #31
dww#538660: Move update manager upgrade process into new authorize.php file (and make it actually work) is now in core. This is done. Yay!