I'm developing a component which has the below structure. This system is developed under Multi-Tenant concept.
www.a.com, www.b.com, www.c.com are web sites which are in different domains but they run the same system. Each website have their own template and web pages in their local database. That's doable.
The system which is ran on these three sites are independent from the mentioned above(templates etc). www.a.com, www.b.com, www.c.com have a one large database where all the system data is maintained. Since the system is developed according to MVC what I want to do is have a single model(multiple models) where all the logic is contained. So if I make a single change in the model it affects the 3 sites.
According to my research, model should be maintained in the cloud. How can I implement such a requirement with MVC(Given I'm using Joomla as my CMS, MySQL as DBs) ? How can I have a single model for all the 3 sites ?
You can put more than one domain on the very same joomla installation without any changes, just add a plugin that's called virtualdomains which will allow you (for free) to choose template and - thus - menus, extensions and available pages for each domain;
Maintenance-wise this will be easy since all is in one box; but the users will see three sites with different content, layout and urls.
Just a couple of warnings:
1) make sure no scripts or css or other local resources are invoked with the url (http://www.a.com/template/xxx/js/jquery.autocomplete.js) vs /template/xxx/js/jquery.autocomplete.js, the first will work badly with cache.
2) handle any intricacies such as same-url on different domains with .htaccess; use a sh404 or similar component to manage the SEF urls.
This model looks quite complicated to me.
It depends what the main goal of this? Its just fetching all articles/users together? But why?
If you are dealing with problem of running one project on multiple Joomla installations I can advise you to put them on single Joomla and than using Virtual Domains (http://extensions.joomla.org/extensions/core-enhancements/multiple-sites/7557) for "copying" the website on other domains. Then you will one database for all your project.
One downside of this is that its mainly suitable for the projects with same component and article structure. Meaning for example local news divided by regions under different domains etc.
For the reference: the solution is really working fast on Joomla 2.5 latest update.
Related
I used yii2 framework to do three sites, the three sites belonging to different servers, their layouts / main.php exactly the same, how to make these three different domain name website share this main.php?For example, a company's community and forums, as well as the official website are exactly the same layout file, which means that the three sites of the header and footer is the
same, according to my current practice, the three sites are writing this layout File and inside the style and pictures, then the problem occurs, if you want to change the footer and the title html, css, js or pictures, there will be three sites together, this is too much trouble. My current idea is to put the main.php file into one of the site's root directory, and then three sites in the frontend / layouts / main.php reference to the main.php inside the code, but how to do pictures and Style, please Experts advise?
You can include remote files using the allow_url_include directive, but this is a really bad idea because of the security risks.
In my opinion the way to go is to build a module with your layout-related files and then update it in the applications, using composer (or any other tool) when you make changes.
You could use a scaffolding like advanced template where different application (eg: backend and frontend) share common code .. Yii 2 Advanced Project Template is a skeleton Yii 2 application best for developing complex Web applications with multiple tiers.
By default the advanced template includes three tiers: front end, back end, and console, each of which is a separate Yii application. front end and back end app share common namespace for models and config and you can extend for place a common layout or other application based on the same guidelines
This template is also designed to work in a team development environment. It supports deploying the application in different environments.
https://github.com/yiisoft/yii2-app-advanced/blob/master/docs/guide/README.md
When should we use multi-module structure (instead simple structure) in php Phalcon?
I have found some multi-module skeleton, such as:
https://github.com/ovr/phalcon-module-skeleton,
https://github.com/phalcon/mvc/tree/master/multiple.
But I don't know should i use this multi-module structure in a project instead use multi projects.
Something i can think about it is: more complex configuration, complex folder structure, my web url be longer (/[module]/[controller]/[action]) and , importantly, performance will be low (for more loading things than).
However, I think that there are something interesting with it (so many ITer had used it). Is there Someone can give me advantages, disadvantages and criterias for selection.
P/s: the same problem with Zend2 Module!
If you are building a single purpose application as an API that does not use Views, you should rather use single module structure. If it will be a realy simple API of for example storing/logging, micro app will do aswell.
Multi module application structure is useful if you are willing to build more complex solutions. For example an public application with public content, but with admin panel. This one would be handy to write in multi-module to separate administrative controllers/views from those public ones.
My habit is to use multi-module structure, because mostly I have to build applications that are CRM's with their API and an public accessible content part (eg. docs). For such purpose it's just handy to create such modules as:
frontend - for controllers accessible by everyone
backend - for controllers accessible after authentication and authorisation like administrative things
API - for API purposes ;)
common - a part I rather am willing not to implement, but in one project I'm forced to put here some abstract controllers that will be extended in other modules.
This way you can keep separate services configuration for each module, what saves you from cutting off things that you are using at purpose of module A, but not on module B. Like authentication part - important for backend, but useless for frontend part. Or Database configuration - slaves for frontend, master for backend, etc. So this may be also a performance-wise solution for big projects.
Update
Sometimes "multi-project" is an option including "multi-module" project ;) It strongly depends on what you are trying to achieve. Eg. if you take API apart, it may be easier to scale it over multiple instances, but at first it costs you an efford to configure separate project.
If system is supposed to be single-server instance or every istance should be absolutely independed on other instances, single multi-module project will be enough - lets say a standar CMS, blog platform, even simple browser game or homepage of mobile app including API for it. But if you are building a whole universum of apps like an internal API to privide content, CRM to manage it and a couple of web pages to serve it, keeping these as separate projects will be easier to manage later.
Well for example I in my application im splitting every functionnality - for example i have model Link - it's splitted to seperate module to have nice application structure where each funtionality is seperated module. It's like less classes to load in loader. Beacause you only need models and routes from each module to load for whole app, and you load other things like librarys/controllers/helpers/services in module.
I'm working on a platform which runs multiple Laravel applications that interact via a single database.
Each Laravel instance is responsable for it's own logic, i.e:
Admin module (own subdomain)
User module (own subdomain)
Homepage module (own domain)
Saas-ish module (different domains)
Now the problem im facing with routing is the following:
I want to be able to create/generate URL's for the other modules in my platform and for each of the domains inside the Saas-ish module
Things i've thought about
Option 1
Make routes a shared folder/file (via git submodules or a package) and generate the route file based on the Saas domains and subdomains with the domain group option (and cache it). While this is a viable option, I'd prefer not to load a massive file with all the routes, when all I need is 1 or 2 per request.
Option 2
All routes in the DB. Make a RouteGenerator which will handle this for me. However I'm thorn in this option, because I think it the domains in the Saas module, (which are basicaly entities in my DB) and the other module's subdomains (which arn't entities in my database) are too different. So this may not be the best option.
One of these might be the solution for my problem, and i'm just not seeing it, OR it's something completely else.
Please share your insight...
No. Just no.
Here is your option: Merge.
This is more or less not optional. You never run the same framework multiple times for different parts of an app. It's a waste of space and awful to maintain.
You MUST merge your application into one.
I'm trying to create a web application to manage multiple websites. I'm still not sure what platform to built upon this kind of app, Node.js or Laravel (PHP). I want the application to be scalable to millions of users with an average of 2 sites each.
Would you recommend SQLLite3, JSON or MYSQL for storing all individual site's data in separate files or a single database with all individual site's data?
How can I prevent users from hacking into each others site?
mainSite >
Common
Site1/config.json, content/posts/, layout/
Site2/config.json, content/products/, layout/
Site3/config.json, content/pages/, layout/
I'm still not final on the above structure. Please help me with getting started with this app.
For scalable system you should use some system that will allow you easy redistribute resourses, so in this case i think node.js is better one, you could find many services that shares resourses for node.js
Big plans. Lots of work. My advise start small.
Setup one website with laravel and see how far you get.
You will get one website with multiple pages.
Laravel is easy, scales, has tons of extensions and a living, vivid community.
You have the choice to clone the website and set the same thing up under a different domain or just a subdomain.
I'm new to Laravel and now figuring out how to use Laravel for this project i'm working on. I have some ideas about approaching it, and like to know how the experts will do the job.
The case
I'm working on a project which has it's CMS, a informative site and about 35 specialized websites. The CMS, informative site and specialized sites are different on content and design. But all the 35 specialized websites are pretty much the same. The design and layout is identical, but the sites contain different content. Currently all sites have it's own codebase, which makes maintaining it very hard.
I'm now looking for a solution that will use just one codebase. CMS and sites share some functionality and both will have it's own functionality.
I'm just not sure about how to do this.
The sites run on a dedicated webserver that has DirectAdmin installed on it. Within DirectAdmin it's possible to create a domain pointer. This way I can create a site which shows the correct content by checking the http_host variable. Also, if someday a specialized site needs different functionality than the other, I can also check the http_host. I'm not sure if the has any consequents for SEO and whether it's a neat solution.
I've read about bundles and thinking of using them for the informative- and specialized sites. The "main" applications directory will then host the CMS. site.com/ will then be the cms, site.com/info will show a bundle which hosts the informative site and site.com/special will show a bundle for the specialized sites.
When use a domain pointer, some domain will show the site of another domain. But I don't think this will work with a bundle when it's located at site.com/(bundle).
I already have a database that distinct content by http_host. I would now like to know how to structure the code (and how to point 35 domains to the right pieces of code).
I hope the experts over here can tell me some of there best practices on how to do this job.
Thanks in advance.
I would recommend you to keep 3 projects (one for each kind of site).
You could combine the main site and the informative site they way you proposed (as a bundle), but the only reason to do so is to share something between them, which is probably not the case since they have different design and content. If it's only a matter of having it on "/info", this is achievable by a well designed Virtual Host configuration (can't give too much direction on that tho).
Although, I would recommend you to keep the informative site on http://info.site.com instead. It feels "right" to me to have different websites on different domains (or subdomains). Some people even advocate this is the correct thing to do, but who knows...
If you have libraries that you may reuse between all projects, I would recommend putting those on a bundle and include that bundle on all projects.
Now, about the 35 specialized sites, you should point all URL's to the same application through Virtual Host's ServerAlias.
On that application, you should defined Environments which let you configure some aspects of it based on the URL. For instance, you can define a different database for each website, create separate log files, languages, anything that is configurable on /application/config. You can also create your own configurations either.