Modules: XOOPS has gone multisite!! (beta testing)

Posted by: wishcraftOn 2009/3/17 6:51:34 9071 reads
XOOPS has gone multisite!!

Have you ever wanted to have a multiple sub domain or domain propagation for your xoops site? Well now you can, as part of the XOOPS expansion multisite beta testing is now on offer. You can download the install/upgrade from the XOOPS SVN.

Note: since it's beta, do NOT install it on a production site!!!

XOOPS offers the world of difference for both you and your clients but now with multi-xoops you can have the added power of your environment being multi-domain. It also has a firewall (‘Access Policies’). For example, if you are having a multi-lingual site, with this version you could propagate the domains like this:

http://www.example.com – Top Layer of the portal.
http://fr.example.com - French Layer of the portal.
http://gr.example.com - Greek Layer of the portal.
http://nz.example.com - New Zealand layer of the portal.

And so on with your domain propagation, this is one XOOPS, many access points.
The way to set up a multixoops is to have all the domains pointing at the same XOOPS_ROOT_PATH. This will allow xoops itself to determine the domain that is accessing it’s code base and make changes. A lot of modules do not use this feature yet so don’t be surprised on small support for it.

There is a new form object for the domains XoopsSelectDomains.

Download from: http://xoops.svn.sourceforge.net/viewvc/xoops/XoopsCore/branches/tasks/multi-xoops-wishcraft.tar.gz?view=tar

The download include upgrades to this version to cross from old versions of xoops to this one.

Structural database changes

The database has changed due to the relational material required for a multixoops. This includes a new table for a firewall (Access Policies) as well as one for feed collaboration between modules not to mention a domain table (3) based on the configs system of delivery of settings. These tables can be amended with the upgrade, but it may be supportive to have something check for their existence and propagate them with a SHOW Table SQL clause.

Access Policies (Xoops Firewall)

The Xoops Policies system is to provide Agent redirection, IP Range lockout/lockin (useful for Intranet applications) the follow table is defined in the mysql.structure.sql in the install:

The files that interface with this are with the kernel, this is to ensure that the new persitable object system in the XoopsModel are used. The following files exist for this principle.

Quote:

/kernel/policy.php
/class/xoopspolicy.php


As you can see the policy firewall, will be usable by protector and similar products to lock out aggressive IP and details, it can also be used to define agent redirection particularly for example for mobile.examplesite.com extension based on having for example a nokia agent type as a redirection clause.

Resized Image

The form which is used to define this is in the system admin and allows for policies to be deleted or created. For any aggressive hosts the client provides a 403 Forbidden header to be sent to the clients browser.

Xoops Feeds Collaboration

Feeds collaboration is very important, in services like spaces.live.com, facebook and many applications the RSS feeds from the site are a collaboration of all the systems (modules) you have installed on your service. This collaboration includes a wide variety of options to allow for system trends of data to accessed by the feeds.

This has been included in this version so that modules from backend.php & sitemap.php – use a collaboration method to search for RSS data. This includes two new fields in the modules table as well as a new table called newfeeds. This has 2 new subroutines as well in the /kernel/module.php for parsing RSS and Sitemap data.

This is done with a modification to the xoops_version.php to include the functions and files for collaboration.

xoops_version.php - example extensions

// Backend RSS Feed 
// Please note **** Module Developers **** 
// this will be a new clause in module installations. 
$modversion['hasRss'] = 1
$modversion['rss']['rss_func'][0] = "xcenter_backend_rss"
$modversion['rss']['rss_file'][0] = "include/rss.php"

// Backend Sitemap Feed 
// Please note **** Module Developers ****  
// this will be a new clause in module installations. 
$modversion['hasSitemap'] = 1
$modversion['sitemap']['sitemap_func'][0] = "xcenter_sitemap"
$modversion['sitemap']['sitemap_file'][0] = "include/sitemap.php"
$modversion['sitemap']['sitemap_agent'][0] = "all";


This means now there is a way of collaborating your modules RSS and Link Sitemap with the core files backend.php and sitemap.php in the XOOPS_ROOT_PATH. When you install a module these settings are search for as well, this means that data in the sitemap or backend rss feed can autonomously populate itself with this new clauses.It also means the site collaborates correctly data on the backend feed which is and should be inclusive of all data.

There have been changes to the /kernel/module.php to encompass this there is 2 new functions:

Quote:

$module_handler -> function rss($items, $userid, $sort)
$module_handler -> function sitemap($items, $userid, $sort, $agent)


Multixoops – Domain Management

The domain management is done with a model based on the configuration tables already in xoops. There is also a new field called domains which is a mediumtext field in newblocks. It still probably needs to be introduced to the configuration table for configuration on a domain by domain basis.

Resized Image

This is the domains control form. It propagates in the domain tables. It allows for language selection, start-up module and theme primarily. However I have used the configuration table structure with a parent Id selection as well to allow for any direction development with this concept in xoops.

It uses XOOPS Form objects with clean and easily adjustable code. This will allow people both in the core and module development to subjectively add data to domain configuration without affluently affecting the runtime of the configuration scripts.

There is also block management for the domains so you can have a block cloned or different places based on the theme you are running as well the block management is done with the standard form with an edition of selectable domain block.
This ensures that you have a concise distribution and are not down ranked from multiples of the same page on different domains.

Blocks

Resized Image

You can see there is a new option in the blocksadmin to support for selecting a block based on the domain you want it to display in. This has meant there have been some minor SQL changes to the /class/xoopsblocks.php
There are also changes to other parts of the system for the templating system to not conflict this is to the smarty functions as well as some admin cache filenames.