Problem: We have to develop a CMS for our sites. The sites are kind of different, but they have common parts. We need to use our external user system and permissions, the menus are different for each of the sites, the forms are posting to a 3rd party system, and we have many other very custom features.Dilemma: Should we use an open source CMS like Drupal, Concrete5 or Wordpress, that we do not have any experience with? Or should we use a framework like Laravel or Symfony that we're good at?Questions:1) The core of an open source CMS is better tested. That's correct, but if developing shaky modules on top of it would make the site more insecure than creating the modules from scratch in Symfony? I say shaky modules because clearly it takes time to learn how to develop strong modules to an existing CMS.2) The open sources CMS's have lots of contributed extensions. Right, but sometimes the extensions are not compatible one to another. Also, when updating the core of the CMS, we have to update these modules as well. From my experience this gets ugly.3) I'm not sure but I think a custom made CMS is expensive in terms of server load and harder to optimize than a custom one. Is this true?4) Developing new modules could take longer in a open source CMS, especially when there are lots of custom features. Am I right?5) Developing new modules could be painful because of various technical issues that may come out. Are these are valid concerns we should take into account? What would you chose in the aforementioned scenario.Update:Example of custom features:Custom menu module. The front-end must follow a specific design and the design should not be imposed by CMS. Having said that I want to explain why we need to develop a custom menu module: the admin should be able to select the hover color of each menu, the admin should be able to create one, two or three columns of links, sometimes the parent is clickable sometimes is not, when hovering some menu items a picture should be displayed, when hovering other menu items a map is displayed and a tool tip containing an image is focused on a specific country / location; this tool tip has a custom color for each item. Each of the sites might have different menu structures. I was not able to find such a menu in Drupal.User system. We already have a system of users and permissions that we have to integrate in the new CMS. We could duplicate it into the CMS or just override the login and the user functions. This seems challenging. Use third party data. We need to combine external data with CMS data. For instance, lets assume we have a content type called page and some custom fields. In addition to these fields we should use some other fields taken from an external source. I hope this makes sense.Multi-site and multi-languageWhen adding a piece of content we need to select a list of sites that the piece of content will be displayed to. Also for some websites we need the multi-language feature. We need to keep the current URLs of the websites. I think I do not have to explain why this is challenging. To begin with each link we embed in WYSIWYG editor in the content needs to be translated for each site. I realize I probably provided unnecessary details but hopefully this makes sense.Thanks, R
php CMS from scratch vs open source
php;cms;wordpress;symfony;drupal
You'd be crazy to write a CMS from scratch.  My kind of crazy.3rd party software is baggage.We all depend on some amount of baggage; it's unavoidable (unless you are  Charles H. Moore and write everything down to the hardware level).   Pick your baggage carefully. Is 90% enough?An open-source CMS probably covers 90% of the functionality your website needs.  So, clearly you will save a lot of time getting that 90% for free right up front.But there's an immediate downside. You have to learn the CMS.  This is a non-recoverable expenditure of effort.The next, much more serious downside: I believe you should always be focusing on the 10% that is unique to your website.  That's the important part.  That's the part without which, there would be absolutely no need for your site at all.   In fact, the 10% is really all that matters. Without that, you actually have nothing.Using an existing CMS inevitably inverts the priorities.  Instead of focusing on building a system around your core 10% of unique functionality, will now be focused on trying to jam your square peg 10% to fit into the round hole of the 90% the CMS provides.This changes the way you think about your project.  Now, instead of thinking about creating something tailored for your needs, you will unavoidably find yourself thinking about how to bend your needs to fit the flow of the existing CMS.  You will do this because anything else means swimming upstream.  The Framework DilemmaThese difficulties will occur despite the very best efforts to generalize the CMS framework (which I'll refer to as just a framework here).  Because you can't have a completely generalized framework without having the full expressive power of the underlying programming language allowed within the framework.Having the full power of the underlying programming language means losing the advantages of having a framework in the first place - its ease of use!  Now you have two complicated things to learn rather than just one.  The knowledge of the framework isn't even portable.So to avoid the extreme end of the continuum, frameworks must avoid being completely generalized and are therefore cannot be a perfect fit for every project.There's probably a name for this dilemma.  (And if there isn't, it's called The Framework Dilemma and you read it here first.)There are advantages to frameworks, of course.  You're getting all sorts of wonderful, tested functionality straight out of the box.But it's still baggage and (if you're really, truly using it properly) you're still having to learn almost as much as if you'd written it yourself.  And most of your learning will specific to that framework!Let's also not forget that years from now, you will be at the CMS maintainer's mercy for updates or else you must maintain a copy of the CMS yourself.It's a difficult calculation to know if you've gained enough in trade.A template analogyConsider a template language:There are moments in your life when creating your own template system is the most wonderful thing.  You can create a tiny, readable, and beautiful syntax specific to your problem.  It saves you time, its more readable. It's glorious.Nobody else has written this template language before because nobody has solved this exact problem before.  (If they had, you wouldn't be writing this software in the first place!)Well, since it worked so wonderfully the first time, you decide to apply the same template language to another project.  Its needs are 90% similar and you don't want to maintain two separate template engines that are 90% similar because that won't be DRY.  So you make the template language a little more generalized.  Sure, the new template language is harder to read and write because its more general, but it's easy enough and it still works great.  Two projects are using it and your glory has been nearly doubled!Add a third project that is 90% similar to the first two.  And then a fourth. And a fifth.  Oh, and your friend wants to use it with her project, so now there are six 90% similar uses. Your template language has become almost completely generalized.  All this while, the template language has been moving down the continuum from a simple, perfect fit, towards the inevitable Turing-complete one-size-fits all instrument to rule them all.  Inch by inch.Until one day, you realize that you must hang your head in shame. Because as your beautiful little solution has evolved piecemeal over time to accommodate all of the different needs, it has now actually become harder to learn, to read, and to write than the programming language on which it was built.   Realizing this, you scrap the whole idea and go back to writing everything by hand.  On paper. With an inkpot and quill.Don't reinvent the wheelAre you actually making a garden-variety wheel?  You're making a huge mistake if you reinvent the wheel in production. (You should definitely reinvent the wheel now and then for hobby projects.)For the sake of all that is good, don't write your own general-purpose CMS to solve this problem.  If you do that, you really would be better off using a battle-tested existing CMS.If you're going to write your own software, make it a 100% fit for your project.  Lest you end up like the template language analogy above.You're not making a wheel.  You're making a machine with a very specific purpose.  Use existing wheels.Use librariesLibraries allow you to use existing quality code, but in a way that lets you assemble the provided 90% around the 10% core of your custom functionality.    A good library does not dictate your software architecture.  You can keep your priorities where they belong: your 10%.Libraries don't dictate your database schema.  There is no substitute for a well-designed database schema.Libraries are still baggage.  Pick your baggage carefully.  Don't pick something huge if something small will work.  You may end up having to maintain the library yourself someday.Don't write your own crypto algorithms.  Some CMSs and/or frameworks are written so well that you can use them as libraries (or so I've heard).Comparing with the physical worldYou can do a lot with a screwdriver, a hammer, and a pair of pliers. If you were dropped on an island with just these tools, you could accomplish just about anything with them.But these three are absolutely not ideal tools for anything other than driving a screw with a specific head shape and material, driving a nail of a certain size and weight, or grasping a part of a specific size, shape, and material.When quality, efficiency, and safety matter, there are specialized tools in the physical world.  We take this for granted.  I cannot for the life of me understand why people think software is any different.A generalized CMS is a very basic tool set.  It is wonderful when it's what you need.  It's not the right tool set for every job.  Sometimes you really do need a pneumatic flooring nailer or a watchmaker's lathe.ConclusionUsing an existing CMS often seems less scary.  But it shouldn't be.  It should be horrifying.Update:I'm glad you've included some specific features in your question.  It will help my answer look a little less like a manifesto and more like a contrarian form of pragmatism.Custom menu - There is no question that this will be harder to implement as a module for an existing CMS than it would be if it were simply part of a from-scratch project. An intimate knowledge of the CMS module API will certainly be needed. I'm hopeful, but skeptical that there's a CMS out there that would make this pleasant to integrate.User system - This is the perfect example of a really hard problem when trying to interface different systems.  It's not that you couldn't create a hack to make it work - I'm more concerned about the long-term maintenance of such a system. Software doesn't have to be monolithic, but if it's going to share responsibilities with other software, there needs to be a clear divide between the two systems.  Anything else scares me because of fragility.  You'd have to investigate externalizing the entire user system in the CMS - if there's a solid mechanism for doing so, you'll then have to determine the level of effort to implement the client side of that communication on your existing user system.Third party data - Clearly this is going to be more custom modules and, unless you can find existing modules for the CMS and the third party data sources in question, you're going to have to write them yourself (it sounds to me as if you already know you'd end up writing these yourselves). There's no question it will involve more effort up front to implement these as CMS modules.  To be fair, the extra effort may be a blessing down the road as building the modules will require you to properly encapsulate the communication - something you would not be required to do when creating from-scratch sites. (That's what good, old-fashioned discipline is for, right?)Multi-site/multi-language - if there's a CMS which already supports this, it may give you an instant leg-up.  If there isn't, I can't imagine adding it would require anything less than mucking about in the CMS's internals.  Perhaps you could bend an existing feature such as tagging into service to help?  (Ah, but here I am trying to shape the problem to the CMS, rather than the other way around. A lesser person than myself might say something pithy like QED here.)There are an additional two parts from your original question which I neglected to address before:Security - Yes, a system is only as secure as its weakest link, and that could include shoddily-written modules.  Furthermore, more code is more potentially insecure code.  Even with a ton of volunteer eyes, an existing CMS is still a whole lot of lines of code you and your team didn't write.  Server load - I could see this going either way - the CMS may have had quite a bit of work put into this area already (caching, etc.), so you might have an advantage from the outset.  On the other hand, if you're running into specific problems, it will be far easier to fix them in your own code than hunting them down in the CMS (and getting them approved and pushed back upstream - and failing that, do you maintain your own fork?).Updated conclusionAt worst, it would definitely pay to at least look at the existing CMSs as if they were a collection of parts to be sifted through, looking for diamonds.  It's likely that no single open-source CMS supports everything you need, but one of them might have a really nice solution for at least part of it. One with, say, an MIT license would allow you to grab a feature you like and use it in a library-like fashion in your own framework.I think your question is already well-reasoned and full of healthy skepticism.  Deciding whether or not to use 3rd party software is super hard.  It's like choosing between having a dangerous animal as a pet or being all alone on a solo journey to Mars.  You're either going to live with some fear of being eaten, or you're gonna be lonely.