[Solved] PW3 - Multi-site Update Query

[ridgedale]

Reference: PW 3.0.62 and uikit3 based site using the Regular-Master profile.

I just wanted to check if there is a recommended procedure for updating multi-site installations.

I've got 4 sites running off one installation running PW 3.0.62. Will back everything up before proceeding. Is it simply a case of following the standard update instructions and logging into and refreshing each of the sites one after the other? I'm a little concerned about people trying to access the sites while the update in progress.

Any advice would be greatly appreciated.

[horst]

How is your multisite organized:

One wire folder and multiple site folders?

Or multiple wire and multiple site folders?

Does every site has its own DB, or do they share one DB?

What do you want to update, the sites or the wire folder(s)?

[ridgedale]

Hi Horst,

Thank you for your reply.

The sites are organised as one wire folder with multiple site folders each running site running off its own database following the guidelines for Option #1: Multiple Sites with Multiple Databases.

I'm looking to update Processwire so therefore the intention was to simply replace the wire folder, but I'm unsure of is whether I should take all the sites offline while the sites are are updated and what the advisable procedure should be.

[Tom.]

Hi @ridgedale swapping out the wire folder should be fine. However, ProcessWire is pretty stable and there hasn't been any documented hack so far in the core. There for you shouldn't really need to update unless you:

1. Want the features that have come out in the update (such as I updated a lot of my website for the new focus functionality).
2. There is a bug that is effecting you. 

Otherwise there is very little need to consistently update. 

[ridgedale]

Hi Tom,

Thank you for your reply.

57 minutes ago, Tom. said:

... ProcessWire is pretty stable and there hasn't been any documented hack so far in the core. There for you shouldn't really need to update unless you:

1. Want the features that have come out in the update (such as I updated a lot of my website for the new focus functionality).
2. There is a bug that is effecting you. 

Otherwise there is very little need to consistently update. 

I'll bear that in mind in future. However, the thing is I do need the functionality that Ryan added to the latest developer version (3.0.107) he was working on yesterday, albeit I may wait until the next master version release. Ryan provided that information in his reply to the PW3 - User Trash Access topic.

It would be really helpful to know what steps other multi-site webdevs take to implement multi-site updates. I understand the process of replacing the wire folder but my concern is that each of the sites need to be launched under the backend to apply the update, it would appear and there is always the chance that someone might be browsing one of the sites while the update is being processed and which might have disastrous consequences for the installation/update.

Any further advice would be greatly appreciated.

 

[kongondo]

There's really not much difference to updating a single site. We are talking one wire folder after all. Of course, in the case of a multi-site, any bugs would affect multiple sites. OK, here we go:

1. Backup all your remote sites databases. Get the files as well if doing #2.
2. If possible, replicate your site locally, i.e. replicate your remote server environment locally (PHP version, etc) for testing purposes using the data from #1
3. If #1 was possible, test the upgrade locally. Look out for any clashes with third-party modules. You might have to clear your caches (PW, browser, etc) and compiled files several times for some changes to take effect. If everything's good and/or resolvable, proceed.
4. Perform the upgrade on the remote server. Choose a time when you know things are a bit quite, if possible. You don't have much control here if the site is always busy. However, if you have shell access to your server, using curl or wget, grab the ProcessWire file and save it directly to your server in some temporary folder. Alternatively, ftp to the temporary folder. The advantage of uploading to a temporary folder is to avoid potential ftp transfer issues. Once you have the wire folder upload complete, rename your existing wire folder, e.g. old-wire and copy over the new wire. Normally this should take a few seconds in a server environment.
5. Test your sites. If everything works, great. If not, determine if it can be quickly resolved and meanwhile put your sites on a maintenance mode (see various approaches in the forums) or in worst case scenario, rename the new (the one you copied over) wire to new-wire and revert old-wire back to wire. You'll then have to decide whether to delete new-wire or try the upgrade again if you know what needs to be resolved.

Hope this makes sense.

[ridgedale]

Hi kongondo,

Thank you for your reply.

Backing up the databases and files is no problem. Every time significant changes are made I back everything up beforehand and afterwards.

Replicating the site locally is problematic as I would have to setup a separate linux system to run the local hosting and specific software. My MacBook Pro already runs six separate operating systems.

I have installed a local copy of the files running the same version of PW3 running under MAMP, but that installation runs older versions of the Apache and PHP software.

Again I don't have a problem with this, but as I understood it I need to be logged in to the admin backend to check the progress of the upgrade for errors. Should I be doing that simultaneously for all 4 sites? I would also like to confirm whether or not the upgrade process makes changes to the database tables.

Maintenance mode! I think is what I need to do, albeit if I put the sites into "maintenance mode" I'm not sure how I'll be able to access the sites remotely to test them. Diogo's and Ryan's methods at the end of the Maintenance Mode Message topic should help me with that!  ?

 

[horst]

@ridgedale It is not that problematic if you use one of the modules that support maintenance mode.

1. I would suggest to install a maintenance or page-protection module into all of your sites.
2. And a module for easy cache flushing? (https://github.com/somatonic/ClearCacheAdmin)
3. Then FTP-Upload the new wire folder to something like "wire.new".
4. Backup all your site databases!
5. Login into every site and enable maintenance mode.
6. FTP-Rename wire to wire.old and wire.new to wire.
7. Repeat for every site:
   a) reload page,
   b) use the ClearCacheAdmin and
   c) additionally clear the "modules-cache".
8. See that every thing is running fine and disable maintenance mode.
9. ?

 

[ridgedale]

Hi horst,

Thank you for your helpful reply.

I really like to keep the modules used to an absolute minimum. At present the only additional modules installed are Ryan's Database Backups and Teppo's Version Control, albeit one of the sites does also include Ryan's Twitter Markup Feed. All the latest versions are installed.

I hadn't thought about the caches. I'll have to check how doing so might affect Database Backups and Version Control.

The issue with both the Maintenance Mode and Protected Mode modules is that they both allow sites to be accessed by other users that have accounts. Anyone running a PW update must be certain that no-one else is able to access any of the sites while they are undergoing maintenance.

Having tested Ryan's suggestion at the end of the Maintenance Mode Message topic:

die("Go away! We are trying to upgrade the site.");

I found that because the pages include the sidebar content from separate pages the sidebar content was still being loaded allowing a site to still be accessed through links provided there. That has lead me to the conclusion that the safest way is to redirect all other users (excluding the person managing the maintenance) to a maintenance page located at the domain root.

[ridgedale]

I've been trying to configure the maintenance mode implementation without success as follows:

I created a template using a file named site-maintenance.php and added the following fields:

• maintenance (type: checkbox)
• maintainer (type: text)

Both fields are set to be viewable by all users. The template itself is status: Hidden; viewable by all users; editable by role <site>-maint; no children allowed; no new pages allowed.

I then created a page named site-maint using the above template and set its status to Hidden.

What I am aiming to achieve is when any user tries to browse or login to the website the following check is run (added to the site header) to ensure when the maintenance checkbox is ticked only the administrator user whose username is stored in the maintainer field can access the sites while under maintenance:

$maintenance = $pages->get('/site-maint')->maintenance;
$maintainer = $pages->get('/site-maint')->maintainer;

if ( $maintenance == 1 && $user->isLoggedin() && ! $user->name == $maintainer ) {
    $session->logout();
    $session->redirect("/maintenance.html", false);
}

if ( $maintenance == 1 && ! $user->name == $maintainer ) {
    $session->logout();
    $session->redirect("/maintenance.html", false);
}

The following code on the site-maint page appears to be working without any issue setting both the maintenance and maintainer status correctly:

<?php namespace ProcessWire;
// _site-maintenance.php template file, for managing site upgrades	
if ( ! $page->maintenance == 1) {
	$page->set('maintainer', null);
    $maintmessage = "Status: This site is not currently undergoing maintenance.";
} else {
	$page->set('maintainer', $user->name);
    $maintainer = $page->get('maintainer');
    $maintmessage = "Status: This site is currently undergoing maintenance by " . $maintainer;
}
?>

<div pw-append='content-body'>
<?php echo $maintmessage; ?>
</div>

When users/guests browse the website they are now redirected as required. However, when I test logging in as another user whether a superuser or otherwise the user is still allowed to login. ?

Any pointers to where I am going wrong would be greatly appreciated.

[ridgedale]

I think the issue has been resolved by adding the following to the admin.php file above the require() statement:

$maintenance = $pages->get("/site-upgrade")->maintenance;
$maintainer = $pages->get("/site-upgrade")->maintainer;

if ( $maintenance == 1 && $user->isLoggedin() && ! $user->name == $maintainer ) {
    $session->logout();
    $session->redirect("/maintenance.html", false);
}

and changing the code in the header file to:

$maintenance = $pages->get('/site-maint')->maintenance;
$maintainer = $pages->get('/site-maint')->maintainer;

if ( $maintenance == 1 && ! $user->name == $maintainer ) {
    $session->logout();
    $session->redirect("/maintenance.html", false);
}

Is there anyway to get all the sites to drop into maintenance mode whenever maintenance mode has been switched on in any of the sites? That would greatly simplify the maintenance process.

Any further thoughts appreciated.

[ridgedale]

Correction: Just spotted that the maintainer user cannot log in and also that the maintainer field is not getting updated with the $maintainer username. ?

The only way to regain access is to remove the if () statement from the admin.php, which then re-enables access for all users with a login account.

Where am I going wrong!?

[ridgedale]

Update: See this topic that answers the above question raised.

[adrian]

On 6/23/2018 at 1:16 AM, ridgedale said:

The issue with both the Maintenance Mode and Protected Mode modules is that they both allow sites to be accessed by other users that have accounts

The ProtectedMode module allows you to restrict access to just the superuser if you want so that no-one else can login.

[ridgedale]

@adrian 

Thank you for your reply. From the module description:

Quote

Processwire module to prevent access to front-end of website unless logged in.

Very handy during development/maintenance to allow the clients and testers to view the site, but keep everyone else out.

it appeared to me that the ProtectedMode module would not be able to restrict front- and backend access to a single logged in superuser. Please correct me if my assumption was incorrect.

The multi-site installation I am dealing with has multiple superusers. The solution arrived at, linked to in my previous post, allows a single superuser to manage the upgrade of ProcessWire blocking all other user access to all the websites until the PW upgrade has been completed and websites tested and brought back online, without the need for any modules.

[adrian]

On 7/6/2018 at 9:14 PM, ridgedale said:

it appeared to me that the ProtectedMode module would not be able to restrict front- and backend access to a single logged in superuser. Please correct me if my assumption was incorrect.

It's true that it works by user role, but you could easily give one (or some) of the superusers a different role and block access based on that.

[ridgedale]

@adrian

Thank you for your reply and clarification.

At present the solution outlined previously achieves the desired access control without the use of a role and/or module. I'll have to look into the ProtectedMode module further in due course.