Several sites from one txp installation?

Destry · 2018-03-21 20:15:11

~~It’s been a few days for this thread, so it’s open for hijacking ;)~~

EDIT by jakob: Forked from this thread as it’s gone off-topic.

I’ve heard about this multisite enhancement — multisite functionality always being something of an enigma to me, and a time has come that I might make use of it, at least in a small way.

But I really don’t know where to begin. Can someone give the general 1-2-3 of it all?

Like with themes, I’m willing to flesh out the basics for user docs, but I need to walk through it myself first for the experience.

Lets say I have domain.tld for resume and contact form (essentially biz stuff) and sub.domain.tld for a personal blog, and would like to manage the two with the same install (or is more accurate to say, same admin-side?)…

Does it matter which domain gets the “admin” install?

Then what’s the main steps?

The challenge, currently is I have the two domains as described, a separate install at each; 4.7 on the sub, 4.6.2 on the main. I would like to merge them to manage as one.

Trailhead? Other things to watch out for?

jakob · 2018-03-21 22:47:49

Destry, my instructions are here but have not yet been brought into the docs (my pull request is still open).

Just to be clear, you don’t have one admin-side for administering two domains. For that you’d need to have some mechanism of saying which article belongs to which domain. What it means is you have one installation of textpattern that can run multiple sites, each with their own public (sub-)domain and admin subdomain.

So, for your situation you might have:

www.domain.tld and admin.domain.tld for your biz site
personal.domain.tld as your blog and backroom.domain.tld as it’s admin subdomain

By way of example, the situation I had when I started investigating this was an education provider that has its own association website and then a series of other websites for its summer school, it’s teacher training weekends, an EU-funded research project etc. They’re all on one server, all share some common aspects in their structure and design, but each is a separate multi-site run from one textpattern installation. I use some common forms and a shared base sass library too but no-one ever sees that.

Bloke · 2018-03-21 23:18:58

Just to throw a little more on top of what jakob said, you still have:

completely separate sites…
… with completely separate config files…
… running on completely separate databases…
… sharing a single core code base.

So if you run ten sites, you have ten DBs, ten private directories with ten different config files, ten image folders, ten sets of login credentials so you can administer each site from each of the ten admin-sides.

But, crucially, when it comes time to upgrade Textpattern, you only upgrade the core files in one place. Next time you log into each of the sites, the upgrade script runs and boom, you’re running the latest and greatest.

Some people take this to extremes and run parallel Textpattern installs. In other words:

/textpattern-4.5.7/… core 4.5.7 files here
/textpattern-4.6.2/… core 4.6.2 files here
/textpattern-4.7.0-beta/… core 4.7.0-beta files here
/textpattern-4.7.0/… core 4.7.0 files here
/textpattern-dev/… bleeding edge files fetched from GitHub here

Then, in each site’s admin filesystem area is a single symlink that points to one of the installations above. Thus Site 1 might be pointing to 4.5.7 because that client is too tight to pay for an upgrade, or because it requires functionality provided by a plugin that doesn’t work in a later version of the product.

Site 2 might be pointing at the 4.6.2 installation. If you want to test if the site works on a later version:

Clone that database and private filesystem to an empty Site 3.
Change its symlink to point to the 4.7.0 install.
Run some tests.
Tweak some stuff and discover everything works great.
When happy, either: a) Copy the DB back to Site 2 and alter the symlink to point to 4.7.0, or b) change the vhost of Site 3 so it assumes the identity of Site 2, and take the old Site 2 offline.

The point is, multi-site allows you to run one or more Textpattern base file sets and use the power of the filesystem to run your sites on N different versions of Txp, where N could be 1 or more. The version of Txp that each site uses is controlled from the config and, in some advanced cases like the one I just described, a symlink.

This makes it very fast to upgrade sites: when Client A pays the bills, you already have a 4.7.0 installation available that’s used for other clients. All you do is break the symlink to the old Txp install, make a new symlink that points Client A’s site at the latest install, and log into the admin side. They’re then at 4.7.0 without any additional FTP faff: you just do that file transfer bit once for each version of Txp that you want to support.

And the beauty is that if you’re a dab hand at shell scripting, this stuff’s all scriptable too.

You can get cleverer still and share template files, as jakob alludes, but that’ll really bake yer noodle!

Destry · 2018-03-22 07:47:02

jakob wrote #310227:

Destry, my instructions are here but have not yet been brought into the docs

Cool!

Thanks both. The mechanics make sense now. Glad I asked, because I was definitely looking at it a different way.

So it’s really about time spent updating installs (at time of new Txp version releases). Thus the benefit increases the more sites you need to update (e.g. web designer businesses).

For peons like me with just two small sites, on the other hand, it’s the difference between grating cheese and slicing it (i.e. not much).

jakob · 2018-03-22 09:09:20

Destry wrote #310220:

Let’s say I have domain.tld for resume and contact form (essentially biz stuff) and sub.domain.tld for a personal blog, and would like to manage the two with the same install (or is more accurate to say, same admin-side?)…

Your question got me thinking. This might not apply exactly to your situation, but for the sake of argument, say you have a situation where you have two sites that share some information but other parts of them need to be separate, another option might be to use one install and use ied_if_domain (download here – this version is the same as Yuri’s just with the tag registered) to differentiate between them:

Make both your domains point to the same textpattern installation / directory
Use ied_if_domain in your page templates and forms to output only the information you need for each site
Make sure you use /relative/links only in your site templates, image src statements etc. or use ied_if_domain to use the specific domain in the url.
If you use automated aspects such as rss feeds or sitemap builders, you’ll need to make custom versions of these to avoid feeding search machines / your rss-readers the pages from the other site with the wrong domain.

How you use ied_if_domain in 2. depends on how similar or different the sites are. If they’re quite different, you could have two sets of page templates and use ied_if_domain right at the top of your main page template to output either your site_a templates or your site_b templates. If they are similar (in terms of their html structure), you might only need to use ied_if_domain in the form for your nav, your footer etc. where you want the link structure to be different. If you have different css for each, your sites might still look quite different even if they are similar in terms of HTML structure.

Advantages:

Input only set of data / articles for both/all sites
Use one set of images and assets for both/all sites

Disadvantages:

You need to structure your site a little more carefully
You need to build your permlinks manually rather than using the txp:permlink tag or tags with link="1" attributes. You should avoid using txp:site_url too. That’s not hard, though. If you’re dead set on having all links with http://thisdomain.tld/section/article and http://thatdomain.tld/section/article, then use ied_if_domain at the top of your page template to set a variable with the current domain and then use that variable in place of txp:site_url.
Tags/functionality that process the entire site (e.g. rss / sitemaps) needed to be remade as custom versions. rah_external_output or mg_setheader is your friend. In txp 4.7 I believe there’s a way now to set custom content-type headers too and simply use a page template or form.
You may be able surf the site structure on both domains. This is more a side-effect than a problem, as long as you don’t feed search machines duplicate content. You could code defensively against this in your page templates to prevent articles or sections being shown on the wrong domain. If you need things very fine-grain, i.e. per article, you might have a custom field that denotes to which domain the article belongs. If it’s sufficient to just restrict some sections, you could make a site variable that holds a list of permitted sections per domain, then use that in conjunction with ied_if_domain to determine if the page being shown matches the sections for that domain or not.

Okay, the disadvantages list looks longer but the issues are not insurmountable. Also the disadvantages all pertain to the site design, the advantages to the running of the site later.

I guess you need to weigh up whether the more careful customisation saves time further on down the line. For sites that share similar content and structure with only a subset for your professional audience, it could be a good fit. Where sites begin to diverge more and you start to have to code more and more exceptions to the rule, then two separate sites might make sense.

EDIT: There’s another plugin like ied_if_domain ~~but I can’t remember what it’s called.~~ It’s called aam_if_host and you can download it here (also with tag registry added). See also this thread for more along the same lines.

Bloke · 2018-03-22 09:33:33

jakob wrote #310232:

If it’s sufficient to just restrict some sections, you could make a site variable that holds a list of permitted sections per domain

If this is the case, then in 4.7 you could use themes per Section. It should be a cinch to detect the domain at the top, set the variable and then use that to only serve content from the relevant section(s) based on the value in the variable.

If you segregate your Page/Style templates into Themes – one for each domain – and assign assets from domain.tld to Theme 1 and assets from sub.domain.tld to Theme 2, you can manage the sites largely independently from a single database. Problems would only arise if you wanted Section name(s) the same on both domains.

Just a thought.

Destry · 2018-03-22 13:23:02

jakob wrote #310232:

…say you have a situation where you have two sites that share some information but other parts of them need to be separate…

That’s more like the scenario I thought multisites functionality addressed. Thanks a lot for the breakdown. You’re like a Textpattern encyclopedia. What would this community do with you and Stef (and etc, and…)? I hate to think about it.

But I will think about the pros and cons you outline. Thanks for highlighting them!

My situation is kind of silly because the only reason I don’t just use a single static page at domain.tld is I want the comm_connect plugin functionality for more secure/private contact reasons. That domain will still just be a single page, but it needs the powa for that one thang.

cschack · 2018-06-18 12:07:18

Hello.

Thought I’d jump in at the end here. I have three mini-sites that I’d like to have as three separate installations. I followed Jakob’s instructions, and created subdomains for site and admin, but when I tried to access the admin folder to setup the site, I get a message: “Forbidden / You don’t have permission to access /setup on this server”.

I’m not very technically adept, so not sure if this is TXP or the server, but thought I’d ask here first. (I’ve had a multi-site WordPress installation run successfully before.) Thank you in advance for any help. (It’s TXP 4.7)

Textpattern CMS

Textpattern CMS support forum

#1 2018-03-21 20:15:11