Multiple Mambo sites - Page 5

mmx · 17.04.2004, 04:18

Tom... I applied for a project on mosForge and should know if it will be approved within 72 hours. In the least case, I will add your original hack files and my modified files to the project, along with a tutorial for those with little knowledge of multisite operation.

If there is sufficient interest from other developers, it should be possible to quickly build a superpack based on your ideas.

Please leave a PM on mamboserver.com, so I can setup your CVS access.

mmx · 17.04.2004, 05:13

Quote:

Originally Posted by gogoguerilla

The fake front page & admin section loaded up fine when using the files you posted, mmx; however, I can't log-in using the password I created earlier. How do i fix this issue?

Also, will I now simply copy the same files over to the other sites/domains that will use this database? What if they all reside on the same shared host?

Thanks again for your help with this.

Best,

greg

Greg... if support for all_session is not added to setQuery in database.php and the revised com_config is not used, configuration.php is modified each time the Global Configuration is updated. The revised com_config adds the two new configuration variables to configuration.php. Those variables are not added if you do not use the modified com_config, thus configuration.php is rewritten without the two new variables. This prevents login because the configuration is looking for login and ACL information in the default prefixed tables for the site instead of the all_ tables.

To fix the problem, manually enter the two configuration variables back into configuration.php.

I'm working on a solution that eliminates all of the manual changes and the changes to table names and deletion of redundant tables. It's going to take a bit to do this, so have a bit of patience.

After the project is approved, I'll post a tutorial with detailed instructions in the mamSites project on mosForge, along with the latest set of files. The first pass will be the hacked files plus the tutorial. The second revision will include more files and simplify the installation process.

gogoguerilla · 17.04.2004, 06:35

Pardon my not including Tom earlier...

So I've been playing around and made sure that the modified com_config, mambo.php and database.php files were uploaded in /administrator/components/com_config and /classes/ respectively; however, still no love.

Further, I've maually modified the configuration.php file as needed.

I've also tried doin the install process and modifying the "standard" prefix to a new one. Still nothing.

Just thought I'd let you know.

Best,

mmx · 17.04.2004, 07:18

I'll try installing those on a fresh install to see if there are any problems.

mmx · 17.04.2004, 08:07

Your project registration for MOSForge has been approved.

Project Full Name: mamSites
Project Unix Name: mamsites
CVS Server: cvs.mamsites.mosforge.net
Shell/Web Server: mamsites.mosforge.net

Ready · 17.04.2004, 10:33

No love for me today

My expected tech help must have had something come up. So here I am stuck... How to share the users, and manage the permissions seperately on each site?

I have shared these tables using mmx's & Tom's excellent hack:

_users
_sessions

These tables were left unique to each site:

_core_acl_aro
_core_acl_aro_groups
_core_acl_groups_aro_map

I've been digging around in the two following files:

gacl_api.class.php
gacl.class.php

*(Note after reading up on the ACL I feel very confortable changing around the permissions groups, and have tweaked a few to meet my needs.)

Now I am at a crossroads:

Solution #1

Share all the files as outlined by mmx, and expand the ACL by leaps and bounds (I am getting sick thinking about it as the ACL in its current form is VERY basic.)

Solution #2

When an individual registers on the site 2 tables are populated aside from the user table from what I've seen. Would it be possible to INSERT into all the multisite acl tables on registration? This would then allow each site to manage permissions on its own for each common user?

mmx · 17.04.2004, 11:48

Considering the number of hacks required to get this working correctly, it might just make sense to add a site_id to the applicable ACL tables to make it possible to query for the permissions of individual sites. Getting phpGACL to work effectively might require a dependency on ADODB because it was built on top of it (one of the reasons why the core teams decided to add database abstraction to 5.0).

After Robert finishes setting up the new project area, it might make sense to move this thread over to the project forums at mosForge, so we can split this thread into multiple threads dealing with the necessary sets of changes (authentication, acl, installation, configuration, documentation, doc/help translations, etc.).

tomwoods · 17.04.2004, 16:34

Wow, mmx. It's hard to describe how I felt when I came back to check this forum and I found you working so hard on all this, heh. It's like going out to buy the paper and come back to find your baby has grown up (lol).
Ok. Down to business: I think it’s a greater idea that you submitted the project to mosforge, I’m sure they will be interested because, as you say, its a feature that adds appeal to the whole Mambo project. I also agree 100% that we need all the help we can get from experienced programmers, plus, I feel its something that one day should be added as a core option.

Again thanks for all the effort you are putting in this, and to the max of my time capabilities I would like to help out. At lunch break I'll try to slow down and read all the posts.

Cheers to all,
tom

mmx · 17.04.2004, 17:23

Quote:

Originally Posted by tomwoods

Wow, mmx. It's hard to describe how I felt when I came back to check this forum and I found you working so hard on all this, heh. It's like going out to buy the paper and come back to find your baby has grown up (lol).
Ok. Down to business: I think it’s a greater idea that you submitted the project to mosforge, I’m sure they will be interested because, as you say, its a feature that adds appeal to the whole Mambo project. I also agree 100% that we need all the help we can get from experienced programmers, plus, I feel its something that one day should be added as a core option.

Again thanks for all the effort you are putting in this, and to the max of my time capabilities I would like to help out. At lunch break I'll try to slow down and read all the posts.

Cheers to all,
tom

There is a multisite solution in 5.0, so this is going to be a short term solution for the 4.5 version. I worked on this last night and am about to call it a day and get some sleep.

I added a new all_sites table and am building a component to maintain it. On the first pass this will be for navigation only. It will be used with a new Site menu option called 'Switch Sites' that loads any of the sites listed in the table without having to re-log into those sites. This will eliminate the need to re-enter a URL to maintain any given site and allows all sites to be maintained from a central location.

The frontend of the component will be an optional site navigator menu module for navigating among the sites. This could also be handled manually by creating a top level menu item called 'sites' or 'site navigator' or something along those lines. The secondary menu options could be url links to the various sites. The optional navigator module would just automate the menu creation process for those who want to use it.

I'm going to take a crack at building a new Mambo installer that displays a new opening screen with two options--Standard Installation and Advanced Installation. If Standard Installation is selected, the original installation screens will be displayed. If Advanced Installation is selected, a second set of screens will be loaded sequentially. For this set, I'm going to modify the Site Name screen so it uses a data grid control to accept the site name, directory name, and site url of all sites. A radio button will be included to allow one of those sites to be selected as the hub (central site) for the community of sites. The admin portion of the component, mentioned above, will only be installed on the hub and the frontend part will be installed on all sites. The installer will handle the creation of the all_ tables and create the com_components records for all core components without creating tables for those components or any other table that would otherwise be redundant. It will also install the modified com_config component and modified class files. It will copy the original set of files for the hub into the directories for the individual sites and build the configuration files for each of those sites. This should fully automate multisite creation.

The above will note account for any third-party tables an webmaster might want to share across multiple sites. Doing this would require additional component tabs to handle table definitions for the individual sites, assuming those sites were installed correctly using the new installer.

I need to do some reading before attempting to handle the ACL. The solution is probably going to require the addition of numerous tabs to user administration to handle permissions to sites, components and some items associated with components.

With my luck lately, the core team will probably release 4.6 with multisite before this all gets done.

tomwoods · 17.04.2004, 18:16

Hahaha!
Yeah, well. I'll tell you something: its still usefull for those who hacked their Mambo so bad that they cant afford to upgrade their sites to Mambo 5.0 when it comes out, so dont let your spirits dampen.
tom