My client has a Drupal 6 site.
They are now adding another domain to the same site, but the different domain is going to be used by another branch of their company. Therefore, they need some additional content, specific to the other branch's geographic area, in the menu, as well as a slightly different theme on the front page.
So, to make it clearer: domain1.com and domain2.com both point to the very same installation of Drupal on one server, but not 100% of the content is shared between them.
I don't usually work with Drupal, so I'm not sure how to tackle this. How would you approach the issue? Is there a way to add or remove a single menu item depending on the domain that is being used? Is there a way to use a different view in the same scenario?
Both contrib modules and programmatic solutions will be appreciated.
The Domain Access module allows you to have more than one domain with the same database. You can set different themes in the interface per site. This is a good option especially if you have sites where some of the content is shared, while other content only appears on one of the sites. Once it's installed, you'll see an option on the node edit screen to select which sites the content should appear in. Very easy for content editors.
Domain Access is good at managing two different domains with affiliate content (as that's what is designed to do), it does require more configuration that most modules and you need to have control over your site's DNS.
Another good option might be to use Organic Groups. I use this on a site much like the one you're describing. Like Domain Access, you can share the same piece of content with multiple groups. It's just that the Domain Access module is probably a little more streamlined as it's designed to do what you're describing, while OG may require slightly more tweaking.
This use case would suit using a Drupal multisite configuration (http://drupal.org/node/43816) using shared tables. In essence, one site would live in /sites/site1, the other in /sites/site2, with each settings.php file pointing the tables to a shared database table.
Related
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.
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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 12 months ago.
Improve this question
I work for a company that does sites for the pharma industry and we often need to get legal approval before we push any changes live. So, I'd like to migrate a lot of our work to a CMS environment, specifically wordpress but we need the ability to have a staging environment. Is it possible to instead of publishing a page have it publish to a staging environment that someone can browse as with a link as a site. So basically have 2 sites, one staging one live?
Generally speaking other "answers" here are correct, there are alternatives to WordPress that have better built-in support for staging environments and build migrations. However the suggested alternatives aren't exactly equal substitutes to the WordPress platform, so I think it's best to answer the question at hand instead.
WordPress does not natively support hosting the same site from two different hosts. The core relies on absolute URLs stored inside the database and are used in just about every aspect of the core logic. This results in a number of superfluous bugs like the 500 or so related to SSL access because they try to dynamically alter all http:// schemes to https:// on the fly.
As a result when you host on dev.example.com and migrate to staging.example.com and again to www.example.com you have to do very careful search & replace manipulations on the database export each time you switch hosts. And this causes additional problems when you find out that many popular WordPress plugins serialize the URL into values in the database. So when you search & replace dev.example.com with staging.example.com the serialized data which contained the character length of the original value no longer deserializes with the new longer format. Some core contributors believe the solution to this later problem is to only ever setup staging sites with the same number of characters as the production account...
In a similar vein they also suggest swapping host mappings and only ever using the production.com URL on all hosting environments. Depending on your particular use-case requirements this is probably not a valid solution if you need to provide access to off-site clients, tech-illiterate users (versus tech-literate users of course.)
But WordPress itself has a number of great features otherwise and is a very adaptive and powerful rapid development platform. As a result you can extend the core framework to do much of what you need from it. When I was presented with this situation, I had to develop a solution that was viable for all circumstances. Traditionally this problem is solved with root-relative URLs, they work in cross-hosting environments, and they don't suffer from scheme changes, port changes or subdomain swapping practices that are common with staging migrations.
With this plugin: http://wordpress.org/extend/plugins/root-relative-urls/
(biased? yes, I wrote this plugin.) you get root-relative URLs where it's important and dynamic hosts where root-relative URLs don't work (like rss feeds.) All that remains from migrating the site to different hosts is to move the wp-config.php file outside of the www root (one level up is supported natively by WordPress.) so you can maintain different copies on different servers. Or alternatively you can use basic if-statements to distinguish hosts by server name and define key WordPress constants based on the server. In the end your content, code & data will transition seamlessly.
As a note of concern, the referenced plugins require setting write access to the wp-config.php file, a very bad practice from a security perspective for production or publicly accessible servers. Perhaps you can comfortably implement this in a restricted staging environment but then you'd need to disable and remove the plugin in production transitions.
Long story short, yes you can host WordPress in multiple host environments. The long-touted solutions are very case-specific and option-restricted because of the core architecture. But the framework is flexible enough to overcome the core deficit. This core design decision will probably change at some point in the future given the amount of effort the core developers continually spend on overcoming the cascading issues. But there are also devout defenders of the absolute URL religion that will keep the practice in place for the time being. Maybe a different platform that supports server migrations natively (pick just about any of them because most do) would be a better option for you now.
It's possible: Take a look at this Github Gist to see an example on how to switch environments with your wp-config.php file. Furthermore, take a look at wordpress.stackexchange to see some other Qs about this that give you a more in-depth look at the stuff you should consider.
Greg,
An even better CMS with staging environment would be Silverstripe (silverstripe.org). This cms allows for you to browse an entire staging site.
I think that you can try to use some plugins.
For example (fast search on official wordpress plugin repo) wp-deploy or Dev and Staging Environment Plugin (maybe outdated).
Or as alternative you can try to use different wp-config.php files - one for production and one for dev environment and switch them by checking requested url.
If you need to use WP, and need to publish only one or several pages from staging to live site, why not implement kind of tag on pages that needed to be published (seen by live site visitors)? Simple tune up your templates to display tagged or not pages and you're done! Then you can use only one site and maintain both public-available and not-approved pages on the it.
You can as well maintain local copy of your site (stage) and have some script to upload it (at whole) to your hosting - easy to automate task. In such a case, you may want to consider render the whole site into HTML pages and upload (simple rsync) this HTMLs to hosting - the live site will be hard to break as no dynamic script will be there!
But maybe you really should not choose the WP? There are a lot of CMS that support write-approve-publish scheme.
You can create a WordPress Staging environment with just two click with the help of this plugin: https://de.wordpress.org/plugins/wp-staging/
Disclosure: I am the author of this plugin. So ask me anything about it.
I'm having a bit of an application structure design dilemma.
I have created a web app that creates online surveys. It all works fine, but I would now like to create a new site that does different types of online surveys. This new site will be pretty much 95% similar in terms of layout, logic, functions, etc.
Rather than duplicate all the code from the current web app, I'd like the new app to share in the "fountain of knowledge" created by the current app - so to speak.
Can anyone enlighten me with their experiences of doing this sort of thing? Their best practices?
As a rough guide, I'm currently thinking of using symlinks for all the major logic files (library.php, functions.php, etc), and then deciding which logic to use based on which URL the user logged-in from.
Does that sound like a good or bad idea?
Would it be any better or worse to divide the whole system in to 3 sites, with the site in the middle containing all the common elements and logic? This middle site would have no independent use - it would be used from either of the 2 applications looking for functionality and assets, etc.
Any help and experience on this matter is very much appreciated indeed.
I'm very wary of going down a dead-end solution.
Kind Regards,
Seb
Good solution if:
you host your website yourself and creating symlinks between differents virtual hosts is not a problem
you won't have to make significative changes between the 2 websites
But instead of using symlinks, I could take advantage of PHP's include_path directive and put the common libraries in this path. This way, just write your includes relative to this path, the files will be accessible from any site you want on the same server.
The second advantage of using include_path is you can bypass any open_basedir directives which wouldn't allow you to include files which are not in the same virtual host base dir.
This is how I'd do it...
Create a core library.
Create you 2 site directories.
Create site specific code folders in
each site.
Create core library folders in each
site that simlink to the main core
library created.
Basically, lets say i have a webserver and i resell hosting specifically for local churches.
i have 5 churches as clients, i have a simple CMS made for them they are equal copies of the same files, for each website i install the CMS , database and the website, i think it's a waste of resources.
i would like to know if i can do the following, afaik most webhosts have the following structure:
A main directory (home)
www.church1.com (church1)
www.church2.com (church2)
www.church3.com (church3)
www.church4.com (church4)
www.church5.com (church5)
basically i want the CMS to be on the Home directory, and each one of the Churches (clients) would only have a Config file, a Database ant the template regarding their websites.
so the system source code would be shared, but the website design and the database files would be completelly separated.
i'm not a webhosting or a development expert, but i know my way around, i'm sorry if the question is too basic, i'm having a hard time finding if this is possible.
EDIT: I Think Rudu's reference pretty much solved my problem!
Since you are building it yourself, put the include files (application logic) in a folder or include path that is accessible to all the domains. Then you can put your template files, images and stylesheets in the individual domain folders. If you are database driven you can check the domain $_SERVER['HTTP_HOST'] and load results from a certain table or database based off of that. You really can go a lot of different directions here if you are building it yourself.
It is possible - the answer. Exactly - there are some settings ( and now i dont remember them ) that can block it - but set up in all sites that libraries are there and be happy