Multi-site URL reporting

Bloke · 2017-11-28 10:56:14

During the recent Txp meet in the Cotswolds, our resident guru and fellow TxpBuilder jakob demonstrated a patch for the long-standing issue of incorrect admin URLs. Anyone who runs multi-site installations sees bogus URLs on-screen messages and email links when they run and complete setup, or reset passwords, etc, etc.

That’s because we’ve hardcoded the route /textpattern in language strings and the core regardless of which type of installation you are running. Well this looks to be a thing of the past, but we need your help to prove it. Please, anyone who uses multi-site or who would love to give it a spin or would like to help prove that this patch doesn’t break anything in a regular install, please check out the multi-site-fix branch and see how you get on.

When running in a multi-site environment, there’s an enhanced setup process with a few more bits of info requested, and a natty cookie domain feature to help your sites run cleanly when using maintenance mode or other plugins that span admin and public areas. I’m sure jakob can explain more, because he does this stuff way more often than I do.

Please help us test this patch works in multi-site mode, and also continues to work for single-site installs. Then we can hopefully say goodbye to misleading links in core messages, hooray!

P.S. this is untested for automated installs so any feedback on that would also be appreciated. I suspect it’s not supported so if it doesn’t work, any reports will help us to see if support can be added now or if it’ll have to wait for the next version.

Last edited by Bloke (2017-11-28 11:02:07)

jakob · 2017-11-28 18:46:38

First of all, credit where credit is due: this builds on work already done by Sam, maniqui and maverick, and brings it up to date with the current 4.7 dev branch. It attempts to solve many of the anomalies of the current multi-site setup.

Basic principle

A multi-site setup allows you to use one textpattern installation for several domains. You can use this if:

You have multiple sites on one web host, and want to update them easily
You work with flat files for your templates and want to keep your files for each site separate from the textpattern files. This is perfect for managing sites as separate repositories.
You run multiple sites with different versions of textpattern, or experiment with several versions of textpattern
You want to keep your admin panels totally separate from your public site and all config infos private (also good for single sites)

Prerequisites

You need a web host that:

supports the creation of subdomains, e.g. www.mydomain.com and admin.mydomain.com. Most modern hosts let you do that through their control panel. For hosts that offer root access, you can create your own virtual hosts.
supports symbolic links (soft link). Symbolic links cannot be sent via FTP, so a host must offer, either:
- SSH shell access (best and easiest)
- the creation of symlinks via the host’s control panel (e.g. the cheaper non-SSH plans of the German host, all-inkl, allow you to create symlinks via a command in their web-ftp tool). You have to create the symlinks manually with this method, though.

Setup

The multi-site fork on github includes the /sites folder inside the /textpattern folder. If you want to setup multiple sites parallel to your /textpattern folder, grab a blank repo from here. The README there shows the two different folder structures.

The basic process is:

Rename (or duplicate) /site1 to what you want, e.g. yourdomain.
Set up the subdomain www.yourdomain.com and point it to the site’s /public folder. You can use dev.yourdomain.com or anything other subdomain name.
Set up the subdomain admin.yourdomain.com and point it to the site’s /admin folder

Visit www.yourdomain.com as you would normally and it should give you the usual run setup message but suggests admin.yourdomain.com/setup to start the setup process. If you have used another subdomain name for the admin side, you need to enter your url manually (there’s no way of knowing this at this point).

Then follow the installation process. In addition to the usual information, you will be asked to provide the subdomain of the admin side, e.g. admin.testdomain.com and a cookie domain (usually the main domain), e.g. testdomain.com.

What this solves / what’s new

The installation process should be easier and more automatic, and attempts to deduce the likely input.
The instructions should be correct with correct paths to the config.php location and /setup directory and links to the login areas. The numerous cases of “ignore what it says” in the instructions no longer apply.
No bogus warning messages to ignore in the diagnostics panel. Additional diagnostics infos for multisite setups.
The admin-side txp_login cookie is also readable from the public-side. This means maintenance mode plugins and if_logged_in plugins should work. Proviso: your site and admin area must share the same domain (which is a likely situation).
Proper login link in new user registration email.

Repercussions

For existing regular textpattern setups: none!
For plugin-authors: the introduction of a new constant ahu that points to the admin URL. Use this in place of hu.'/textpattern/' and your plugins will work on multi-site installations too.
Support for the old-style /admin setup without an admin subdomains removed. Was this ever used?

Remaining problems / Unsure

This is all for unix/linux hosts. Can any of this work on a windows server?
The “welcome” article has hardcoded links to the standard admin area that are not then correct and won’t function. Can we inject the correct links during installation?
Not tested all the different plugins mentioned in maverick’s and marjoleink’s thread but several others do work when edited to use ahu as described above.

Misc

The Readme needs updating once decided
Idea: remove the /sites directory entirely from the main Textpattern installation and making the two options available as separate downloadable archives/repositories.

Bloke · 2017-11-29 00:31:06

Fabulous write-up. Thank you so much for taking the time not only to offer the patch but to give insight into what it does, how it does it, and how we can get it working for us.

We’ll need to figure out the Welcome article thing but since it’s now stored as a flat file and injected into the DB at install time, this might be something we can tackle.

Look at vendors/Textpattern/Import/TxpXML.php at the replaceSiteurl() function which replaces all occurrences of siteurl in the file-based welcome.article with the site’s URL. Can we change that in any way to just use ahu instead and remove the hard-coded /textpattern path everywhere it occurs in the document?

philwareham · 2017-11-29 09:22:56

This needs to be a blog article, I think, once the 4.7 beta is live (there are a number of features that will need blog articles to explain them).

jakob · 2017-11-29 17:14:09

Yes, if this makes this to core for 4.7, which I hope it does, then I’ll do some easy to follow instructions.

There are lots of nice things like custom txp::tags, txp:evaluate and more flexible exclude attributes – not to mention theming and automatic installation – that will make life easier.

jstubbs · 2017-11-30 07:57:39

philwareham wrote #308041:

This needs to be a blog article, I think, once the 4.7 beta is live (there are a number of features that will need blog articles to explain them).

Also for Textpattern Tips if you don’t mind – very useful to have multi-sites working. Thanks for this jakob!

Textpattern CMS

Textpattern CMS support forum

#1 2017-11-28 10:56:14

Multi-site URL reporting

#2 2017-11-28 18:46:38

Re: Multi-site URL reporting

#3 2017-11-29 00:31:06

Re: Multi-site URL reporting

#4 2017-11-29 09:22:56

Re: Multi-site URL reporting

#5 2017-11-29 17:14:09

Re: Multi-site URL reporting

#6 2017-11-30 07:57:39

Re: Multi-site URL reporting

philwareham wrote #308041:

Board footer