CakePHP advice on configuration for main app with several sub-apps_问答_开发者

I need to create a website like this:

Home page with public access for everyone.
This Home page contains a login/register section and links to several mini-sites (the amount will start small but will grow over time)
The minisites will have same header (logo/menu) and footer (contact, privacy policy) as the home page. What will change is the main content
To access any of those mini-sites, user bust be logged in

Doesn't sound very complex right? This is the way I'm thinking now (which obviously I'm not sure it's the best way, that's why I'm asking for advice):

One CakePHP app with a global autentication system (using Auth)
Each mini site would be just a different page of the site, with its own controller and views (and model if necessary).
So there would be www.mysite.com/mini-site1, www.mysite.com/mini-site2, etc

My main concerns about this system are 2:

What if the number of mini-sites grows a lot? There would be a lot of controllers, view folders, models and who knows if layouts, elements, etc... Maybe not the best organization
What if mini-sites get more complex? More tables, controllers, scripts, css...

Maybe I'm worrying too much and my concerns are not such an issue, but I would like to know if anyone has any advice for an alternative configuration. For example, having one main page (cakephp app), which would be the home page, and each mini-site being a sub-app开发者_运维技巧 (also in cakephp), whose access would be controlled by the main app. This way it would be much more organized, with each mini-site in a different folder with its own controllers, views, models or whatever it needs, and being as complex as it required. I don't even know if this is possible, or how the server and folders configuration would look be. I have some experience with CakePHP, but not that much.

Any ideas/advice would be much appreciated!

If you are truly building multiple apps then cake has a built in "plugins" architecture that allows you to build stand alone apps inside of a plugin structure that sits a top a main application layer.

We have one we developed here at work that has a main application level that manages all user data, authentication, ACL and has some utility functions that go across all apps, including notifications.

We then have plugins as cake calls them such as Ticketing, a File share and CMS. Each of these look like Cake apps with their own views, controllers and models and sit in a directory under the apps => plugins directory.

It works well, but takes considerable planning to make sure you dont create unnecessary apps or a birds nest of stranded code.

More on plugins here: http://book.cakephp.org/view/1111/Plugins

I have a few CakePHP applications and my preference is to have a app for each site and share the cake source. Plugins are neat as a way to create features and reusable functionality. They keep the main code base lightweight and I agree that helps. They will not help you to customise the routing or configurations of the application.

When I first researched this for my project I explored using plugins as an option but saw the lack of standard control over the core configurations and routing as a pain point. Accessing a database or any data source in this environment can become tedious if you have multiple sites. Especially if each site has its own data sources, routes and configurations.

The way I saw it any deviation away from the "CakePHP way" was not ideal, how complicated was it to run multiple sites off 1 app code base?

Challenges

Are all your routes the same, or do some sites need different rules.
Is your functionality the same for all sites or are there some differences that can cause you to hack at your core code.

Imagine this in any configuration or app_controller.php

if($domain == 'first.example.com'):
#This is the first time I override this value, is it the last?
endif;

Without an end in site, I found my development time was being spent finding clever ways of abstracting this. Not the core functionality I craved.

To prevent the proverbial birds nest I opted to create a single app directory for each site. The main reason for me doing this was to prevent the above mess from developing in the code base. I run multiple app sources but using a bash script and source control this is easy work compared to the time it takes to think of a clever way to abstract all of this in 1 app.

Why

Your sites become easier to test and manage. It helps that each site has its own cache, and log locations as well so if something does happen you have more focused debugging time. You can even share you plugins directory across all the sites. Its easier that way because the complexity of managing multiple environments is take care of.

While it might be perceived as sub-optimal to have a code base for each site. I believe that is part of the process of pragmatism. You decide what is right for you, I know there are a few people who talk of success using a single solution. The choice is yours.

If you decide to go the route of having 1 app for each site. This is similar to my folder structure

/var/www/cakehost/first.example.com/current #Symlink that points to the latest revision.
/var/www/cakehost/second.example.com/current #Symlink that points to the latest revision.
/var/www/cakehost/third.example.com/current #Symlink that points to the latest revision.
/var/www/cakehost/src/cake

Once you have decided to export 1 app for each site you simply use the bootstrap.php file the way it was intended.

I use a script to export a boilerplate "app" from my source control. The app runs in all the environments with no hacks. Any deviations come from the the bootstrap.php file. To help simplify this you could create a single plugin directory and symlink to it from all the sites.

/var/www/cakehost/plugins/ #Symlink source for each app.

Even if it seems like an unnecessary duplication, my code remains tidy and testing is dead easy. I tried using 1 app for everything with plugins it was not never quite right.