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.
Related
I am looking to reduce redundancies in code shared across entire web sites. I have tinkered with several frameworks but cannot think of any that allow you to EASILY separate the framework code from the site code while sharing it to multiple sites at the same time.
What PHP frameworks can do this easily?
EDIT - I am trying to determine which frameworks are the easiest to share.. I was already guessing that nearly all could be shared, but which frameworks are geared towards sharing? It sounds like Yii recommends placing the framework code outside the site code, that is a good start.
If someone is sharing the same framework code across sites already, I would love to know about that.
It's pretty easy to do that with Fuel (http://fuelphp.com).
Each website has an index.php where some paths are defined:
/**
* Set all the paths here
*/
$app_path = '../fuel/app/';
$package_path = '../fuel/packages/';
$core_path = '../fuel/core/';
As you can see, you may share the core and packages in a central repository and create a single app and public folders to each web site.
You may even share an app with different web sites customizing stuff (let's say, the site title or the database used) by just setting a different environment in the .htaccess. That works out-of-the-box for development/stage/production sites, for example, but may be extended to anything. You may also setup central packages to use in multiple apps. Powerful, easy and just works.
Many can do this. For instance YII is supposed to be installed OUTSIDE of your www-root directory (httpdocs, /var/www/ or something like that). You can use several sites to point to that base dir.
Any framework (or part) that does not need specific settings for your site can be shared among multiple sites I guess.
I believe Zend can do what you ask, possibly even Symfony and Fuel, and I'm sure many other frameworks that allow you to pick what parts of it to use will let you do this.
However, doing so will require you to do a little more configuring to get it all running. Which is kind of why I ended up creating my own framework.
Symfony does. I love the Symfony framework, and it comes with some great frameworks. You might like the Routing and YAML ones. A person I know calls Symfony the best php framework.
Symfony components
Some of the components have their own specific sites
You can find a really good documentation here.
Symfony2 is suitable for your needs. It's a full stack framework with a lot of standalone components. It works with "bundles", a bundle is a kind of container with a complete logic (controllers, model objects, views, assets, configuration, ...). That means you write one bundle and you can reuse it without any problem.
But you can also consider symfony 1.4. One project can handles many applications so your model is shared across these applications and the same code can be reused in all applications. Note an application can be a complete website.
I can't think of any frameworks that do this natively, but you could use several SVN (or hg, etc) repositories to accomplish this. Example using CakePHP:
1 repo has the CakePHP default files. If you wish to update CakePHP,
you update this repo in the future.
1 repo per website that stores everything inside your app folder.
It's not built in functionality, but it isn't very difficult to setup either.
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.
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.
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