php CMS from scratch vs open source

Question

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-language When 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

Answer 1

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 Dilemma

These 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 analogy

Consider 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 wheel

Are 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 libraries

Libraries 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 world

You 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.

Conclusion

Using 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 conclusion

At 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.

Answer 2

About a year ago I've built a very minimal cms using Laravel for a project that just needed a bare minimum of the functionality.

It took us weeks to develop. And every new feature was again a lot of work to add.

In the end we spent too much time on developing stuff that was not our core product, so I regret to have made the decision that seemed so logical at the time to not use an "overkill" cms for our simple problem.

So nowadays, I ask myself if the feature we're going to build is part of our core product. If yes, then we'll develop it ourselves. Otherwise we'll use the open source tool and be happy with 90% of the features.

Answer 3

In this era I can't think of many circumstances where I wouldn't choose to leverage an existing Open Source CMS.

It's safer to build on top of a well designed codebase than creating the whole thing yourself. Less work keeping up to date on security alerts too. If you build on Drupal and add a couple of homebrew modules all you have to do is keep up with Drupal security alerts and keep testing your additions. If you write everything yourself there could be accidental holes everywhere and nobody else (except blackhats) will be looking for them.

There are issues around upgrading an OS CMS but you're usually getting free security fixes, free additional functionality etc. It's still a cost but less of a cost than regularly refreshing your own CMS.

Optimisation, maybe it is slightly less optimal because it's supporting a generalised implementation, but, on the plus side, people do manage to run really big sites on them and the how-tos are out there if you do make a very successful site - otherwise beware of premature optimisation.

Developing a module from scratch is probably harder than creating a few PHP pages. The benefits are all of the additional functionality you don't have to write from scratch - it's probably FAR more efficient to leverage the os cms than try to create one - although for a very limited small website you may save a small amount of time. But you'll pay that back many times over if the website survives and thrives.

TL DR Pick a good CMS, learn how to use it and expand it.

Answer 4

It really is going to depend on what your business is. However you say:

• We need to use our external user system and permissions,
• The forms are posting to a 3rd party system,
• We have many other very custom features.

Given these requirements I would assume that whatever off the shelf cms you use you would have to implement custom functionality to cover these cases.

You will have to consider how much work that will be vs how much work to add CMS functionality to your existing code.

If you are selling generic CMS websites, then you are going to want all the cms features offered byt he off the shelf product, plus a few custom ones of your own. So the balance will be leaning towards the off the shelf solution.

If you are selling some bespoke sites which need a small amount of user generated content, then you only need a tiny subset of the CMS feature set and you custom stuff will be a large part of your offering. In this case you would lean towards your own solution.

Answer 5

I would avoid the CMS unless you want to commit yourself to that CMS.

As you point out, using a CMS effectively means that you must learn it. Not only that, you must live it, too, as everything you want to do with the system is done through it. That's a great strategy for some types of sites - those that basically involve pages of content. But for others, it might mean one brick wall after another if your way of doing things conflicts with the CMS's way.

Since you are already very familiar with a number of frameworks, and those frameworks offer a lot of the functionality the CMS offers, I don't see the big benefit to using the CMS. It has been my experience that on projects that involve extending a CMS, that the CMS gets you up and running very quickly... and then everything you do after that takes twice as long because you have to fit into its way of doing things.

You mention testing and security. While its true that existing CMS's are tested quite well. You'll also find that's because they are attacked at a very large scale. I used to work on an application based around Joomla. I spent many nights recovering from malicious scripts that used one exploit or another to hose our servers. The core of the system wasn't the problem (though I think the design encouraged some bad practices), it was the extensions that were full of security holes.

Basically, I'm in the "if you have the technical resources to do it yourself, then do it yourself" camp.