Multix on ICMS

Hi to all, i'm working in a multix version for ImpressCMS. By now there aren't many differences but, i 'd like to know if you have any idea on this issue, so i can start doing things in the right direction.....


So what do you think???

I think it's an excellent idea indeed.

From what I understand of the Multix concept - it works by one master site controlling others, using the same base-url?

I mentioned to Saganxis about perhaps looking at this as a possibility as well... as could allow more domain flexibility across sites hosted on the same server.

Unbelievable! Saganix, yesterday I was working on exactly that, and today I see this post. It great, I realy need something like multix for an idea I have in mind. I think it would be better than using soap or something. Will you work it for icms 1.0? Thanks

David, I think it does not have to be the same base url.You can have any domain pointing to your site's dedicated IP.

That's even better

Nice... i am back too.... (you can notice that the exams has finished in Argentina ) ... so we will work in MultiX...

I am also very interested... in any kind of ideas... to implement this... to improve the way that is implement.. (really very manual).

Welcome back GABY!.

Nice to see you again here, Nekro. Congratulations for you have finished your exams. Now is my vacation turn: I will come back on 14th August

Ok Debianus!... we will be here...

Thanks for the replies....
I 'd like to explains more or less how multix works:

Multix today:

- there is a "/sites" folder where there are the folders:
sites/all
sites/site1.name.com
sites/site2.name.com

into these folders there is a "config.php" file(like mainfile.php) with the main site costants configurations. And in the /all folder there is a file with the same name. The purpose of this is that you can include some "global" configuration for all sites, e.g: the paths for the editors....
The problem with it is that we use constants for all, so if you include the global configuration file you can not override this values. It 'd be better to work with variables to override this in a better way. Ok this isn't a real problem, but is a bit dirty.

So what we have at this point? We can share the same directory structure for many sites. This is just to ilustrate the configuration parameters:

HTTP
|
mainfile.php
|
-------------------sites/all-----------------
| | |
sites/site1 sites/sites2 sites/sites3
| | |
---------------------------------------------
|
wwwroot

The main goals of this project are:

- Share the same directory structure for many sites
- The posibility to share the same SESSION por many sites which allow the user to avoid logging in in every site(maybe for communities sites).
- The posibility to share tables between sites.
- much more....

Today you can restrict the module and themes you want to be available in a particular site.

Comparing with the drupal way:

Drupal uses a sites/all, sites/default folders(the default is the first site you create).

is not necesary to have a folder with the site name. If you have the sites:
site1.name.com
site2.name.com

you can use a folder named name.com to specify common configurations.

You can put a 'modules' folder and 'themes' folder into a particular site or put it into the all folder.

Supose the following sites:

Drupal:
/sites
/all/modules/news
/all/modules/content

site1.com/modules/formulaire
site2.com

Apart of this you can put a module into the wwwroot/modules folder but they recommend not to put folders there with te purpose that an upgrade don't need much changes.
It happens the same with the themes folders.

So you 'd have the news and content modules for all sites and the fourmulaire module only for the site1.com site.

ICMS:
/modules/news
/modules/content
/modules/formulaire

and in the site2.com configuration file specify the foumulaire module will be disabled.

So at this point we can simulate this behaivor with multix.

Ok supose we want to do some changes in the foumulaire code. It 'd affect site1.com and everybody happy. What what happen if now we want to use the original formulaire module in site2.com. The changes in the code 'll afect all sites!!!!!
Instead in drupal:
create the folder
site1.com/modules/formulaire
with the original code and thats all. Or just put it in the all/modules folder.
The site1.com site 'll use the /sites/site1.com/modules/formulaire code to reference de code.

So here is the problem. We 'd have to define a constant for the module folder like ICMS_MODULE_FOLDER, and it 'd be resolved.
Supose we can modify the core to do this. But what happens with all existant modules????

We will lose compatibility!!! At which point we have to maintain the compatibility with xoops?????

Any idea about this?????????????

Please if you have any idea post to share with the community.
It 'll be a plasure trabis and nekro(gooooossss) to woth with you.

Best regards :) !

Saganix:

Moving modules to sites/domain will make modules stop working not just because of the actual core way to find modules but because modules use most of the times relative urls like for ex: ../../mainfile.php. This would mean to change core and modules.

Making this would be making a new Cms, break 100% with xoops. I don´t think that is iCms idea, but I would vote for it.
I have already crossed this problem when trying to make an Seo module for xoops.
Idealy, modules should be coded to be included just as blocks are. Using functions and/or classes and become independent of fixed position.
This would give extreme power to the core. Ability to easlily use Seo frindely urls and aply your multix idea.

Drupal uses a index.php to load everything, I believe Joomla does it to, MVC aproche uses it to, I think there is a good reason for doing so.

Again, I don´t think this is for iCms, it is not on the roadmap, eheh, but...

We had been talking.. face to face... with saganxis... and we talked about the ICMS_MODULE_PATH... but now i realized with the trabis coment about the problem of the "../../mainfile.php" ... that will be the biggest problem... if some can collaborate with any idea to fix that... it will be really very wellcome!

Another thing to consider....

We're using php5 now - which has (I believe) more flexible copying of files etc...

So - we could, theoretically, copy files from another directory to the site/modules/modulename folder as and when needed?

It's also worth looking at WordPressMU for ideas on this

Perhaps sub.domain.com and domain.com are both ways to handle this - and as for existing modules. perhaps they could be split over domains?

I think we can remove XOOPS_URL constant from mainfile as it is now.

Drupal doesn't have a predefined constant (well, it has, but it's optional). Instead of that, it learns where it is everytime a page is loaded.

In iCMS, there are only two possible paths for a URL: site root and modules folder, so it can't be a big deal to write an script that parses URL and gets domain name and iCMS base URL.

If mainfile-php learns domain name every time is run, and XOOPS_URL is defined this way, we are some steps nearer single install - multisite managing. Example: themes that use $xoops_url Smarty variable.

We can probably remove XOOPS_PHYSICAL_PATH too. I have never seen an autodetection failure on this.

This change has some side benefit: MOving a site from a XAMPP install to the server requires less steps.

I agree that is a good thing... the dinamic information... but is slower... you make the system do something else...

I should have explained this further.

You can define the base URL in Drupal, but it's not required.

If it's defined in the config file, ok. If not, it tries to get it by itself. This is my proposal. Faster XAMPP installation, faster moving to another URL, faster deployment, less config editions. You want to push performance? You edit mainfile.php once you know for sure the site is not being moved.

A good thing on this is that you can prepare an "universal distribution" for several customers at once, and you need only to theme them and change text.

Just a suggestion, anyway. This change's not gonna change anyone's life, but it will help on the way to single install - myultiple sites, and it's making deployment work a bit faster.