Half the code lives in the database, configuration is all mixed up with content, and there's no reliable programmatic way to extract it. It makes doing deployment a nightmare.
And the worst part? Drupal developers by and large have such a narrow range of experience that they don't even know what they are missing. They have no idea what good coding standards look like, a lot of them don't even have a development/production separation: they just hack away on the live site with no source control or backup. And no one writes tests, or sees why they would be useful.
Some of the big professional drupal shops appear to have basically written their own cms on top of drupal, with a bunch of terrible hacks to try to make source control kind of work, and just use the drupal name basically as a marketing technique.
So glad I don't have to deal with any of that insanity any more.
I work for a company that provides site implementation, custom feature coding and ongoing support for ~30 enterprise websites and all of them have this in common: 100% of the source code for each site is in revision control (SVN or Git, depending on client preferences).
If you want to complain about Drupal be my guest. The ground's very fertile, but what you've posted here is FUD.
Code in the database? No, just no. While it is technically possible to stuff code into the database community best practices (not to mention common sense) strongly advise against this practice. What you are describing is the system handing you enough rope to hang yourself, not it's default behavior.
Configuration lives in configuration tables.
Content lives in content tables.
"they just hack away on the live site with no source control or backup"
It would be a mistake to take the fumblings of a few scrub freelancers or interns and extrapolate that as being the norm for all (or even most) Drupal developers.
For all core modules and all quality* contrib modules there are $N_load() functions to extract these (reliably) from the database.
* With ~8000 contributed modules to choose from, quality varies wildly. While unfortunate, it's to be expected when you've got that many chefs in the kitchen.
This is quibbling over semantics. Drupal's custom content types, custom fields, and Views all allow developers to express complex logic that would, in any other development environment, be expressed as code and committed to version control -- creating a new content type in Drupal and adding fields to it is exactly analogous to creating a new model in Django. You can call it "configuration" if that makes it easier to justify its being in a table, but it doesn't change the fact that Drupal developers spend lots of time building shit that can't go in a VCS, can't be easily tested, can't be branched/merged, and can't be easily deployed without a convoluted export/import dance. Just because there isn't literal code in the database, it doesn't mean there's a clean logic/content separation.
"Drupal's custom content types, custom fields, and Views all allow developers to express complex logic that would, in any other development environment, be expressed as code and committed to version control"
And that, in a nutshell, describes why Drupal's adoption rate is as high as it is compared to development frameworks developers actually enjoy working with. No fucking code. Non-developers can actually get results with the system without having to resort to the kind of miserable hoop jumping we developers subject ourselves to in an attempt to make sure nobody else on the team fucks something up.
View got changed? Log in and change it back. Absolutely, positively MUST have an ongoing log of changes to your view/content type/custom field? All of these are exportable to code and can either be imported raw or live in modules.
I suspect you've worked with exportables at some point so I simply mention this for any spectators that aren't aware there are a number of strategies for getting your configuration into code (and thus revision control) if that's your thing.
Also, for the uninitiated, apendleton makes an excellent point about deploying config changes from dev/staging to production. It sucks, plain and simple.
Being able to export and commit isn't really good enough; keeping a work log is only a relatively small part of the capacity for version control systems to expedite development. Many projects have development workflows where new features are developed in branches, and only merged when they're ready to be deployed.
Suppose, in a Drupal project, you had two such features being developed simultaneously, and each added different new fields to a given content type, with corresponding changes to views and authorship workflows. Assuming it were even practical for each developer on a Drupal project to have their own development instance of the database powering a site (which it totally isn't), it's true that each developer could export their own version of the given content types, views, etc., and commit them to version control. The exported blobs are pretty much opaque to many Drupal developers (or non-developers, as you say), though, and may not be expressed sufficiently sanely that Git could figure out what changes actually took places. When these features were ready to be merged, would the merge work? Who knows? What if there were merge conflicts? Would developers be able to resolve them? Worse, what if Git's notion of the correct merge strategy didn't actually produce a semantically correct result? All of these operations take place on generated code that nobody wrote and nobody reads, which is scary enough that the whole process wouldn't be trustworthy.
Exportables are yet another in a long series of efforts in the Drupal community to attempt to address a deficit they have with respect to most other web stacks, and again they've done it in a way that doesn't really deliver the benefits of the feature as it exists elsewhere (see also Drupal's "database abstraction layer" or its supposed "object-oriented design").
"Being able to export and commit isn't really good enough; keeping a work log is only a relatively small part of the capacity for version control systems to expedite development. Many projects have development workflows where new features are developed in branches, and only merged when they're ready to be deployed."
Features, exportables, Strongarm (et al) are all compatible with the workflow you're describing. Our development workflow is heavily dependent upon branching. All new feature development takes place in branches that are later merged into dev, with stable "snapshots" taken from dev whenever we do a release. Pretty standard stuff, and we use features and installation profiles heavily in our implementation work.
"Suppose, in a Drupal project, you had two such features being developed simultaneously, and each added different new fields to a given content type, with corresponding changes to views and authorship workflows."
What you're describing isn't a credible workflow, it's a mess. Field declarations for a single content type strewn across multiple features? Why? Designing a content type and exporting it to code shouldn't take more than 30 minutes for even the most complex content types. If additional features are required they can be added to the feature but separation of concerns typically dictates that that code goes into a separate module. Cleaner that way.
"ssuming it were even practical for each developer on a Drupal project to have their own development instance of the database powering a site (which it totally isn't)"
All of our developers maintain local mirrors of the dev environments for all of the clients they work with. This includes snapshots of the dev database. Also, how is maintaining a local copy of a database either impractical or in any way a Drupal-specific problem? Any project that includes a datastore is going to have similar issues.
"The exported blobs are pretty much opaque to many Drupal developers (or non-developers, as you say), though, and may not be expressed sufficiently sanely that Git could figure out what changes actually took places. When these features were ready to be merged, would the merge work? Who knows? What if there were merge conflicts? Would developers be able to resolve them? Worse, what if Git's notion of the correct merge strategy didn't actually produce a semantically correct result?"
Merge conflicts happen with any workflow. Merge uncertainty is an issue with revision control, regardless of what platform you're developing in. As far as manual merges goes, I submit that any developer should be capable of manually merging simple array declarations (because that's all exportables are).
"All of these operations take place on generated code that nobody wrote and nobody reads, which is scary enough that the whole process wouldn't be trustworthy."
I think our definitions of both "code" and "trustworthy" differ greatly. Exportables aren't huge blocks of opaque logic. They're simple associative arrays. I have no problem trusting code that generates array declarations and has been tested by the core project devs, security team, module maintainers, and several thousand developers on tens of thousands of websites. Your mileage may vary.
"Exportables are yet another in a long series of efforts in the Drupal community to attempt to address a deficit they have with respect to most other web stacks, and again they've done it in a way that doesn't really deliver the benefits of the feature as it exists elsewhere"
100% accurate, you'll get no argument from me here.
"database abstraction layer"
My kneejerk reaction when this was first announced: DBTNG is a fucking travesty foisted onto the community by Acquia as part of a corporate play for the "enterprise" market. After a year of screwing around with it: It still a pain in the ass but with all of the bullshit going on with the MySQL project courtesy of Oracle, this might turn out to be very very useful.
"object-oriented design"
Who claimed Drupal was object oriented? Seriously, I'd like to know so I can spill my drink on them if I ever run into them at a DrupalCon afterparty.
"Field declarations for a single content type strewn across multiple features? Why?"
Sorry for the confusion; I meant lower-case "features," as in, new pieces of functionality that both affect the same kind of data, not "Features" in Drupal terms. I don't think it would be especially unusual for multiple feature branches to affect the same content type in different ways.
"Who claimed Drupal was object oriented? Seriously, I'd like to know so I can spill my drink on them if I ever run into them at a DrupalCon afterparty."
Admittedly I've been away from the Drupal community for awhile, but I attended a DrupalCon several years ago in which the argument was made in multiple talks that Drupal's design followed the object-oriented philosophy despite not taking advantage of PHP-native object-oriented mechanisms. This (old) article seems to espouse these sentiments roughly as I remember them: http://drupal.org/node/547518 and I remember finding them to be pretty ridiculous at the time. Perhaps community sentiments have changed since then.
Thanks for clarifying. At time of writing the only two data types that are routinely and consistently cast as objects in Drupal's codebase are users and nodes. The comical thing is neither have methods assigned and can just as easily be cast as associative arrays (like everything else).
Outside of core, contrib has gotten quite object oriented over the last few years as Views, Panels, Simpletest, Ctools (etc) are all heavily object-oriented and the popularity of these modules has driven a lot of other contrib module development that in turn is required to take an object-oriented approach to interact smoothly with these modules.
Still, attempting to claim Drupal is in any way object oriented is like hot gluing a handful of feathers to a basketball and calling it a chicken.
Yeah, those non-developer's you're talking about? Most of them have no idea how to change a view, because changing a view is pretty much just as complicated as coding a SQL query. If you understand how to modify a view, you probably can write an SQL query.
The benefits of having a UI to manage core application behavior is lost on most clients. Most are terribly scared of editing a view, content type, or pretty much any other module specific configuration. I speak from the experience of someone whose developed about a dozen or so Drupal sites.
Not all clients. Clients are different of course! Should something break it would be immediately obvious, and not all are prepared for that (obviously!).
It also depends on the structure of the site itself.
But some are comfortable changing a title, sending new arguments into panes and stuff like that. Again, depending on structure. As long as the job can be boiled down to a simple point and click routine, they get comfortable doing it. They're not too scared of filters either.
Some are also comfortable setting up new panel variants. It's an extremely powerful editorial tool, when setting up sections with teasers. ("breaking news" sections based on terms for instance.)
Not that I know much about Drupal, but isn't it inevitable that stuff that can be changed via the UI (sometimes even per user) has to live in the database? This is simply a consequence of blurring the lines between developers and users, which is exactly the point of CMSs.
Actually, I think what we should be asking is this: Do CMS databases and VCS really have to be two completely seperate universes? I would say no. There is room for a new type of CMS database design that includes all the functions of a VCS.
Drupal's Features module tends to use this pattern:
The code defines the default configuration.
If the user changes the config using the UI, the change gets written to the database. At the same time, a little telltale light (or something) tends to appear in the UI display, to alert the admin that something's been changed on the site, but not in the code.
Your developer can then come along and pull a report that lists any configuration that's been changed in the UI but not migrated to the code. Pressing a button spits out a code-based representation of that configuration. The developer finds the right file, pastes in the config change, checks into Git or SVN. Now the config is once again captured in code, and ready to be deployed in a consistent manner.
I'm not sure if the Drupal 8 team is using this pattern or something different. Still trying to catch up with this stuff.
this gives you a nice diff of the config in production v's code.
drush fd feature_name
sometimes i really need to make a fix in production (or its so trivial the overhead of a release would be just silly), make the change on production, then grab fresh db dump, stick it on dev box and run "drush up". today i did this to remove a link from a field in a view.
On a site that is version controlled and has a QA workflow for changes, you simply disable the UI for changing those things on production, and the only way to influence them is by committing the changes exported as code and deploying.
The UI is enabled on development environment, allowing for extremely quick experimentation (possibly by non-technical folk), but you still get (most) of the benefits of changes being in code.
ETA: It's not perfect, but it's on it's way to becoming the best of both worlds. Drupal 8 is making significant progress in that direction.
"Configuration lives in configuration tables" : the OP's point exactly. Configuration should live in a VCS
Bear in mind also that "configuration" van be so complex with Drupal it's often more along the lines of being "an application". A non-trivial view is hugely complicated and yet all its settings and code live in the database entirely, with no way to either back it up in a VCS or deploy it from a development environment to a live environment without manually copying the settings from one to the other.
Views, specifically, have been exportable into version-controlled code since Drupal 5, and the ability to do so is a prominent feature in Views v3 for Drupal 7. Indeed, the Feature module, which spearheaded the current effort to make every Drupal configuration setting expressible in version-controlled, script-deployable code, is based on a pattern invented by Views years ago.
Exporting views to code has been shaky at best. And worse: once it's exported to code, there is no way to only import the bits that have changed. You must recreate the whole thing anew.
That's not version control, that's an export function.
All of the configuration for my Drupal sites DOES live in a VCS (it just doesn't have to, and many people don't bother).
Drupal 8 is continuing to make this easier and more powerful, by (amongst other changes) making configuration live in the filesystem by default, turning the copy in the database into (one of several options for) a cache.
This is the main reason I chucked my Drupal 'cuffs in 2008, no longer taking on new Drupal projects and helping my clients move over to other Drupal service providers: It was very, very difficult to scale up my business because bringing on extra developers, and having consistent local/dev/staging/production environments was at least an order of magnitude more difficult that it would be with other tools.
In Drupal 6, the only way to reproduce an environment was with a massive install profile for the project, and the average Drupal developer was entirely clueless to matters of testing and version control when compared to the average Django/Rails/CakePHP developer. This made for many painful projects and unhappy clients, usually beginning 6-8 weeks into the project when the issues of database drift became inevitable.
And like you said, everything lives in the database. So the chances that some production issue (or new issue only seen in dev) was caused by an errant user action in the Drupal UI was pretty high, and this made debugging a nightmare -- where is my issue really coming from?
I'd just about forgotten about my Drupal days of yore, and between the "click monkey" analogy and the "clear the cache" nostalgia, the author sure conjured up some bad memories!
Also the testing part has been improving, and although very few of the contrib modules have tests most of core has automatic testing in place for when you submit a patch as you can see in the issue queues (http://drupal.org/node/466576).
Features is good as a concept, but in implementation it fails considerably. Here are a few issues:
- How to deprecate a feature (I created http://drupal.org/node/1400346 to attempt to solve this, but admitedly, it's a very dangerous module)
- Ever created a feature with tons of things in it? Hello, 5 minute load times for admin pages!
- How do you merge two features together? How do you commit just one feature and not another (say, one you're still working on?)
The CMI initiative will hopefully take care of a lot of the messiness and bugs in Features.
Right, features is not perfect. Upgrading a feature from D6 to D7 has been a pain to me.
I've merged features together and it was not as hard, at the end it is all code, you just need to be very careful, but at the same time you have git to revert if something goes wrong.
I don't understand the part about committing just one feature. You can commit just one =P.
Features is indeed the answer, and all of the potential issues are manageable.
I finished up a project earlier this year that has more than 300 modules active in a custom install profile, with 10MB of features modules stuck in there. We committed/contributed to a few fixes in core and Features to speed it up greatly. That's out in the wild on major sites and doing fine.
We didn't have any terrible admin screen issues, or indeed any terrible issues beyond occasional painful version control collisions.
The other downside of Features in Drupal is that if we export something as a Feature (say a View) and then our site builders tweak and change that View for our clients and then we update some core element of that View and re-export the Feature, that re-export will overwrite any custom changes that were made to that View, thereby trashing any of the custom changes. This is a real problem with Features to which I'm surprised there has not yet been a good solution.
Same problem as other frameworks. You need to know the rules. If you use rails, and the designer changes the CSS without committing the change to git, then next code push will erase his change.
I work on big Drupal sites and this simply is not true.
Drupal lets you get a ton of shit accomplished without making you understand a single line of code, have a reasonable Dev-Stage-Prod workflow, QA, even version control or backups, etc., but it's completely possible to do all of that. That means that it can scale from anywhere from something like a 16 year-old's shared-host fanfiction site to say Whitehouse.gov.
Of course that means that there will be tons of fuckups live-coding (or live-configuring) on production, or people that don't export and version things in environments when they should, and that people will construct fragile combinations of modules and configuration where a tiny bit of code would have sufficed, or write tons of fragile custom code with no tests or security review when there was already a module for that.
But allowing people to be fuckups doesn't force them to be, and they can be trained.
"That means that it can scale from anywhere from something like a 16 year-old's shared-host fanfiction site to say Whitehouse.gov."
Scaling to Whitehouse.gov is not impressive at all. Like a 16 year-old's shared-host fanfiction site whitehouse.gov really is nothing more than a content site, albeit a very large one.
The problem is Drupal isn't content to simply be a CMS. It has to pretend to be a framework for developing web apps as well, and for that it's just plain terrible.
If you compare it to a framework it loses, obviously. It's massive and complicated. And while PHP's is trying hard to modernize, the tools and ecosystem still don't compare to Ruby or Python (see below).
Drupal is only for when what it (or modules) can provide is a vast majority of the requirements of the project. Anything that couldn't be described as "nothing more than a content site" probably would not be a good fit.
The only thing it has to offer is when what you need is one of the myriad things it can be configured to be, because then you get a bunch of community eyes and tests on a bunch of code you didn't have to write.
Edit: Discussion on recent improvements to PHP's and its ecosystem (which are exciting progress in a direction I believe there is more room to go) http://news.ycombinator.com/item?id=4605715
> And while PHP's is trying hard (see the other story on the front page at the moment) to modernize, the tools and ecosystem still don't compare to Ruby or Python.
What do the current offering of PHP frameworks lack that Python/Rails provide?
I'm not going to claim up-to-date in-depth knowledge of the PHP ecosystem since my daily work ended in the 4/5 transition era, 6 years ago. So PHP is loads better, I'm sure, but I've seen the announcements of new features such as namespacing and closures, and it's clear that this stuff is shoehorned into the language and good use of these features is not ingrained into PHP culture.
In the case of rails, beyond the easily copyable superficialities of the MVC pattern, simple ORM and HTTP helper methods, what you have underneath is the elegance of the ruby OO model.
The ruby OO model with its mixins, implicit metaclass (eigenclass), and dynamic nature (ie. class definitions are just executable code), and standard functional features like lambdas w/ closures are all designed into the language in a very elegant way and this basic model has been more or less stable for the nearly 20 years of ruby's existence.
This means ruby code has a more consistent style and set of powerful idioms over time. Obviously there's a lot more shit ruby code getting written these days then there used to be, and modern PHP has a ton of power that can be leveraged very elegantly. However if you look at the corpi of popular open source ruby code vs popular open source PHP code over the years, you find a much higher bar of quality in the ruby code. Some of the attraction to the average rubyist is aesthetic, but that's not the whole story.
> and it's clear that this stuff is shoehorned into the language and good use of these features is not ingrained into PHP culture.
Every major PHP framework uses both namespacing and closures.
> The ruby OO model with its mixins, implicit metaclass (eigenclass), and dynamic nature (ie. class definitions are just executable code), and standard functional features like lambdas w/ closures are all designed into the language in a very elegant way and this basic model has been more or less stable for the nearly 20 years of ruby's existence.
What you're describing here is the difference in the language itself. The PHP OO model is more traditional and Java-like, but that doesn't implicitly make it worse or behind the times.
> However if you look at the corpi of popular open source ruby code vs popular open source PHP code over the years, you find a much higher bar of quality in the ruby code.
I can't speak for the Ruby side, but on the PHP side you couldn't be more wrong. The open source efforts in PHP in the last 5 years have been nothing short of excellent. The open source PHP community has completely adopted the full range of PHP features, unit testing (TDD and BDD), and coding standards (https://github.com/php-fig/fig-standards/tree/master/accepte...). This is nothing new and it's been like this for a while.
> Every major PHP framework uses both namespacing and closures.
No True Scotsman argument.
> The PHP OO model is more traditional and Java-like, but that doesn't implicitly make it worse or behind the times.
I don't care for fashion, so "behind the times" is neither here nor there, however a Java like OO model is definitely worse on most axes except foot-shooting and style-uniformity for large teams. If I want strong typing I want a system that leverages its power such as Haskell, not something like Java where compilation errors are mostly trivial things and I still end up with null pointers all over the place which is exactly the same as the most common type of error in more powerful dynamic languages. Beyond that, saying PHP OO is like Java is doing PHP a huge service because Java started out as OO with quite a strong vision. It may not have been perfect, and it's certainly developed its warts over time, but the seed of conceptual integrity in Java's OO is an order of magnitude more robust than PHP's.
> I can't speak for the Ruby side, but on the PHP side you couldn't be more wrong.
I was specifically making a comparison between PHP and Ruby. Making a one-side claim is a nonsensical response.
Kind of, but not really. The two major framework players in the PHP space right now are Zend Framework 2 and Symfony 2. This isn't really a "No True Scotsman" argument because both are headed up by reputable development shops (Sensio and Zend).
Both use namespaces.
> I don't care for fashion, so "behind the times" is neither here nor there, however a Java like OO model is definitely worse on most axes except foot-shooting and style-uniformity for large teams. If I want strong typing I want a system that leverages its power such as Haskell, not something like Java where compilation errors are mostly trivial things and I still end up with null pointers all over the place which is exactly the same as the most common type of error in more powerful dynamic languages. Beyond that, saying PHP OO is like Java is doing PHP a huge service because Java started out as OO with quite a strong vision. It may not have been perfect, and it's certainly developed its warts over time, but the seed of conceptual integrity in Java's OO is an order of magnitude more robust than PHP's.
Err, what? I'm not sure if I'm misunderstanding you here -- because PHP didn't have OO designs early on somehow that makes it's OO model less robust then Java's? I'm not going to bother arguing that point, but it certainly doesn't make me a less efficient developer. PHP's OO model is more than adequate for most web applications. I'm also not following the null pointer issue. Proper unit testing should vet null value issues out whether you're using a dynamic language or not. PHP has the (arguable) advantage of not completely shutting down when this mistake occurs.
> I was specifically making a comparison between PHP and Ruby. Making a one-side claim is a nonsensical response.
Not anymore of a one-sided claim than your own. You haven't done a lot of research into what's going on in the "popular open source PHP code" if you think your opinion is two-sided -- I'd strongly challenge you to point out what popular modern open source PHP code is inferior to popular modern open source ruby code.
It's not about frameworks so much as whether people use them. In Python and Ruby, pretty much everyone knows to look for useful gem or pip packages and uses frameworks and does a good job of avoiding reinventing wheels. In PHP, there's still a lot of old-guard cowboys and new blood that want to emulate them which aren't participating in the ecosystem, so the availability and quality of reusable code isn't there yet.
I completely disagree with your views about Drupal development. We've recently migrated bmj.com (a big site with gets 1.6 million visitors and 6.8 million page views a month) from old Java Servlet based platform to Drupal. We've used continuous development process where up to 4 developers were working on the same code base in dev, staging/testing and prod environments. It is now a standard Drupal development practice to export all configuration data to the source code. BMJ.com is not a simple site, it has an article page with quite complex data structure with up to 60 meta data elements (author details, publication date, vol/issue number, section, series, category, taxonomy, relations to other articles, open access flag, etc...) being rendered at the relevant blocks. The business and editorial departments have been happy with the new opportunities Drupal is offering them. For more detail, please access Drupal success case study: http://drupal.org/node/1557636
This does not say much about Drupal being good in absolute terms. It only tells us the obvious point that Drupal is a lot better then your old application.
What you state would have been just as trough had you developed in Rails, Django, and maybe even in PHPnuke. What you don't state, is why Drupal was the better fit compared to modern alternatives. Is it?
Wow. This sounds exactly like a complaint that would be lobbed against SharePoint (rightfully so, it's a special kind of hellish nightmare for people responsible for developing on it.)
Right you are @tedsuo
There are many ppl not writing tests and not using staging and best deployment practices. This is true in every CMS and WCF. I don't believe it it any more prevalent in Drupal than anywhere else.
Drupal invites a lot of BEGINNER types to the arena of web solutions. As such you will certainly find the things you mention.
I don't agree with your suspicion that big shops are hacking core and building custom CMSs upon Drupal in a vain effort to try and gain source control features.
Rather... I'm aware of big shops sticking to Drupal bets practices and using Features, Strongarm, Plumber and other modules to get configuration into code and keep it source controlled.
If Drupal deployment were the nightmare you s=describe, then the phenomenal adoption of Drupal that we see today would make no sense.
Why would the Georgia Tech Authority decide to move SIXTY-FIVE sites off of a Oracle, Java, Vignette solution and onto Drupal? Well.. It is isn't because they like nightmares during deployment.
Drupal is growing up.
The issues that plagued us 5 years ago when I got involved are being solved with varying degrees of success and effort. We're not where we want to be but the market is eating us up. We are bullish about our future and know that out continued improvement will only serve to better our position as the leader that we are in the web space.
Nope. They're busting the inner platform and having config live in the filesystem to get versioned like anything else. Good luck with those prejudices, though.
Does it address config drift in production where users make changes that aren't reflected in the versioned codebase? The question is not intended as a retort, I'm interested in the answer.
The prejudices I have against Drupal are the result of my experience of it starting as far back as version 4. I don't believe they are unfounded.
I'm currently investing moving our sites (a network with 1M+ visits/and 12M+ pageviews) from Drupal 6 to Rails.
We have a large amount of custom code (I've written 20+ modules for this platform), and yet we've gotten to a point where we really want Drupal (and PHP) out of our lives, because it isn't worth the headaches anymore.
Absolutely not true. When I was working with Drupal 6, CCK and Views 2, I would use the GUI to try out new content types and views, but I would then export their definitions and put the code for them into a custom module, which was under version control.
When I first started out I actually wasn't using CCK or Views 2, I was creating new node types with a custom module, and if I were to go back to Drupal now I would be sorely tempted to do this again. Views was a bit too fragile and the queries it generated were horrific, and I think if you can code and know PHP and MySQL well they really give you very little value, or possibly even work out slower overall.
WordPress too. In fact in WordPress the site root URL is stored in two separate configuration fields, so woe betide you if you rewrite one field and not the other.
Thankfully the WP core devs seem to have been slowly cleaning stuff like this up over the last couple years. So even though this wart persists, I have hope it'll eventually get zapped.
- NOT AMENABLE TO SOURCE CONTROL
Half the code lives in the database, configuration is all mixed up with content, and there's no reliable programmatic way to extract it. It makes doing deployment a nightmare.
And the worst part? Drupal developers by and large have such a narrow range of experience that they don't even know what they are missing. They have no idea what good coding standards look like, a lot of them don't even have a development/production separation: they just hack away on the live site with no source control or backup. And no one writes tests, or sees why they would be useful.
Some of the big professional drupal shops appear to have basically written their own cms on top of drupal, with a bunch of terrible hacks to try to make source control kind of work, and just use the drupal name basically as a marketing technique.
So glad I don't have to deal with any of that insanity any more.