I'm struggling to find the right verbiage to use to research a solution for my situation.
I work for a company that has multiple websites and I alone take care of all our sites. Though there is a fair amount of overlap to the content of these sites, each site has been it's own unique entity (custom built CMS, Joomla, static sites and more). It's horribly inefficient when I update a document and have to upload it to 9 different sites.
I'm trying to devise a strategy or system by which images and documents (PDFs mostly) are in a shared space that feeds all the sites. But also the possibility that as we go forward we could have 1 Central Repository for files that has 1 "Engine" that drives it and it feeds to several sites.
I'm not sure if there is a name for such a setup nor what the pros and cons of it would be.
Would love to hear some thoughts on this, some proper terminology that I'm lacking and your thoughts as to it being a custom build or whether their may be a CMS or something out there that might accomplish what we need.
Thanks you for your feedback!
WordPress has a multisite option built in where multiple WordPress sites are run using a single copy of WordPress.
Drupal also has that feature built in - http://drupal.org/documentation/install/multi-site
Joomla has at least one multisite plugin available - http://extensions.joomla.org/extensions/core-enhancements/multiple-sites/5550
Thanks so much for the reply.
I've been looking and just figured out Multi-Site was the term I was lacking.
A few of my sites are actually Joomla.
I'm really stupefied that they still do not have Multi-Site capabilities built into Joomla!
Looking at Magento right now as another possibility.
Though we don't currently do eComm, these are all catalog sites, so they function the same just without a cart/checkout.
Just have to determine which CMS serves our needs the best.
We are actually a wholesaler and sell exclusively to middle men retailers.
One idea I'm having is to have a primary catalog / product feed that is not so much an entire site, but like a stand alone where it does not have a header and footer, but just the main body.
Then if a customer wants it, we can clone it, and give them that clone. Offer them restricted Admin control for style and content.
While their clone would feed off of the primary controlled by us. They could then integrate their clone into their own site. Or we could host their clone as a subdomain off of our primary catalog/feed.
..... if that makes any sense.
wondering if any of these CMSs can handle that (it I even explained it sensibly).
Most vendors I have worked with offer two options:
1.) Hosted solution
2.) Service API
The hosted solution is normally some type of application that you log into and configure different options for your deployment. Never do they actually grant access to the filesystem or code itself. The entire site is built/configured through a GUI. In some cases there is only an area to paste in a header and footer. Than like you are saying the main content is injected. The level of customization exposed through the GUI can either be real complex or real simple. That would all depend on what needs to be done, etc.
The service API is a gateway to the database. So that if a customer feels they are to limited with the hosted solution can actually pull data and build their own site. This would make it possible for any customer to gain access to all the data without the vendor having to integrate or worry about the customers technology stack. The API itself could either be REST or SOAP option depending on your current stack/familiarities with technologies.
I wouldn't mess around with creating an application that is copied over and over. Instead use a hosted solution that resides on your server that offers a limited amount of options. If the customer feels they are to limited with that than refer them to the service API.
And some vendors… really suck. The terrible ones normally only have some type of text file or RSS feed. Those types of vendors are terrible to integrate with.
I'm not really familiar with Joomla. However, I;m very familiar with Drupal. While something like this would be possible with Drupal it would be difficult. Permissions are really scattered and it is quite difficult to manage three global states of a Drupal site. Especially locking down admin features. Possible but painful. Not to mention how many products/variations are we talking here? One thing Drupal does not do well is scale unless you throw a lot of hard-ware at it and "Drupal" oriented server configuration.
In reality though it seems like the only thing your obligated to do is have some type of API to access data. Providing some type of customizable hosted site for customers seems like a little above and beyond the call of duty. Most customers are probably going to integrate directly with their own technology stack anyway. In which case having an API to pull data out of whatever storage facility you have is the only vital thing. Unless you think it is truly a wholesalers duty to provide customers with a website. I really don't think it is. In more cases than not people will probably already have their own sites or no? The return on investment just seems dim for that piece of it.
As someone who works with a lot of vendors I much rather see a well documented, working service API than anything. We almost always integrate with our technology stack anyway. In fact I'm currently integrating several of our real estate vendors data into our technology stack. Luckily they all use the real estate standard for their services API. Otherwise, I would probably want to shoot myself considering we are talking about 13 separate real estate vendors. Standardization is an amazing thing!
- Could also just go the route of the law enforcement system and just have absolutely nothing besides scraping some god awful broken, stuck in the 90s web page.
oddz, thanks for the thorough feedback, I really appreciate it! That's a lot to digest, but I'll start reading up on it.
clone maybe wasn't really the right term for me to use, I was fumbling for words, but it conveyed the basic idea anyway.
We have over 200 products, but they get into a lot of variations and an excruciating amount of detail in some cases. We have some rather large customers who have very nice catalog or even ecomm sites. but we have a fair number of customers who are mom n pop shops that can't/won't invest in their website. we support them with free tools to help them but never on this grand of a scale. we have two separate competitors who have just launched their version of what we are discussing. so, we need to get something out there.
That makes sense. While, I wouldn't recommend Drupal for such a task it could easily handle 200 products w/ the commerce suite. Though creating separate deployments without duplicating the codebase would be a very tough task… very tough. Drupal does not do well when it comes to managing multiple sites under te same database and codebase. There is the domain module and profiles (d7) but profiles use a separate db and the domain module is just… problems after problems because not all modules account for it. The major problem with domain module is that it only account for a slew of modules. It just really becomes a mess considering it hacks into Drupal core in ways NO outside/module code should. If you were to go with Drupal it would be best to use profiles. Though I use that term *best very very lightly. Most of the configurations/what defines a Drupal site is defined in the db so if you have a 100 sites that means do the same thing over and over 100 times unless you can figure out a reliable way to do it through programming alone, which is tough. Especially when it comes to anything related to ctools like views, panels, etc. The best bet is to use features to manage those but that module is a little unreliable at times. You really have to test and vet anything related to Drupal because most of the code is garbage.
If you are comfortable with programming and dealing with LAMP stack I would highly recommend Symfony 2. Drupal just isn't a great platform for creaing web applications. It sounds like what you are trying to create is a web application. A single code and data base that is able to be deployed multiple times w/ different configuration. I would say use a framework rather than a cmf/cms. That way you can model the application any way you want. With a cmf/cms you are kinda restricted to the interface already provided without a ton of customizations and testing.
icky_thump, may I ask if you've made a choice to go forward with any solution? What was your decision?
Hi Pina, no, no decisions have been made. I'm searching for a new development team currently and discussing options with some contacts who are giving us some consultation.
This topic is now closed. New replies are no longer allowed.