Plugin Manager in Core: Part 4 (installation profiles)
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | base system |
| Category: | task |
| Priority: | normal |
| Assigned: | cwgordon7 |
| Status: | postponed |
| Issue tags: | installation profiles, Update manager |
This is one of four issues to get Plugin Manager in core. The Plugin Manager module in contributions can be found at http://drupal.org/project/plugin_manager. It would be a huge boost to usability if we didn't have to mess around with our file system before we do updates or new module/theme installations. The reason I've separated this into four issues is because otherwise, this will quite quickly turn into even more of a monster patch. I will be updating my patches every Tuesday and Saturday, so getting reviews between each of these regular updates would be awesome :). The four issues I've created are outlined as below:
- #395472: Plugin Manager in Core: Part 1 (backend)
- #395474: Plugin Manager in Core: Part 2 (integration with update status)
- #395478: Plugin Manager in Core: Part 3 (integration with installation system)
- #395480: Plugin Manager in Core: Part 4 (installation profiles)
For more details on the other issues, click the above links.
This issue will deal with integration of installation profiles with the new plugin manager system. The current plugin manager module doesn't do this, but this will open up all sorts of possibilities. First of all, rather than provide a limited subset of core installation profiles during initial installation, we could list *all* applicable installation profiles on drupal.org. This way, we greatly boost the visibility of install profiles - the goal of them is supposed to be to make it easier for a Drupal newbie to set up a site of a particular type, but they don't do much good if the vast majority of Drupal newbies are ignorant of their existence. This is certainly at least part of the reason why we haven't seen many install profiles (along with the need for better API functions).
A second possibility (in addition to the first one) would be using plugin manager to fetch any necessary modules (and themes?) from drupal.org, and install them automatically with the profile. This would save profiles from the necessity of either shipping with all the required contributed modules (and updating whenever any of those modules comes out with a new release) or making its users download any contributed modules themselves (tedious and bad user experience). This issue will explore this possibility as well as the first one, though it may later be split off into a fifth issue.
#1
Postponed pending Part 1, Part 2, and Part 3, though it could potentially go on at the same time as Part 2.
#2
Watch #483987: Decide on direction for default install profile for details on a new default.profile, which hopefully will flush out related issues to shipping with more / better / different install profile support.
#3
Subscribe.
#4
Subscribing.
#5
+1
#6
I'm going to go ahead and see if I can hash out as many functions as I can that don't rely on issue number #2 in the above list. At least this way we should already have some progress by the time this becomes unblocked.
Edit: By Issue #2, I actually mean Part #2.
#7
Subscribe
#8
Tag consistency.
#9
Subscribe
#10
Well, I have an almost working model. Just a few more things and I believe that I might have an initial patch ready to try.
#11
This patch relies on two others:
#395474: Plugin Manager in Core: Part 2 (integration with update status) and
#524728: Refactor install.php to allow Drupal to be installed from the command line
Here's where the problem is... The patch doesn't work. ;) It supplies most of the code that will be needed, but I've run into a slight problem. I was hoping for some community guidance. Basically, I'm trying to call the a function which calls the BatchAPI... before the database is setup.
I see three main options:
1) Work on yet another patch. This time with the intent of allowing the batch API to work before the database is setup. (Probably quite time consuming. Doubtfully worth the effort.)
2) Reorder work flow so that the database gets setup before the stuff gets grabbed. (Painfully easy. Not sure about this method though. It would mean the DB would get setup before the we found out if the module install worked properly. Me thinks this could pave the way for major pain...)
3) As you're reading this, you see a brilliant / underrated way of getting it done. Preferably one that makes me throw my hands up wondering why I didn't see such an elegant solution.
I'm voting on #3.
#12
Tagging.
#13
Incidentally, http://drupal.org/node/596488 was posted on the d.o front page recently. I tried to point out some synergies in a comment, but don't know if it was noticed.