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.

CommentFileSizeAuthor
#22 wordpress_backend-1044692-22.patch1.31 KBhelmo
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sfyn’s picture

This is the only issue tagged as crazy in out issue queue.

I am in awe. Posting the link to Drupal for Evil.

izmeez’s picture

subscribing

jgabor’s picture

Subscribing.

I'd absolutely love this, as the WP-fanboi I am. :)

niccolox’s picture

I think the concept of "site network" should be added to Aegir

would be useful for integration using modules such as Bakery and Deploy

leenx’s picture

Sub - One Hostmaster to build them all!

Steven Jones’s picture

Version: 6.x-0.4-alpha3 » 6.x-2.x-dev
anarcat’s picture

Looks like we have a winner.

https://github.com/andreascreten/wp-cli

univate’s picture

Another potential contender - https://github.com/getsunrise/hydrogen

Steven Jones’s picture

Status: Active » Postponed

I don't think anyone is working on this at the moment, so marking as postponed.

ergonlogic’s picture

Version: 6.x-2.x-dev » 7.x-3.x-dev
Priority: Minor » Major
Status: Postponed » Needs review
Issue tags: -crazy, -shit

I'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 including wp-blog-header.php, which in turn includes wp-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:

/**
 * Bootstrap file for setting the ABSPATH constant
 * and loading the wp-config.php file. The wp-config.php
 * file will then load the wp-settings.php file, which
 * will then set up the WordPress environment.
[...]
 * Will also search for wp-config.php in WordPress' parent
 * directory to allow the WordPress directory to remain
 * untouched.
[...]

/** Define ABSPATH as this file's directory */
define( 'ABSPATH', dirname(__FILE__) . '/' );

Note the latter part of the comment. WP's wp-config.php is the equivalent of Drupal's settings.php. It contains database credentials, various salt values, language and debug settings. This allows us to have a file structure like so:

/var/www/sites/example.com/
/var/www/sites/example.com/wp-config.php      site-specific db creds, etc.
/var/www/sites/example.com/wordpress/         WP code-base

With a very basic vhost like so:

<VirtualHost *:80>
  ServerName example.com
  DocumentRoot /var/www/sites/example.com/wordpress
</VirtualHost>

Moving the wordpress/ out of the site directory and symlinking to it breaks WP, since it defines an absolute path with in wp-load.php, as we saw above. However, a simple patch to the WP code-base does allow this to work. Just replace this:

define( 'ABSPATH', dirname(__FILE__) . '/' );

With this:

define( 'ABSPATH', $_SERVER['DOCUMENT_ROOT'] . '/' );

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.

ergonlogic’s picture

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

wp --path=/var/www/sites/wp.local/wordpress core install --url=wp.local --title="My WordPress" --admin_email=me@example.com --admin_password=****
Success: WordPress installed successfully.

Pretty encouraging!

mvc’s picture

nothing to contribute, except to say great work, ergonlogic!

anarcat’s picture

Amazing! But still crazy shit. :)

ergonlogic’s picture

Here'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

fuzzy76’s picture

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

helmo’s picture

Status: Needs review » Needs work

nothing to review at the moment.

bgm’s picture

Status: Needs work » Needs review

Here'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.

helmo’s picture

Thanks for working on this, I'll try it later this week.

Note that you can #2300537: Merge Provision extensions into Hosting modules

niccolox’s picture

I'll try this also

great work

Francewhoa’s picture

Thanks bgm :)
/ Merci :)

bgm’s picture

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

helmo’s picture

Here's a patch that could help avoid patching the hosting module. I'll post a PR for it's implementation.

bgm’s picture

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

bgm’s picture

See #2763509: Deprecate hosting_context_node_types() for a better fix to the hosting_context_node_types() problem.

bgm’s picture

Status: Needs review » Fixed

Closing!

As far as I know, hosting_wordpress does not depend on any core patches/changes anymore.

helmo’s picture

Issue summary: View changes

Adding a quick link to the resulting module ... https://www.drupal.org/project/hosting_wordpress

Francewhoa’s picture

That is fabulous news. Thanks all :)

fenstrat’s picture

Fantastic. This and the Kubernetes work are great signs of a healthy Aegir ecosystem. Keep up the marvellous work!

Status: Fixed » Closed (fixed)

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