Actually, it's about using the wrong tool for the wrong purpose. I tried building a custom CMS with both Drupal AND Wordpress, just like the author and I realized how horrible it is build something custom out of an existing CMS.
I wanted to build a Metro-like interface for a shopping cart application with some extra functionality, just using Wordpress. Should be easy and was easy, until I discovered some horrible stuff within the code. You would think that Wordpress being so popular, would be top-notch as a development platform too. It was for the most part, but there were some trivial issues that made me develop a sense of hatred for developing for it.
No, I'm not talking about themes, I'm talking about building off something different using Wordpress as a base platform.
For example, on Wordpress, for pagination on posts, the GET variable is 'page' and for pages it is 'paged'. There is absolutely zero documentation on this and no reason as to why they have different (inconsistency) names for the same functionality. This is just one example. There were lots of other annoying bugs that pushed me too far. For example, sometimes, updating Wordpress would break a lot of plugins and leave you stranded.
Does this mean Wordpress is bad? No certainly not. It's the best blogging platform out there. But, if you want something custom, just build it yourself.
That's why I said 'fuck it' and moved on with rails. I get what I want, nothing more, nothing less. If I want an authentication system, there's Devise, if I want something else, there's always a gem for that, let alone writing my own code for the functionality I want isn't a big deal either.
In short, if you are building your start-up based off on an existing CMS, you're doing it wrong. Unless you are focused only on developing themes and frameworks for these platforms, or if you just want to run a Media company like Techcrunch or Mashable, just don't go with it.
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.
Using Drupal as an app platform is a definitely trying to solve the problem with the wrong tool.
My experience with this kind of thing is that these tools are flexible enough that people can stretch them beyond their intended purposes, but it's usually rougher than just finding the appropriate tool.
Specifically designed blogging engines become general purpose CMSes when people stretch and tweak them enough, and likewise people stretch CMSes into crude app frameworks, but you generally wind up fighting the tool about as much as building with it.
I have been developing PHP applications commercially since the start of 2008, using Symfony1 then Symfony2.
My current job is using Drupal 7 for the past year or so, and I have found it to be the biggest clusterfuck I have ever dealt with. Very steep learning curve, horrible admin interface (currently designing a new one for our clients), horrible bootstrap time.
There are a few saving graces for Drupal 7 such as Drush that make developing a bit easier... but I see Drupal 7 as a CMF as a horrible decision for almost any webapp/intranet app/anything.
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.
This is an honest question: if it's mostly a bunch of pages, wouldn't setting up a baseline Ruby on Rails (or similar) site, or using a Ruby on Rails CMS (Locomotive, etc.) be more cost-effective and faster? At worst, you spend a day setting up the basic system that you can then just copy for every new project.
I've long used Drupal, building sites ranging from full-blown content providers to the kinds of sites you speak of, but I still find that setting things up, even when 'copying', and clicking around the interface, and so on, take more time than just copying a base rails app and changing some lines of config and code, or branching an existing project at a point where it has most/all the features I need.
I might still use Drupal, and I've invested considerable amount of time in understanding it, so I'd really like to know the best reasons why I still would.
No its not.
my last website had the following features:
multiple content types, backed by private/public file system hosted on s3, UI to configure fields and directories
(got all that setup within a few minutes)
out of the box SE-Friendly urls with a UI to bulk manage the content
(few minutes to install and configure pathauto)
Rich text editing using ck4, with a great UI to configure and excellent HTML purifier library to filter text.
(few minutes to configure and install wysiwyg, ckeditor, and htmlpurifier)
Excellent account management / user profiles / roles/premissions out of the box
Excellent Categorization system, out of the box, with configurable widgets on the front/backend
revision control out of the box
comments out of the box, add spam protection/flood control in minutes
Custom views with configurable pagers and designs
Cool image management out of the box
Caching with memcache, apc, and boost , takes less than 2 min to enable
unlike wordpress Drupal is very portable, I personally add the db dump to the files and push them to the server then import the db as needed. everything just works perfectly, move your website to a subdir, or change the hostname, it will still work no need to do anything.
I can go on and on describing many of the excellent modules that you can get using just drush dl <module>, but I think I'd better write a full blog post about it instead. Hopefully will do that in a couple of days.
Thing is that most clients want PHP because it runs on everything. They can take their entire site, package up the code + database and move it pretty much anywhere.
good point. I do run into this issue at times, just haven't had a need to start from scratch with clients in a year. I either support existing wordpress/drupal installs, or work with existing rails apps.
We host client websites, however sometimes a client may want to take their website and go elsewhere, so it's easier for them to not worry about where their site can run as pretty much any admin can get PHP working.
Sure I would love to expand work into other languages, but for the short term it's PHP (symfony2/drupal) for us. :-(
Well, Drupal is great for one thing - job security! It's so convoluted and complex, that good programmers who know it well are a rarity and can charge a good premium. But hey, the white house site uses it, so it must be good, right? Right?
Drupal 7 is my favourite PHP CMS to build small client websites with. It's fast and the content types are easy to fit to their requirements. Anything bigger than that makes me cry inside.
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.
As a "good drupal developer" (I hope!) I can back this statement up big time. My company has 2 developers who know Drupal fairly well but we need to scale up to 4-6 developers at our skill level.
They simply do not exist.
We get loads of useless "site builders" applying or your prototypical PHP Developer (seperation of layers? why?). Very, very hard to find competent people who are willing to work with Drupal.
If you're just starting out and are shopping for a development platform, stay away from Drupal. You'll take more time to develop your MVP, but in the long run you'll save a huge amount of time and money.
For me, drupal is still saving lots of time in development. If you (or your client) thinks he knows EXACTLY what he wants, than do it from scratch and expect to invest much more time (money).
But I have come across enough clients that were pragmatic, and were able to understand that changing built-in feature X to make it a little different is not that crucial. They were able to live with the limitations imposed by built-in systems because they knew it saves a lot of money, and ultimately - these things are not the things that determine if a project succeeds or fails!
In the real world of limited time and money, drupal is indispensable.
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.
It takes advantage of PHP 5.3 (anonymous callback functions, namespacing, etc) whereas a lot of the other PHP frameworks feel like PHP 4+.
You can swap in components like Redis easily. Setting it to use mock versions of web-based APIs in the development environment. And the code just feels nice to work with.
Yes, that's sort of the point. It looks like the MVC frameworks you'll see in Python and Ruby, with allowances for and enhancements where they make sense with PHP as a language.
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.
One of the biggest problems in building something on top of Drupal is the 2 year cycle of major releases with no backward compatibility. That means you will need to port all your custom code every 2 years. Combine that with the fact that many crucial modules are actually not part of the core distribution and are often not ported for months/years. Some less popular ones are even abandoned with new alternatives coming up. We went through that process of upgrading from D5 to D6 but simply gave up at the D6 - D7 transition.
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.
In cases where I've seen sites switch from Drupal to a custom-built ruby solution, the end result had less features (or were missing crucial features and user interface details that are trivial to enable in drupal), and they had more problems and bugs (and I would guess, have more security issues). Also, some of the reasons I saw posted for switching are not true, at least not anymore. For example, there are tools that allow for version control and collaborative development on drupal sites now.
examples: p2pu, mozilla drumbeat, cloudworks http://cloudworks.ac.uk/ which were all originally drupal sites
On cloudworks, it forgets that I'm logged in everytime now. And it can't link together and display connected posts and people as easily as you can in Drupal, it can't email you updates and activity you've subscribed to, the site isn't mobile friendly (and think how easy it is to convert a site to be mobile friendly now in drupal & wordpress), the links are ugly and not seo or user friendly, etc. The site went down several times last month.
There are lots of Drupal developers around. Why not hire one instead of training people from scratch? If your job involves something new like Drupal then you get on and learn it, there are plenty of resources around. Perhaps novice Drupal developers are the problem.
Note, I do not like working with Drupal but I have seen some really impressive things done with it.
The author says Symfony is dying. The opposite is true. Symphony2 and it's components are becoming more popular and are being used in other frameworks like Laravel. If you are following php into 5.4 at the very least you will know about symfony. You will probably be using some components of it.
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.
Yes Drupal is not for creating custom apps, but it is not really that bad, for specific systems (ex: where you have anonymous traffic) or publishing systems, Drupal really excels. the huge amount of queries (200+) executed on each request can be easily cached and scaled using a bunch of layers (APC,static files, varnish) and it scales very well.
on the other hand, if you try to build the CMS features you get (out of the box) in other framework like Django or rails, it will take you really a longer period of time.
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.
yup, this is a real problem with small community sites that drupal is other wiser awesome for. the work involved can be rather arduous (and impossible if you are using a module that lacks an upgrade path).
that said, the drupal community is huge and in my 8+ years of building and running sites i have always been able to work out an upgrade solution, finding the time to implement it is the bigger problem.
Last I used it, there was still too much that the Features module didn't 'cover', making it less useful and sometimes even counter-productive for me. Has this improved greatly in the past year?
Configuration management can be a real issue. For Drupal 8 there is the Configuration Management Initiative meant to solve just this problem. It will be there in Drupal 8.
Features has some very rough edges. It's a bolt on after the fact solution. Through it Drupal developers learned about the rough edges, what people want here, and so forth. What comes in Drupal 8 is meant to be a proper solution at the core from experience.
Having just migrated a big Drupal 6 site I attest that the Drupal db schema is really quite complex.
Also one of the project advisers has also said that going between different versions of Drupal is comparitable with going to a totally new Cms (meaning its no simple task).
Dupal's advantage (imho), or the advantage of being exposed to it is that everything, Rails, Django, Pylons etc. seems "easy" and like a breath of fresh air compared to it, even if you are learning another language, like Ruby or Python, at the same time with learning the framework! ...really, the only other piece of software that I've worked with and has this extraordinary "quality" was Magento (I know, they are at different extremes of "nightmare", and I hope I'm not offending anyone with the comparison)!
As a Drupal dev of several years, my team recently started working on a rebuild of our sites (magazines/blogs) in a custom node.js framework.
I appreciate certain notions embedded in Drupal, still: abstracting away technical requirements, flexible data models (content types), huge number of pre-existing modules that cover a tremendous range of cases. Still I found the modules mostly served as guides to create our own custom solutions, and less as plug-in-play options. I was really able to build some good functionality, abstract enough for the core elements to be shared between 6 websites, with superficial theme-level changes for each.
That said, anything awesomely written performed so abysmally that the great work really felt like it was a waste in the end. In that sense, Drupal strikes me as a true dead-end. The basic heart of the app, and elements of the philosophy make a beast that is bad for anybody with skill who wants to feel good about what they've done. Other criticisms would be the excessive integration of administrative-type functionality with end-user functionality; an almost incomprehensible (Fields) system for building custom data extensions; and the big one for so many here, the tight-coupling of the database with the code everywhere, which is part of what makes it so slow and a nightmare to develop with.
As to job security; I suppose I have that, and I often get offers to work on Drupal projects beside my main employment, but I find the work so lacking in joy that I need to charge punitive hourly rates.
For a certain type of project I'd definitely choose Drupal over Wordpress. Still, I wish there was some middle-ground. A more performant CMS, ready-to-go for small-to-medium size vanity or content projects, that doesn't make the insane compromises Drupal does to be "user-friendly" (read: code-averse).
Wordpress front end provides the CMS and Bling; proxy custom requests (crud, shopcart, etc.) to framework of your choice on the back end -- powerful combo.
A friend of mine has made a killing on Drupal development over the years. When asked to help out on a couple of projects digging into underlying code to solve some square peg/round hole problems that he could not manage at the GUI level -- after one small project, I declined further requests; it was truly painful.
PHP itself is of course a nightmare language (spent 6 years slogging through that mud) compared to Ruby, Python, Scala, etc., and Drupal's function-based hook system brings no joy, more drudgery really.
Saying that, it seems that in addition to drush> there's an implicit drudge> that takes affect when working under the hood in Drupal...
I saw this over-engineering coming in the transition from Drupal 6 to Drupal 7, and as such I held my company on Drupal 6. Drupal 6 is a significantly slimmed down environment, which can be used like a scaffold to build custom apps. There is not a hell of a lot there, so the complexity is minimized. But it's still not testable, and still pretty opaque for debugging purposes. I'm moving off Drupal, to the "Doh" framework that hosts other frameworks, and you define the interface you want to the "other" frameworks, forcing the logic pattern you want to use upon frameworks that may not support it.
I guess, every CMS has same problem.
Either you build from scratch or use one of the CMS. For quickly setting up a web site Drupal/Wordpress is good option.
There are plenty of cases, you would not want to write from scratch. For example, I am running my website on Drupal(http://www.avabodh.com) without writing any code. I do not have time to write code for my website. My requirements are very simple. It will be waste of time if write CMS from scratch for my purpose.
I dont think there exists a good replacement of Drupal today.
> 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...
The author missed a critical reason to stay away from Drupal.
Testing.
It's basically impossible to do proper unit testing in Drupal. A unit test is a core requirement to doing test driven development and to do it properly that test needs to be run quickly and efficiently. There is no way to do that in Drupal as their testing framework requires a minimum of 1 minute per test.
As a developer working with drupal, I feel completely trapped by this atrocious platform. I worry that the longer I work with it, the more at risk my career becomes - not a pleasant feeling.
I was a Drupal developer for a year or so. That was at the end of my stint as a PHP developer, and presaged the end of my use of PHP as a language, and my introduction to the larger world of software engineering.
Thinking about it now, I'm really not sure what Drupal is good for. All in all it is a pain-in-the-ass to work with. Having switched to Rails after that (and please don't get me wrong, I'm not trying to insist that Rails is the be-all-end-all, but for the sake of comparison...), I know now that the same amount of development time in Rails can yield far greater results, despite the fact that you can essentially build functionality through a GUI in Drupal--a GUI which is as incomprehensible as the codebase is. This is something the author of this piece acknowledges when he talks about trying to customize Drupal.
This has to do with two things, I feel. One is that, fundamentally, Ruby is a more expressive language than PHP, and you can accomplish a lot more with less code. I say this not to start a language war but simply because I think it is true--the same way I feel that Lisp is more expressive than Ruby by a significant factor.
The second, and much more significant reason, is that Drupal doesn't have any sort of sane architecture to let you safely plug in modular code. You are essentially hot-loading code into arbitrary points within the system. Frankly, it suffers from the same problem a lot of PHP apps do (and more Ruby and Python apps than many of us would care to admit) which is that it's people re-inventing the wheel from the ground up, all over again, poorly. The fact that they are now talking to the Symfony guys about putting some of those ideas in place suggest to me that someone on the Drupal team finally realized MVC exists. 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..."
I'm joking a bit...but after years and years doing web development, I only finally realized the whole world of software engineering that was out there, and how out of the loop I truly was (and still am). Many developers exist in a little bubble consisting only of their language or worse, their platform. The Javascript folks, Rubyists and Pythonistas (fill in your favorite language/platform here I suppose) can all suffer from this.
Point being, any of us who consider ourselves "software engineers" should be constantly reviewing our own skill set, and while we should certainly be refining our skills in our particular language(s) and toolsets of choice, we should also be constantly reviewing other languages and ways of thinking about architecting software for guidance, inspiration, and to combat our own tendencies towards small-mindedness. We should be refining our knowledge of algorithms and comp sci fundamentals if we are lacking (as many web developers are, especially self-taught ones).
After all, "those who don't know history are destined to repeat it." This is just as true--if not moreso--in software engineering as it is in any other discipline or domain.
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.
> 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.
...same can be said for WordPress, that actually "evolved into" a CMS from a humble blogging platform. And when freelancing, I made the "mistake" of offering customers a "custom coded Django based solution" at the same price one would charge for a WordPress based solution (functionality via custom theme/plugin). Boy, it was confusing for customers! The ones that knew about technology and prices couldn't know what to make of it, and it ended up lowering their confidences in what I had to offer! I just didn't fit in with their mental models of technology and prices - especially when you add the fact that I charged per project or per feature and not by the hour (they couldn't imagine that using what they seemed as a more expensive technology with allow me to do the job in less time and with less effort).
I think we're approaching the point where a chinese/indian dev will end up stitching up a Rails/Django solution at the same WP-level < $40 / hour...
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.
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.
> 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:
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.
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.
>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.
<tongue in cheek>
If you're interested in examples of GoF patterns implemented in a language without typehints or interfaces, I highly suggest getting ... the GoF book -- it has examples in Smalltalk!
>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.
I don't see any joke. Jokes are of the type "Knock knock, who's there", etc. Using GoF patterns in a language without interfaces or type hinting? Not so much.
Most of the design patterns can be applied in any language, some languages even have inherent support for some of them. Not much to do with types or interfaces (besides them offering extra checks).
Facade, Decorator, Flyweight, Iterator, Proxy, etc... Equally at home in Java, C++, Smalltalk, Python or Ruby...
>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.
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.
Drupal has it purposes, however I wouldn't use it for anything custom. I have a friend that runs a small web site business (mom & pop shop). He makes most of the sites in drupal, his primary customers are very small businesses. In this case drupal is perfect for him, he can have a site up and running in an afternoon with an amazing amount of features. Of course, when he ever calls me to do any custom modification, I cring.
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.
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 :)
Although this might be a performance issue as well, I think the real problem is that some unlucky people had to write those 1100 lines of code in the first place.
size of code != performance problem in most cases, plus drupal give you an extremely lightweight api method "url() or l()" to render links, its up to you to choose .
I always end up going back to Drupal. Sure you need to be an astro physicist to be able to get Views and Panels to work with a jQuery version from this century but where else can you build a fully functional social network with Solr based indexing and tagging in two hours? Rails? I think not. It took the Diaspora guys a year to build something that could have been done in weeks in Drupal with pre existing modules that can be turned on and off with a checkbox.
I admit she is treacherous as the sea and I swear off her regularly, but she's still my go-too gal when I have a dumb idea for a multi user site that I want to get working before lunch.
Actually, it's about using the wrong tool for the wrong purpose. I tried building a custom CMS with both Drupal AND Wordpress, just like the author and I realized how horrible it is build something custom out of an existing CMS.
I wanted to build a Metro-like interface for a shopping cart application with some extra functionality, just using Wordpress. Should be easy and was easy, until I discovered some horrible stuff within the code. You would think that Wordpress being so popular, would be top-notch as a development platform too. It was for the most part, but there were some trivial issues that made me develop a sense of hatred for developing for it.
No, I'm not talking about themes, I'm talking about building off something different using Wordpress as a base platform.
For example, on Wordpress, for pagination on posts, the GET variable is 'page' and for pages it is 'paged'. There is absolutely zero documentation on this and no reason as to why they have different (inconsistency) names for the same functionality. This is just one example. There were lots of other annoying bugs that pushed me too far. For example, sometimes, updating Wordpress would break a lot of plugins and leave you stranded.
Does this mean Wordpress is bad? No certainly not. It's the best blogging platform out there. But, if you want something custom, just build it yourself.
That's why I said 'fuck it' and moved on with rails. I get what I want, nothing more, nothing less. If I want an authentication system, there's Devise, if I want something else, there's always a gem for that, let alone writing my own code for the functionality I want isn't a big deal either.
In short, if you are building your start-up based off on an existing CMS, you're doing it wrong. Unless you are focused only on developing themes and frameworks for these platforms, or if you just want to run a Media company like Techcrunch or Mashable, just don't go with it.