Result .... https://www.drupal.org/project/hosting_wordpress
Provisionning other platforms would be nice. Wordpress, even though it has become Drupal's arch-enemy in terms of popularity (i'm kidding), is a quite powerful and user-friendly blogging platform that Aegir could help provisionning "en masse".
Since the release of Wordpress 3.0, I have done some quick reading on the "Wordpress MU" capabilities that were merged into the main program. I wished to share this with the community in case somebody wanted to go that way or had any more ideas, especially about how to do this on the wordpress side...
Note that before this can actually work some modifications to provision and hostmaster need to be performed, see #1044678: alien platform support for that.
Multisite in Wordpress is derived from an old 2.x project called Wordpress MU. A multisite Wordpress is now called a network. Out of the box, a Network is a bunch of Wordpress sites all crammed up in the same database, but in different tables. Also note that it's the "primary wordpress" (for lack of a better term upstream) that behaves like Aegir's "hostmaster" site in that it indexes and manages the multiple sites in the "network".
Installing and upgrading wordpress sites is still performed through the web interface, unfortunately. It seems there's a quite specific "network" process to install wordpress within a network. Previously, this was documented in Installing_Multiple_Blogs but it now seems unclear how that process works other than through the magic web interface.
In general, the biggest hurdle to go through to install wordpress through the commandline is that install.php and update.php are both web-facing scripts that are not adapted to the commandline (from the user's perspective at least, I haven't looked at the code in 3.x).
Another problem is that the network system assumes a certain DNS configuration (wildcard) so it needs a special plugin (e.g. WordPress MU Domain Mapping) to map to arbitrary domains.
More links that could shed light on the install and upgrade process:
http://codex.wordpress.org/Migrating_Multiple_Blogs_into_WordPress_3.0_M...
http://codex.wordpress.org/Upgrading_WordPress_Extended
http://codex.wordpress.org/WPMU
http://codex.wordpress.org/Debugging_a_WordPress_Network
FAQ: No, it's not april first. Yes, I am crazy. No, this is not a troll.
Comment | File | Size | Author |
---|---|---|---|
#22 | wordpress_backend-1044692-22.patch | 1.31 KB | helmo |
Comments
Comment #1
sfyn CreditAttribution: sfyn commentedThis is the only issue tagged as crazy in out issue queue.
I am in awe. Posting the link to Drupal for Evil.
Comment #2
izmeez CreditAttribution: izmeez commentedsubscribing
Comment #3
jgabor CreditAttribution: jgabor commentedSubscribing.
I'd absolutely love this, as the WP-fanboi I am. :)
Comment #4
niccolox CreditAttribution: niccolox commentedI think the concept of "site network" should be added to Aegir
would be useful for integration using modules such as Bakery and Deploy
Comment #5
leenx CreditAttribution: leenx commentedSub - One Hostmaster to build them all!
Comment #6
Steven Jones CreditAttribution: Steven Jones commentedComment #7
anarcat CreditAttribution: anarcat commentedLooks like we have a winner.
https://github.com/andreascreten/wp-cli
Comment #8
univate CreditAttribution: univate commentedAnother potential contender - https://github.com/getsunrise/hydrogen
Comment #9
Steven Jones CreditAttribution: Steven Jones commentedI don't think anyone is working on this at the moment, so marking as postponed.
Comment #10
ergonlogicI'd like to see WordPress support be one of our goals for Aegir 3. From poking around WordPress' installation docs and it's bootstrap code, and I think there's a way to treat WPs similarly to how we treat Drupals. This should make an initial implementation relatively straight-forward.
From what I've read of MU, I don't think it's worth pursuing (at this stage, anyway). It's a completely different model to how Drupal handles multi-site. In fact "MU" stands for 'multi-user', and is more akin to Drupal's Domain Access. However, with a single line patch to WP, we should be able to support something similar to Drupal's multisite. At least, we can have a common platform (code-base) on which to run multiple instances of WP, in separate databases, etc.
Basically, WorpPress' bootstrap starts with
index.php
includingwp-blog-header.php
, which in turn includeswp-load.php
. This file defines a constant (ABSPATH
) that is used throughout the rest of the code-base to define the path to the WP code-base:Note the latter part of the comment. WP's
wp-config.php
is the equivalent of Drupal'ssettings.php
. It contains database credentials, various salt values, language and debug settings. This allows us to have a file structure like so:With a very basic vhost like so:
Moving the
wordpress/
out of the site directory and symlinking to it breaks WP, since it defines an absolute path with inwp-load.php
, as we saw above. However, a simple patch to the WP code-base does allow this to work. Just replace this:With this:
And everything works again! This value is also set in wp-config.php, if not already set, so we'd have to change it there as well, but since we'd have to generate that file anyway, that shouldn't be a problem.
So, this would allow us to build WordPress platforms in /var/aegir/platforms, but we can't install sites within them. So, we'd have to install them somewhere else, such as in
/var/aegir/clients/sites
. This is a bit similar to what we're trying to allow in #1205458: Move modules/themes/libraries/files/private directories out of /sites/example.com, except in reverse. We'd symlink from within the site directory to the WP platform, and the vhost would point to that symlink.Obviously, we'd still need to implement new platform and site entities, but they shouldn't have to be too different. We should still be able to cloak our DB credentials, if we wanted. Backups would probably work very similarly, but clone/migrate would look very different. The latter being something we'd need to tackle for #1205458: Move modules/themes/libraries/files/private directories out of /sites/example.com anyway though.
I haven't looked at if we could support per-instance WP plugins/themes, nor whether this setup would work with the command-line installers. Still, I think it's a viable approach that could, at least, get us moving in the right direction.
I'm setting as 'needs review' to get feedback on the validity and feasibility of this approach.
Comment #11
ergonlogicI tried out wp-cli, which appears to be the most actively developed and maintained. I posted the following issue that addresses some challenges I had with it: https://github.com/wp-cli/wp-cli/issues/478
With those minor tweaks, I was able to install a WP site using the structure in #10 by simply running:
Pretty encouraging!
Comment #12
mvcnothing to contribute, except to say great work, ergonlogic!
Comment #13
anarcat CreditAttribution: anarcat commentedAmazing! But still crazy shit. :)
Comment #14
ergonlogicHere's a patch against WordPress core: http://core.trac.wordpress.org/ticket/24563
Someone commented on an interesting work-around: http://core.trac.wordpress.org/ticket/24563#comment:2. This is particularly interesting, since it'd allow us to use an un-modified WordPress (though we'd need to supply our own index.php), and hints at site-specific content directories as well.
And finally, the current pull request against wp-cli: https://github.com/wp-cli/wp-cli/pull/482
Comment #15
fuzzy76 CreditAttribution: fuzzy76 commentedOnce this actually works, I'd love to see some sort of API / tutorial on how to create alternative backends. I'd actually love to make a non-web backend for gameservers...
Comment #16
helmo CreditAttribution: helmo commentednothing to review at the moment.
Comment #17
bgm CreditAttribution: bgm commentedHere's a proof of concept:
https://github.com/mlutfy/hosting_wordpress
NB: I tested only with Aegir 7.x-3.x-beta, on Debian Jessie, with nginx (although it should work with Apache as well, and if not, should be a trivial fix).
It also requires 2 small patches on Aegir core (one of which will probably break your Drupal sites), and 1 patch to wp-cli. See the README.md from hosting_wordpress for details.
The module supports the creation of a "wpplatform", and the creation of a "wpsite" within that platform. Pretty much anything else is not implemented, including to verify the site (it will loose the site db credentials).
I'm not very familiar with Aegir internals, so please do not use this module as inspiration on how Aegir works. In many cases, I just hit it with a hammer until it works. You can grep "FIXME" or "TODO" for entertainment. :-)
Pull requests welcome!
edit: removed link to provision_wordpress, since it's now included in hosting_wordpress.
Comment #18
helmo CreditAttribution: helmo as a volunteer and at Initfour websolutions commentedThanks for working on this, I'll try it later this week.
Note that you can #2300537: Merge Provision extensions into Hosting modules
Comment #19
niccolox CreditAttribution: niccolox commentedI'll try this also
great work
Comment #20
FrancewhoaThanks bgm :)
/ Merci :)
Comment #21
bgm CreditAttribution: bgm commentedNeat, I merged provision_wordpress into hosting_wordpress, following the instructions in #2300537. Seems to work well (oops, was working offline, and had not seen the PR from helmo yesterday).
If you are updating your environment, don't forget to run "drush @hostmaster provision-verify" so that the drushrc.php of Aegir is updated.
I have also added a few minor things, such as "wp-cli" command line support using, for example, "drush @my.example.org wp user list". It systematically complains that the drush command terminated abnormally, but I'm calling wp-cli in a very bad way, so that's probably not a big surprise.
I will start opening issues on github, if anyone wants to follow from there (https://github.com/mlutfy/hosting_wordpress).
For this specific issue, if the Aegir maintainers are open to it, I would like to find a way to avoid the 2 Aegir patches that are currently required. The patch for the node type could be done with a hook or config options? The other patch for the DB is a bit weirder for me, I guess I should find a way to set the correct variable.
Comment #22
helmo CreditAttribution: helmo as a volunteer and at Initfour websolutions commentedHere's a patch that could help avoid patching the hosting module. I'll post a PR for it's implementation.
Comment #23
bgm CreditAttribution: bgm commented@helmo: is it possible that the patch in # 22 is not the right file? Looking at hosting.module in git, I see no change for hosting_context_node_types().
Comment #24
bgm CreditAttribution: bgm commentedSee #2763509: Deprecate hosting_context_node_types() for a better fix to the hosting_context_node_types() problem.
Comment #25
bgm CreditAttribution: bgm commentedClosing!
As far as I know, hosting_wordpress does not depend on any core patches/changes anymore.
Comment #26
helmo CreditAttribution: helmo as a volunteer and at Initfour websolutions commentedAdding a quick link to the resulting module ... https://www.drupal.org/project/hosting_wordpress
Comment #27
FrancewhoaThat is fabulous news. Thanks all :)
Comment #28
fenstratFantastic. This and the Kubernetes work are great signs of a healthy Aegir ecosystem. Keep up the marvellous work!