mRFC 0025: Midcom site startup and configuration.
- Background:
- Site configuration
- Versioning
- Site authentication
- The "midcom_site" array
- Site Configuration
- Implementation
This is an outline for how future MidCOM Sites should be created and configured.
Background:
The current solution to set up MidCOM sites uses the Midgard Template to create sites. The current template is slow and is hard to modify.
For those who do not know, the following is an example of the setup of a very basic MidCOM site.
Midcom goes through three stages:
- initialization and startup
- Content output
- Ending.
The most basic site template for use in MidCOM is this:
<?php
$GLOBALS['midcom_config_local']['midcom_root_topic_guid'] =
"860f1b5af98b409abd916a80cdb0d68e";
require 'midcom.php';
$_MIDCOM->codeinit();
?>
<html>
<head>
<?php
echo $_MIDCOM->print_head_elements();
?>
</head>
<body <?php echo $_MIDCOM->print_jsonload(); ?> >
content(); ?>
</body></html>
finish(); ?>
Site configuration
Today site configuration is contained in parameters to the host. This is fairly inefficient as this generates a large set of queries to the database on every request.
The new system will not use a common rootpage for all sites. Instead common functionality is shared using styles.
Instead of keeping the configuration in parameters it should be kept in a simple pageelement that is included into the request by changing the normal midgard-root.php file to something like this:
<(code-midcom-start)> <-- This element is autogenerated as outlined above
<(code-global)>
<(code-init)>
<(ROOT)> <-- the style calls $_MIDCOM->content()
<(code-finish)>
<(code-midcom-finish)> <-- Calling $_MIDCOM->finish();
The following parameter must be set in the configuration:
$GLOBALS['midcom_config_local']['midcom_root_topic_guid'] =
"860f1b5af98b409abd916a80cdb0d68e";
Versioning
Hosts using this configuration will be defined as using version 1 and have the parameter "midgard", "midcom-configuration-version" set to 1.
$host->parameter("midgard", "midcom-configuration-version", 1 );
Hosts missing this parameter are expected not to run Midcom unless they have set their rootpage to the common MidCOM rootpage used in Midcom-Template today.
Site authentication
Today site authentication is handled by the old Nemein-Auth library. This library is snippetbased and old. The new MidCOM authentication libary exists and should be used instead. Thus there will not be anything authentication related in the simple code-init.
The "midcom_site" array
Today, the template populates the midcom_site array with some objects as well.
This array should only be created in the compability style for the old Midcom-Template.
Site Configuration
Setting of page/host configuration options handled through a datamanager2 schema driven MidCOM.
The editor most be accessable even when the site is down for some reason.
This could be done today using a dummy topic[1] that could be set to run MidCOM with a configuration module, and then run a normal MidCOM session. This is a stopgap measure.
Another option is a very simple stylelement that lets the user edit just the path to midcom and/or the generated pageelement in an atempt to generate a working configuration.
Implementation
The following needs to be done:
- A MidCOM for generating the configuration must be created.
Todays M-T must be refactored into two styles:
- one simple style
- one backward compatible style Both styles depend on a common root style.
A midcom for creating hosts must be made.
- A midcom for creating Sitegroups must be made.
- A midcom that takes the other midcom and makes a Form-wizard out of them must be made.
Please note that many of the implementation details must be left for another mRFC (f.x. how should sitecreation be configured in the future).
[1] Dummy topic Midcom currently needs a topic to be able to run. By creating a set of dummy topics and then setting the $GLOBALS['midcom_config_local']['midcom_root_topic_guid'] it is possible to run a normal midcom component without having to create a local topic for it.