#222 - Multi-site-networks overhaul

Identifier #222
Issue type Feature request or suggestion
Title Multi-site-networks overhaul
Status Closed (rejected)
Tags

Risk: Core rearchitecting (custom)

Risk: Major rearchitecting (custom)

Handling member Chris Graham
Addon core
Description Composr has:
- multi-install support (Demonstratr)
- multi-site-networks
- zones

People ask a lot about having whole networks of Composr sites, and it's typically people with no money or skill. So it's not really viable.

There are a number of problems:
- multi-installs create one DB per site, which quickly makes things unmanageable
- DB clutter
- requires root level access
- big difficulty applying changes retroactively across all sites (e.g. adding or deleting a menu item)
- generally multi-installs are difficult to manage, it's hard to see the big picture
- multi-site-networks have most of the above problems, and are even more fragmented in terms of control
- zones can be used for sub-sites, but it's not automated. There are lots of features to be set up manually for each zone

I am proposing enhancing what we have already into two separate solutions:
- Simple and centralised: zone templates
- Sophisticated and limitless: multi-sites

[title="2"]Zone templates[/title]

We have already done some draft work on this as we were hoping to use it to make building out zones to include news categories easier. The sites that need this tend to be huge, with whole trees of basically duplicated functionality - under each department.
The idea is you basically would set up a zone, parameterise it carefully, and then clone it. All the content trees and virtual roots would be set up seamlessly.
For this we would need a nice polished API, good documentation, and an admin interface.

[title="2"]Multi-sites[/title]

Without undoing or replacing what we have already, we could combine our multi-site-network and multi-install features into a more seamless system.

Databases:
- Instead of having multiple databases we just have one. We add a new field to each table for "sitename". Not enabled by default, but added en-masse upon first time multi-sites is used on a site.
- Using the SQL 'views' feature in MySQL5 we filter it out based on the sitename field, so each data set appears separate and queries run as normal.
- The usage of the sitename field should not be necessary for multi-sites: it should actually be built into the database API, as an extended syntax for database name. E.g. instead of "cms_site" as a database name, info.php specifies for 'charlie.whatever.com' it is "cms_site:charlie". This way we can continue to use multiple databases if we choose (easier for scaling). So upon such a reference is when the automatic en-masse creation of the field would happen.
- We replace MySQL's auto-increment with random-ID code, like we do in our XML DB driver. (For this to work we'll need to fix a small issue in the chat room where sequential numbers are assumed -- which has already been done for the XML DB driver). The intent here is to switch to GUID-style-IDs, which allows us to make better assumptions about consistent use of ID numbers across different sites (useful for the Commandr command execution stuff described later). It also stops the problem of having weirdnesses now that we potentially have an extra "sitename" key field added next to all the ID numbers.
- The f_member_custom_fields table is an issue, as this table has fields added/removed as CPF's are added/removed. It will need to be more like how the catalogues work: ie. a new CPF does not actually create a new DB field, it creates a new row to store the key/value pair.

Site spawning:
- We turn our informal sites API we have used for Demonstratr and client(s) into a proper Composr API.
- Instead of running an SQL dump script to make network sites, we create sites via cloning an existing site (can be any pre-existing site - i.e. some existing value of "sitename"). Instead of extracting a site template tar, we have code that implicitly knows what directories to make to store the site's files. We make an admin interface for doing this clone, with a few parameters that can be re-set for the cloned site (e.g. site name).
- When you install Composr, the installer allows you to do the "cms_site:charlie" syntax, so that's another way people can setup a site onto a network (i.e. just like the existing multi-site-network scenario, except no separate DB). For multi-site-networks this should be the recommended method, as it allows us to track things better as well as making things more manageable.
- We do [i]not[/i] worry about trying to maintain a 'sites' table of site data, or making an interface for regular users to spawn their own site, or trying to sell sites. That should all be addon territory. But the addons can make use of our API. And if there needs to be some config stuff for sites (e.g. something embedded into default Comcode pages like the site owner's telephone number) then get_value/set_value can be used to maintain that quite easily (which Tempcode and Comcode can use). Maybe we could release an addon here ourselves.

Site management:
- There should be an admin module that can only run on the central site that shows defaults of all other sites in the same database. When they were created etc, all the file overrides on those sites, as well as record counts for each table.
- When actions happen on a central site (the site with sitename='', which is not necessarily the same as the clone source), it logs the queries run and file-ops done into a console (similar to the errorlog screen), in Commandr command form. A clever developer can then extract these commands and use them to make batch-ops happen on all sites via Commandr. This isn't ideal -- obviously in the ideal world Composr would allow you to specify for each action what sites it happens on -- but that would be a nightmare to make happen. So at least we allow a developer to mirror of actions onto all sites. It's already the case that Comcode pages and theme files can be shared across sites (they inherit if not overridden).
- For this to work, Commandr would need to be able to allow running Commandr-scripts in batch mode against all sites. That would be a core Commandr feature.

Upgrading:
- Whenever some kind of upgrade/install happens, Composr should automatically know to make it happen on all sites. It should be smart enough to not try and repeat things like field-additions, but know things like inserting new rows do need repeating.
Steps to reproduce

Additional information Whilst we're talking about a DB overhaul, here's some fixes for long-running DB problems…


Remove auto-increment. Horrible concept, makes merging such a pain

Use default values with add_table_field, so that reverted DB's/old-code does not break so much. This way we get best of both world - upgrades/downgrades go more smoothly, but clean installs are still strict

Give XML export system a sense of table relationships, to grab dependencies (DB meta system will need to have this encoded for it to work) - maybe it should bunch things up when it can resolve simply one-to-many dependencies.
This will make merging a lot easier.

Maybe add an implicit "date added" column to each table, which the XML export system can use for ordering by date. Again, this would make merging a lot easier.
Funded? No
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".

Rating

Unrated