Why we stopped using Drupal for our platform

Yeah, the only really good situation where you'd want a CMS rather than building something yourself is if the technology is not the product.

Yes, it is confusing to talk about how blogs get paginated, in general. But if you're curious about WordPress internals: "page" is for archives, like the second page of blog posts categorized as news. "paged" is used when a single post (and page, or any other single item of content) is paginated. You know, like reading multiple pages of a news article.

I've been developing PHP for many years, and the best frameworks are always the lightweight ones.

Good Drupal developers, who actually understand the framework, are rare. If you can hire one, finding a second one of the same level is like winning a lottery. When I worked on a fairly large Drupal website our Drupal devs would disagree on how to develop some pretty straightforward things. It's a huge clusterfuck of a framework.

I have been developing web systems since 2000, I believe I have made at least $150k out of developing Drupal websites, most my clients are small to mid-size companies who only use a few pages and have a few hundred visits/day.

hence, I think it is a pretty good system.

It's not, and Symfony2, along with Laravel (which also uses Symfony2 components), is probably the only reason I would consider new PHP development these days.

Maybe it was phrased that way because Symfony 1.x is dying, since Symfony 2.x is not backwards compatible.

I don't think symfony is dying, however, bridging the two systems might produce a mess. but we better wait and see.

Symfony2 is excellent and is growing in terms of usage, conferences, and so on. The framework actually borrows best practices from Django, Ruby, and Java. The false description of Symfony2 as "dying" makes me wonder how much the original author actually understands the landscape.

In my experience the work involved in porting your site to the next version is equivalent to the work involved in just rebuilding from scratch.

And this is something you have to do every 2 years if you want to be able to use any of the latest developments in web technology. It's the big dirty secret of working with a monolithic stack imo.

Trouble with hiring "drupal developers" is that they are more then likely NOT developers. They are people with no engineering training who learned how to configure drupal sites and plug some hacked solutions into less then optimal places in the code.

People with proper development pedigree tend to sneer at the Drupal platform, and with good reason. This makes hiring incredibly difficult.

Took the "dying" part back. Apologies!

I can speak from some experience here, as a few years ago I led a team in moving a client's custom-built application off of Drupal.

You could probably set up a blog and a storefront easily within a day, and then hand that off to a non-technical client with a very limited budget. Outside of that use case, you're better off using something else, for several reasons:

Configuration is entirely stored in the database, which means setting up multiple environments for testing changes is effectively impossible. You also have no real way to use source control to track changes in your configuration.

The Drupal database schema is surprisingly hard to extract data out of, which means transitioning to another CMS, or to a custom-written app, is also very difficult.

Bugs are nasty, many, and often undocumented. In our case, we got bitten by a nasty bug regarding null fields when exporting XML -- it simply kept the last non-null value. Which was pretty problematic when that altered the nature of purchased items for thousands of customers (that was fun to fix). This also makes transitioning data very difficult.

Drupal module behavior is highly non-deterministic; you can add hooks in to, say, modify SQL queries before they get to the database, with no logging or other indication that this is happening. Debugging interactions between modules is very unpleasant.

There is no backwards compatibility between releases, which makes upgrading incredibly painful, especially if you depend on custom modules.

> I dont think there exists a good replacement of Drupal today

How about WordPress + plugins + some custom code in a little plugin? (much less work than for Drupal and you can implement what you want by ignoring 90% of WP's functionality and "ugly" code base - that is not poetry, btw, for those who get the joke :) ) You can even use a lightweight MVC framework of your choice inside your plugin if you figure out how to stitch things together and avoid some undocumented pitfalls...

True, that. There is actually a number of things I left out for the purposes of brevity, but thanks for pointing it out.

These stupid generalizations about PHP devs have to end some day, right? Symfony2 (as example) is a piece of software that is probably light years away from anything you have done in software engineering. And its community is way better both in knowledge and openness than the Rails one (I've been a Rails dev too, and have my own rants to make, but I don't go around saying Ruby devs are all noobs) IMO. Yet here you are, making generalizations based on having written code in plain php, working in a piece of software that I don't even know when it was created, but I guess it was here before we even started programming.

And for the sweet downvotes, I'll just drop this here:

Tell me more about how you read the GoF book, and applied the patterns in a language that does not even have interfaces or type-hinting. What a joke. On a recent article, another "Ruby expert" (who writes and sells programming books) was shocked by the fact that you can reuse code with inheritance. You should read it.

I'd completely agree. I find that only very tiny slivers of my ideas and thoughts are actually original. Because of this, I find a very worthwhile step of every project is researching existing solutions. This is also hardly an original thought, but it's one that's often ignored.

Drupal is the logical extension of the whole CMS movement of the late 90s that was predicated on the idea that web functionality could be commoditized. At the time it made sense because developing web software was new and no one knew how to do it very well.

These days it's easy to look at Drupal and just write it off as antiquated and horribly clumsy compared to the Railses and Nodes of the world, but Drupal is still going strong because custom software is not the be-all-end-all of web development. Drupal serves a huge market of people who simply could not afford an A-grade site built from scratch with one of the many low-level frameworks out there.

Drupal's high-level abstraction is, as you point out, incredibly restricting, but at the same time it enables you to check off a huge list of functionality from a project without writing a single line of code. As far as the architecture is concerned, it's actually pretty brilliant for what it is. The power to weight ratio is certainly an order of magnitude higher than Wordpress or any other CMS that I'm familiar with.

If you take the time to really learn the internals and how all the hooks interact, I think you can be quite a bit more productive than any Rails developer, albeit with considerable more restriction into the shape of the final product (again, client type and project requirements matter here). You probably can command an obscene salary as well given the number of Drupal sites out there and the difficulty of maintenance. Personally, I hate Drupal and consider it an evolutionary dead-end, but I have respect for its architecture and the type of work it enables.

I've had a similar experience.

For me, the most important realization was this: the moment I reached the point where I could set up really complex sites with very little code, using carefully chosen and powerful/flexible modules, the moment I figured out how to make the whole database-as-configuration issue as painless as possible, and the moment I started automating things (drush, etc), was also the moment that I had become a developer competent enough to do all this better, cleaner and faster with frameworks that don't require me to click around and configure stuff.

Drupal is deceptive, in a way, by allowing you to go quite far without writing code or understanding underlying structure. But at a certain point, the costs outweigh the benefits.

I think a example is the Views module. If you're good enough to understand the complexity of building a view, you probably have the mindset of a programmer, and/or the capability to use some kinds of code-based queries.

Perhaps the best audience for Drupal as a tool consists of people that are frustrated by Wordpress' limitations (or that of other full-blown CMS solutions), but aren't quite ready or interested in using frameworks as a starting point.

Drupal is good if you (or your client) can be satisfied with something that gets you 80% of the way there. If you need that last 20% then it is possible to make it work but isn't going to be time/cost effective.

There's also a kind of sweet spot around multi author publishing where Drupal does better than Wordpress (at this point in time). If anyone tries to sell you Drupal as a solution for web application development, run away as fast as you can.

Source: several years of Drupal dev for enterprise and large brand clients.

> I have this vision of someone in the PHP community at some point randomly picking up the Gang of Four book and being like "holy shit, check this out people...they had a solution to some similar problems 20 years ago..."

It's more subtle than that, but there's indeed a great lesson to be learned: the architecture of an open source project affects and reflects both its code and politics. Many years ago, the following article was written and spread through the community: http://drupal.org/node/547518

Though it has since been updated, the original premise remains intact: "You can point to chunks of Drupal's code and identify pieces which act similar to OO-patterns. Therefor, Drupal is OO-like and there is no problem." New Drupal developers have been reading this for years, and drank the kool-aid, including myself many years ago, before I left.

But of course, OO isn't just about what the code does, but how the code can be re-used and re-factored, and this is where Drupal falls flat. It's always been architected as a waterfall of pieces that call each other directly. This was rationalized away with the trope that Drupal had a "solid, well-written core", meaning nobody should ever need or want to touch it. But what it really meant was that there was no room for innovation in essential parts of it.

Drupal has always exploited the low bar in PHP land to position itself as more than it is. It is not better than WordPress, it is merely bigger and more meticulously annotated. This is the result of a review process that encourages people to participate, while only giving them superficial checklists to verify, rather than good software and product design practices. Creating and maintaining Drupal has become such a bureaucracy, that even ideas that should be dead on arrival can be ferried along, slowly being turned from "unacceptable" into "good enough to steamroll over the remaining objections". This creates a desire from many to see it go through regardless, to not have all that accumulated effort go to waste. As a result, big decisions come down to taste and politics, not technical merit derived from a consistent vision of what the end result should be.

I can't count the number of times a committed core patch left behind an exasperated contributor, who'd lost all appetite to continue to work on it, even before their work had the official seal of approval. Code is abandoned as soon as it becomes relevant.

Buytaert has always been aware of the limitations of Drupal's flat extension mechanism, always hesitant to add to it, but never seemed to want to modularize the module system itself to fix that. Of course, when the language you're developing in has the exact same problem, it is easy to rationalize this away as "not a big deal", even as the frog is slowly cooked to death one degree at a time. The frog is now dead, but rather than admit it, it lies open on the operating table, hooked up to a Frankenstein-like mechanism that makes its limbs twitch in a convincing fashion.

Every year, his keynote would list a set of goals. Usually the same ones kept getting repeated, on account of them not being accomplished in a way that actually solved problems for end-users. A perfect illustration is WYSIWYG editing. For years, the only thing people could agree on was wanting to swap out the WYSIWYG editor component. Which may sound admirable. But WYSIWYG is not about dropping in a JS library to add formatting buttons to your textareas, in fact, that's the least important part. It's about creating a workflow for users where you can always edit content in the same place you're reading it, and to make that happen seamlessly and elegantly, regardless of whether it's text or media.

Such goals cannot be accomplished in the Drupal community, even though several private companies have done it with Drupal over the years. Ironically, Drupal has a bottom-up process that results in a top-down architecture, which realizes a vision in the middle nobody actually needs directly. The WYSIWYG example is a perfect illustration: even as people say they're trying to reinvent the way editing in Drupal works, they're not willing or able to gut all the old stuff that keeps it clunky.

While Drupal contributors maintain things are getting better, the same processes are still in place, and more importantly, the same attitudes. Here's a recent quote by Chx, prolific Drupal contributor, loved by many:

"Drupal always did things better. Always. [...] That's a fact and a hard fact. [...] I hope we can get back on track for D9, finally." http://www.garfieldtech.com/blog/off-the-island-2013#comment...

Based on the current pace of development, Drupal 9 will arrive somewhere in 2015, maybe later. They've been supposedly turning this ship around for 2 years now, which shows you the real problem: these core contributors aren't in it for the end-result, they're in it for the process. There are social, political and financial benefits to be gained from putting yourself in a position where everyone relies on you, especially if you value approval from others.

The community that declared loudly that it wanted to make the middle men of the web obsolete, has created the perfect product for middle men to exploit for their benefit.

Every open source project is a social and political experiment. People should pay more attention to that fact.

Strange. Symfony2 should definitely be faster than Drupal. Were you running a lot of SQL statements between requests?

In terms of recommending a framework, it really depends on what feature set you want. Do you need a very minimal set of features, or do you want it to be very featured?

Django is great for building CMS. If you have the option, try it out.

are these 1100 lines of code executed everytime you render a link field ?

If you take a look at the code, most of that's dealing with the backend UI, comments, and stuff broken into multiple lines for readability.

Bashing based on LOC is as moronic as the old practice of LOC as a performance metric.

Hi, This a great example of a broader issue.

The statement "I switched to Wordpress when I realized that Drupal's Link Field Module (a plugin to add a hyperlink field to an entity) was 1100 lines of code." contains no logical context.

Most Drupal developers are not programmers. For example, a Drupal developer may be graphic's designer.

Drupal allows end users to define ad-hock data types. That's what "Drupal's Link Field Module" is (a part of). Ad-hock data types are an option, not a requirement.

If an end user wants to define an ad-hock data type with a "link", they install and configure "field modules". That's a limitation of being an "end user" (as opposed to being an application programmer).

A application programmer would look at Drupal's source code and see there is succinct API method to create a link.

So the broader issue is, you have folks with little to no programming experience making application programming decisions :) It's just as likely, the poster's project did not require ad-hock data types. Without any type of requirements analysis, the project fails.

Drupal's popularity (at least among CMS's) is due to it's set of logical features. It's not the technical implementation of the features :)

The downfall of most Drupal projects is due to poor resource choices. You hire a graphic's designer to implement an inventory system, you are going to get the same results no matter what CMS, frame work, programming language etc :)

Sorry, didn't mean to pick on anyone. Without an elaboration, you speculate based on you experience :) That's my experience with Drupal development :) Lots of talented folks asked to do the wrong job :)

That's weird. Themed on FF on Ubuntu. I will look into it and try to fix it. Thanks!