I screwed up in a big way on one of our higher profile Drupal sites. I had configured the default inputformat to include PHP execution, because there are a whole bunch of pages on the site that need to be able to execute PHP, and that was the easiest way to get it done. I was lazy, and didn’t follow best practices. And it resulted in a pretty open security hole, where anyone could create an account and then execute their own PHP (to do stuff like promote their account to Admin, delete the database, send emails, launch ICBMs…). Not cool.
Why was I so sloppy? Basically, I forgot that I’d left user registration open. The site is supposed to be a closed ecosystem, but with user registration enabled, it ain’t.
What I should have done was create a separate “über-inputformat” that included PHP execution, and was only available to admin users on the site. I would then have a separate, more limited inputformat as the default, perhaps with html tag filtering, as well. But here’s where I got lazy – there is no way for me to say “I know that ‘n00b’ is the default format, but I only ever want to use ‘über-inputformat’ so don’t make me choose each and every time I create a node”. Having more than one inputformat available causes the display of a new “input format” control in the node authoring form, and users have to first understand wtf that means, and then they have to figure out why they’d want to choose any of the available options. And if you’re creating a whole bunch of nodes with PHP in them, you have to remember to change each and every one to the “über-inputformat” inputformat, or the code won’t execute. pita.
Which brings me to D’Arcy’s Drupal Pet Peeve #2: Loose inputformat control. You can say which is the default, and then EVERYONE gets to use that. Then, you can add on other additional and optional inputformats, and enable them only for specific roles. But you can’t say that “n00b” is the only available inputformat for anonymous and authenticated users, and that “basic” is the only available inputformat for “members” and that “über-inputformat” is the inputformat to be used by default by admins.
As a corollary to Pet Peeve #2: TinyMCE ignores inputformats. If I have an inputformat configured with PHP execution, TinyMCE is completely happy to try to provide an editor for that, obliviously clobbering the code within the node. You have to go to your account and (temporarily) disable TinyMCE rich text editing before editing any node with PHP in it. It’d be really nice if you could tell TinyMCE to NOT kick in on certain inputformats…