Multiple Joomla websites with in One installation and database - php

Is it possible(out of the box) to have multiple website running on one Joomla installation.
The idea is to give clients a unique domain(or sub domain) and based on the request coming from a particular domain the view should be assembled (theme selection, articles, pages)..
Is it possible.. ??
It important that for each domain we should have a unique theme.
I am not particular about Joomla..If the same is possible with ease in any other CMS like Drupal,etc then please share your thoughts about the same.
Thanks in advance

In Drupal this is called "multisites" and it's easy to have each site have its own theme and/or even have additional modules used only on some sites, but all sites generally using the same Drupal installation. Anyway, what you describe is commonly done in Drupal and not too hard to accomplish.
More info here: http://drupal.org/documentation/install/multi-site

i am not sure about installation, but you can store all the data into a single database, but keep in mind that it is possible with multiple prefixes,
means like you have two joomla sites one with 'jos_' prefix(by default joomla prefix, you can change this) and the other with different prefix

Related

Common index page for 3 drupal sites

I have 3 websites which were built on drupal, 3 are on different sub-domains each. Now i want to built a common index page for all 3 websites in which i want to show features of all 3 websites and to load faster. Also i want to move all the websites to sub-directory instead of sub-domain (Example: www.example.com/site1 instead of www.site1.example.com).
Is this a suggestible method? if done so should i work on.htaccess configuration too?
Please suggest me in this.
Thanks.
You can work with multi-site configuration. This is the most fascinating thing about Drupal. You can use single code base for multiple sites. Then you can configure them in the way you want. You can also define a common index page but its little bit tricky and may require some coding.

Multiple sites with 1 kohana core on same server

I think it has to be possible, but didn't find anything useful yet...
Is it possible to run multiple websites with from 1 Kohana core? Basically all website's are the same, only the layout is different. (Just a different view-folder, (works)) and the content is a bit different. (This is based on constant SITE_ID that pulls it from the db, (also works))
The only two things are, how do I configure this in my bootstrap/index.php? I thought of checking the url. With that url perform a query on the table 'websites' (select where url = '$url') and get the right SITE_ID and view from that query.
In that way both x.com y.com and z.com will pull up the same index.php file. After that SITE_ID is defined and with that id the right content is loaded and the right view is used.
Also, how can I do this in combination with widgets. I have like 8 different widgets and each website displays 3 of those 8 over different pages. So x.com/a will display widget 'widget_1' and 'widget_2', x.com/b will display 'widget_2' and 'widget_3'. But y.com/a has to display 'widget_6' and 'widget_7' and y.com/b has to display 'widget_3' and 'widget_4'.
Is there a way this can be managed? I didn't worked a lot with widgets before and now I want to use it in combination with multiple sites...
Possible?
For multiple sites handled via database within a single instance; what you're doing is similar to a multisite CMS. I have experience developing CMSes, both of the single site and multisite sort; I can tell you through experience that developing a multisite CMS is significantly more complex than doing multiple instances of single CMS. I usually opt for the latter if having multisite is not a requirement from the client and the implementation is up to me.
Have you considered multiple instances of websites with separate folders?
For multiple instances of single sites, I suggest reading http://kohanaframework.org/3.2/guide/kohana/tutorials/sharing-kohana to get a better idea of how do go about having multiple sites with single (or even multiple core).

Creating multilingual wordpress site with shared structure and php functions

I know there are many multilingual wp plugins but I'm not sure which method should I use for this purpose;
I'd like to create a wp site with advanced features, partly coded by myself in php. Then I generally want to create duplicates of this site's structure, design and behavior in other languages, for example, es.blog.com would be a duplicate of en.blog.com. The content, however, shouldn't be shared.
I'd also like to keep changing the code only at one place and make those changes affect all the other languages duplicates, so I assume that means the code itself, or parts of it, would be shared.
Is there a way to have a shared structure, design and functions for several blogs, while the content of each blog is different?
I believe this is a perfect case for WordPress Multisite.
Multilingual Network (forum thread)
I would like for users to choose their language when they first get to the site - so they can choose to read, register, administer the entire site (front end and back) in either English, Kurdish (and perhaps others).
How to set a bilingual or multilingual WordPress multisite blog (blog post)
I need two independent sites to facilitate the plugins and theme localization with an easy way to switch between languages if a translation is available. Another reason is to optimize the search engine indexing. With this solution I can have some language specific posts without translation.
[ update ]
Multilingual Press (plugin)
Each site/blog can then be attributed to a different language. Simply write a post or page in one language and Multilingual-Press will automatically create a duplication of it in the other sites/blogs. These new posts and pages are interlinked and are easily accessible via the post/page editor screen - you can switch back and forth to translate them! Multilingual-Press is WordPress conform, easy to install and doesn't make any changes to the WordPress core. It doesn't harm your website's performance.
You could use any MVC framework to achieve this, and simply store the data in a database with a 'language' field and call only rows from that language.
Google 'MVC Framework'.
A good and free example would be CodeIgniter.
In CodeIgniter, you can include the Wordpress files in your 'libraries' folder then create a model with the specific functions you need to use.
Finally, you would have to create an .HTACCESS file to get the sub-domain section from the URL if you were to use this approach, however, again, there are many tutorials on achieving this, google 'htaccess URL rewrite'
I wouldn't recommend WP for any true multilingual site, searches get messed up, plugin-incompability etc.
Install parallell WP-instances in subdirs and make one the "master" for dev/bugfixes. Content is isolated and you can use standard WP-features without metadata or plugin-hacks.
By "changing the code", I presume you mean the template? It's a simple drag'n'drop in a decent ftp-client.

Serving multiple site with one drupal (not using multi site)

I am looking for expert advice on how to best serve multiple sites with one Drupal instance (using Pressflow 6.x). Let's consider the company needing this is called "ABC Group of Companies" and it has 3 sister concerns. So, altogether there will be four sites:
www.abcgroup.com
www.company-a.com
www.company-b.com
www.company-c.com
Here are the things that are most interesting:
The users will be shared among all
the sites
Each site will "mostly" host their own content (say the welcome text on home page, or menu items - different for each site)
Some contents, will be shown in all of the sites (say, a company-wide notice....or an employee directory)
The theme for each site will be different
Now, I am thinking of having DNS entry so each of the domain point to the same Drupal installation and when Drupal gets bootstrapped, I would like to sniff into the $_SERVER array to know which site is being hit. I'd then like to load the theme accordingly, show the contents specific to that site, and also show the contents that are shared with all the sites.
To make this happen, so far I have created a node type called "Site" and have created four contents for each of the sites. Then for each other content type (say, Page) I have put a node reference to the "Site" content type with multiple value so when creating a new content, the administrator can specify in which site that content will be showed. However, after that I am stuck.
I have tried to understand Contexts, Spaces, PURL - but haven't figured them out fully yet and I believe I could use the community power to help me out. What do you think is the best approach to handle this scenario ?
It'd be greatly helpful if anybody can suggest a direction.
Regards,
Emran
The way you are suggesting is certainly a way that you could do it, but have you considered domain access? I have used it in the past and found it to be very useful. there is also quite a large collection of modules which work with it. Different themes, Options as to which nodes should appear on which sites and shared users are all features that it has.
Hope this helps!
http://drupal.org/project/domain
First up, I strongly second hookds suggestion of using Domain Access Module for this (+1). It has extensive support/features for your scenario and already covers most of the hard parts you'd need to solve yourself otherwise.
Second, if you insist on trying to do this yourself, I can assure you that it is possible, as we have done something pretty similar recently (some special requirements ruled out domain access), but it was a lot of work, especially when functionality provided by contributed modules would not fit well into our 'unusual' scenario.
Given the multitude of special cases you'd have to cover, it is hard to point out a general direction (apart from suggesting to use Domain Access Module ;) but one major point would be to check out the custom_url_rewrite_inbound()/custom_url_rewrite_outbound() function combo. These will allow you to do pretty low level URL manipulations for incoming requests, as well as for URLs generated for output, both of which you'll need to do if you you want to serve multiple domains from the same instance.
Did I mention that you should check out Domain Access Module before you try to build this yourself?
It sounds like there will be virtually no content shared between these sites. Will you be wanting a single login across all sites?
Remember, Domain Access uses 1 shared database.
You could also just do a regular multi-site install, and share certain tables.
I give Domain Access two thumbs up, but just make sure you really need what it actually does.
Also, I would look into the Feeds.module. You can pull content from anywhere (especially another drupal site) and it imports it directly and creates nodes and fields automatically from it.

How to delete drupal's unused core modules correctly?

I want to delete the unused drupal modules like ( blog, Forum, taxonomy ...) but I'm worried if I delete the modules from the modules directory I might cause an error (now or in the future).
Is it safe? and if I deleted the corresponding tables what will happen?
The reason for this is because I want to deliver the site to my client, and teach them how to use the admin page, but I want to make as easy as possible for them.
Deleting Drupal core modules is plain wrong for many reasons, the number one is the newbie intro advice to Drupal.
Don't hack core.
Changing Drupal core files opens up to a world of pain.
What you want is not really deleting the modules anyways. What you want is to remove them from the modules list. Though I personally think it's wrong to do it, as always with Drupal there is a way to do it, without altering Drupal itself. The solution is hook_form_alter(). With it you can just remove the modules fro
the modules list form. That would be the way of doing this.
Instead of deleting modules, you can configure an user for your client limited only to those sections of the admin area you want to show.
It's a better and more general solution.
You could theoretically just delete them out of the modules directory without any immediate problems, but it's not recommended. There's no reason to, and you'd have to do it each time you updated Drupal, among other problems.
There is no point to deleting them. You could download a contrib module later, and it might rely on Taxonomy, Forum, Color, Upload.. etc. I would advise to leave them alone.

Categories