Re: Why we stopped using Drupal for our platform
codedrop.com.au
codedrop.com.au
The way Drupal is constructed is a work of genius. You need to understand that Drupal was invented in a university dorm before design patterns were popular and Dries did an excellent job at creating a content framework in PHP in the days that PHP wasn't even much a language (one can argue further I guess).
However, having said that. Because everything in Drupal is so abstracted, to do even the simplest thing, such as adding or modifying a form, as a developer you need to be across such a large extent of sub-systems and naming conventions that the learning curve on Drupal is simply way to high and totally unnecessary.
I say this because you shouldn't use Drupal for anything than building websites and if you're building websites then why not do yourself a favor and use Wordpress instead...
If you want to capitalize on Drupal, your project needs to be well inside that problem set and you should have a tier of users that can and will learn arcane rituals and minutiae such as which of the five modules for X doesn't suck -- people who are going to be more productive doing so than if you were to have them writing code. These shouldn't be developers, these should be that class of person that is content to spend months complicating together a single spreadsheet, it's that same kind of work.
I've been doing Drupal full time for several years and I often say that if you're working on a Drupal project and you're in a code editor, you're probably doing something wrong. Most of the time, either there's a module for whatever you're doing, or you shouldn't have used Drupal.
Drupal agencies seem to sell Drupal as if it were bespoke development: hourly rates, design from scratch and lofty goals -- until it gets handed to a site builder "developer" who weeps because module X doesn't have support for module Y yet and fixing that properly exceeds the budget and their own skill set.
The Drupal service industry has to realize that Drupal and contrib is an IKEA and they should seek to serve clients as interior decorators do, not as carpenters - although I suspect it won't be quite as lucrative for them under that model, as well as many egos in the way.
Actual developers do exist in the ecosystem, but their time is best spent increasing the breadth and quality of the catalog of solutions for site builders, not cleaning up messes and creating endless one-off cludges on an over-promised project.
I've not yet had my conviction broken that there is a market for CMS, but whether Drupal is a suitable implementation of CMS, whether agencies can sell CMS properly, and whether I want to do this anymore are big questions for me right now.
I also remember using Hippo CMS on a project that wasn't well suited to it. That was the double whammie of enterprise Java and all its warts (complicated maven build system, XML coming out of my ears) AND the 'square peg, round hole' problem whereby the sold solution isn't actually remotely possible with the technology chosen out of the box.
It was around that time I quit that job.
Building custom products you want to make sure your developers are happy and the platform is flexible and fast to iterate on, Drupal is not the best choice. It has the same programmer dread that Sharepoint has.
Most sites I end up seeing on Drupal have upwards to 100-200 db calls per page before optimization and caching but even then still heavy. It is at EOL.
Yes you can build solid and tightly run Drupal ship as you can with any tech really, but why if you are starting a new system these days? There are much better solutions in every area. It is monolithic systems like Drupal, Sharepoint, etc that continue to push people to microframeworks.
Ultimate zing. That's my experience too.
There are so many great options that I can't for the life of me think why you'd pick Drupal. Maybe you had to choose between Drupal and Joomla?
> "It is at EOL."
Exactly this.
The future looks promising: http://symfony.com/blog/symfony2-meets-drupal-8 http://buytaert.net/the-future-is-a-restful-drupal
From a personal point of view, the "easy, efficient and also fun" aspects of it just stop being true since Drupal 7. There is IMHO some well intentioned over-engineering at work there, along with a fairly asphyxiating/monopolistic stance from a certain company.
Drupal is great to wipe out publishing platforms (online magazines for example), but can quickly become an expensive constraint as soon as you start ramping up on complexity or customization.
Good for small to medium (at best) fairly straightforward sites, not at all to build web apps. I'd be sceptic of anybody telling you otherwise.
On a broader note, I think the need for monolithic solutions like CMS is also shifting. Shameless plug of a post I wrote recently about it http://devo.ps/blog/2013/01/31/farewell-to-regular-web-devel....
I just came here to say the same thing. However, I dont think Drupal is right for most small projects either.
I think Drupal's ideal use case is when you have a small community site where you will have many people creating and curating content.
Anything smaller, and you can probably get away with Jekyll or some other static site generator. Anything bigger, and you need to look at building a custom app in django, rails or my current fav.. node.js.
There are use cases for Drupal, just probably not the kind of things we'd get involved with. I think the overall state of the ecosystem and community is more of an issue for me than the technical considerations.
- No license fee
- Ton of modules = most common functionality is quick (cheap) to add
- Powerful point-and-click interface lets non-coders manage significant functionality
- A good security record and a large, security-conscious community
- Easy to find hosting = low hosting costs
- Plenty of shops know Drupal = keeps vendors honest
- You can pay a flat fee for enterprise support (Acquia)
In contrast, custom coded solutions have unknown security futures, unknown support futures, and you're dependent on the team who wrote it originally (few companies are willing to try to understand and support someone else's custom code).
I will say that it is very easy to develop apps with bad performance (doing 500 queries on a page load) and are not very scalable. It takes a lot of dedication and attention to detail to ensure your app/website is running at it's full potential. At it's core though, Drupal is just a beefy PHP framework, with a very robust hook system and APIs for doing a lot of things. It's node/entity system are very helpful when used properly, and is one of the reasons it remains popular.
Obviously, it's popularity is completely driven by the extensive theme/module development community that helps support the CMS. Without them, Drupal really would not be worth using.
I've used symfony1 since the beginning of 2008, then symfony2 from ~2011.
I've found drupal 7 to be good for client websites, custom module development is a major PITA to do anything interesting with, the core drupal 7 is a major clusterfuck...
You need to treat Drupal 7 as a CMF and learn where to hook in from over something `traditional` like RoR or django or symfony2 or any other framework.
I often hear that the learning curve for Drupal is high (and it certainly seemed that way to me five years ago when there weren't as many resources), but I can explain the major concepts and architecture of Drupal 7 to almost anyone willing to learn in about 10 minutes.
The biggest problem that I've encountered when working on Drupal sites is actually just bad/lazy developers. These people aren't really "Drupal Developers". They came from Joomla or .Net and jumped into Drupal projects without ever considering that they should find out what makes Drupal different. They won't be contributing anything back to the community, and it's unlikely that they'll develop anything that's reusable from one project to another. There is an abundance of information out there right now (even just on Drupal.org) for someone who wants to learn how to work with Drupal properly, but it seems like a lot of people would rather just complain that it doesn't behave exactly like whatever else it is that they're used to than actually try to learn about it.
For the record, a good place to start would be the Drupal documentation[1]. Drupal Answers[2] is pretty good, too. If you ever want to learn about a specific contributed module, try searching Youtube.
The code to create a node is simple. The code to create a node with a term reference, two field collections, and images copied from the filesystem is considerably more complicated, poorly documented, and prone to throwing weird errors.
If you're writing a module when you don't understand how modules work, you're gonna have a bad time. The Examples for Developers[1] module probably would have helped out. The Field example creates a custom field. The Node example create a custom node type. Or you could have just created the node type using the Field UI (and if you need it in code, export the configuration using Features[2]).