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:

Improve the report page from Plugin Manager

Improve the language, choose and use a consistent name for a "project"

Make a special view of admin/config/modules which just contains the modules in the package you just installed to show after a module install

Write Unit tests for the Updater classes

Comments

Yeah, 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.

@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.

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 *install and enable the module*.

I 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...

Subscribe. Thanks a lot for your hard work on scoping this, folks!

Agreed with yched on enabling modules. Running update.php, that's handy, enabling a module, I'd rather make people do that themselves.

Issue tags:+Drupal 7 priority

Subscribe

Subscribe

Awesome! I'll try to set some time aside to test out these feature and help as much as I can. :-)

subscribe

Badly need some help here folks! Please ping me on IRC / contact form / here to find out what if you aren't sure.

Best,
Jacob

subscribe

Subscribe.

Status:Active» Needs work

Ugh what has happened to the plugin manager? Feels like something serious. Still would understand if Jacob just could not take it anymore.

Sub. I'm ready to test any upcoming patches.

we need the patches written too...

We 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?

Nice, this is one of the 10 exception in code freeze on 7 September.

These 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?

Issue tags:+Exception code freeze

add tag

Hey 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

I don't understand why is a new issue?

This is duplicate? Won't Fix? or the two are different?

This issue is just an overview, it's not really something that will have code on it.

subscribing

@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.

Title:Plugin manager for D7 code freeze spec[Meta issue] Plugin manager for D7 code freeze spec
Issue tags:+Plugin manager meta

This is a meta issue tracking several issues. Modified the title accordingly.

Subscribing. I dreamed about this many, many times.

Hi!

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.

  • Place a button labelled "Suspend active modules" (or the like) in the Module section.
  • If this button is clicked, all enabled modules (let's say they have the state "1") are set to suspended (say state "-1"), thus disabling them but remembering their previous state.
  • Re-label the button "Restore active modules" - if this button is clicked, all enabled modules with state "-1" are reset to state "1"), thus enabling them.

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

Status:Fixed» Closed (fixed)
Issue tags:-Drupal 7 priority, -Exception code freeze, -Plugin manager meta

Automatically closed -- issue fixed for 2 weeks with no activity.