Adam Davis said:
I want to share an answer with you.
Question: “Is it better to create your own CMS or to use Drupal when we have to implement a lot of self-made applications?”
Answer: “I think it’s oversimplifying the answer to say Drupal saves work or time (or to say doesn’t). Sure, Drupal can get you up and running with a website quickly, and probably with 90% of the functionality you need with core and contributed modules. But your website will probably look and behave like 90% of websites out there. That can be ok. But I have often found that making simple changes or customisations in Drupal can take far longer than they would in a well documented/understood PHP application built around a code library or framework. Add to that the time you need to dedicate to testing and applying security updates to core and modules and your access to knowledgable Drupal resources – you will have a lot more to consider in making your choice.
I think Drupal is a powerful framework, and I use it for many projects. But here are a number of caveats to using Drupal that I have come across in the last few years of using it. These mostly apply to developers who are capable of programming and developing advanced functionality, and for whom the choice of a bespoke CMS or Drupal is a real feasible possibility. If you are not a developer, or don’t have access to developer resources, you need a ready-to-go CMS like Drupal or WordPress.
- If you want your site to be different, the developing the remaining 10% functionality can be a hellish journey for developers using Drupal. Custom module development for Drupal is not for the light hearted. It involves developing with a level of abstraction from native PHP and bending modules and core functionality that is in some parts poorly documented, and in others goes against best practices you may have learned as a developer. Drupal does things its own way, and the sooner you learn that, the sooner you will be closer to productive with it. If you take this path, developers, get to know the hook system and the theming system.
- Customising Themes (Drupal’s presentation layer) can feel unreasonably complex to the front end web developer or web designer that is used to a more transparent and simple system. Combine core themes with the good contributed modules like Panels and Views and it gets really messy for front end developers who are used to clean and semantic code. Lots of divs. I have often come across developers’ work on a project that has in frustration hacked around Drupal’s logic to get the desired result in the time available. One has to ask, why use Drupal if all you’re doing is spending more time getting around the way it does stuff?
- Customising contributed Modules is difficult as there is often no way to extend functionality the way you can with a more object-oriented architecture. This can be a real frustration when you just want to alter a module slightly for your own purposes, and not break maintainability from the contributing 3rd party for security releases an updates.
- Drupal can be difficult for developers to maintain, migrate or deploy as much of the functionality is often a combination of untraceable checkbox configurations in the admin interface of the website. As I understand it, this is core to Drupal’s goals – to allow people to make websites without having to touch code – but the result is it can to great lengths to ‘protect’ the user from code, making it difficult to manage interfaces where a quick line of code qould do it. It’s hard for developers to work like this, as it feels like your hands are tied. The lack of traceability of work and code mentioned above can be mitigated using CTools Exportables – which some modules support. There are also contributed modules like Features that assist in deployment. It’s all a different way of thinking when you are used to deploying from a branch of your repos. I find using a development instance of Drupal and using these tools to export to a build instance is the best solution for this.
- Generally, someone with technical capacity is required to manage and set up the more complex aspects of a Drupal application (Views, CCK, Panels, Nodequeue, etc are all good Modules, but are difficult for the average admin/editorial user to grasp). Often this job will fall to a web developer and in my experience this can result in frustrated and unhappy developers who would prefer to be coding than ticking a combination of checkboxes.
- Drupal (like any system) requires maintenance. There are security updates for core and contributed modules released regularly. Applying these to your live site can be risky and time consuming.
Obviously the more you know your tools, the better you can use them. If you are a proficient developer and you have some bespoke requirements, or prefer to be hands-on with code – write your own code, follow good practices and document it well. If your site fits into the 90% generic category, use Drupal (or similar) and extend it where necessary. If you want a bespoke Drupal site, you can get to know how its code works (it is open and extendible after all), but be prepared for learning a whole new dialect of PHP.
If you are not a developer, and have access to technical resources make the decision in collaboration with those resources. You will want them to be happy creating your product. A happy developer is more likely to be productive.
If you have few technical resources, recognise the limitations of what you are going to be able to do and use Drupal or similar.”
To see this answer, visit: http://qr.ae/cK53
