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…
It all just sounds so complex. Hmmm, how would I ever expect students and/or faculty to navigate this treacherous path of input formats?Well, luckily they don’t have to in Drupal, spoon fed simplicity including everything but the bib, but that ain’t managing yur digital profile, its a Adobe Contribute with a few more bells and whistles. The more I think about this, the more Drupal makes less and less sense to me.
um… what? Drupal rocks, for managing a LOT of content. It’ll do things for making (and keeping) sense for a constantly changing set of content based on all kinds of funky workflows and scenarios. I don’t think I’d even try to manage a website without Drupal as the back end anymore… It’s got some really minor irritations (like this pet peeve) but nothing fatal, and certainly nothing worth avoiding it as a CMS over. on over 99% of websites, this peeve wouldn’t even be an issue – it just showed up because I was needing to do some pretty funky things with dynamic content within nodes…
but, yeah… have fun with Contribute… 🙂
I had what sounds like a similar issue. After digging into the form api, we created a small module which we call falter. We use it to modify forms like this. Now, different users on our site have different options for input formats. For instance, if you log into our drupal deployment, you won’t see an option for different input formats, we default it to a predefined format after the server has been submitted. Let me know if you’re interested and I’d be happy to share our code with you. It isn’t contrib-code ready, but I’m happy to excerpt parts of it.
Hello, D’Arcy —
First, I am drop-dead *stunned* to hear Jim talk smack about Drupal — from reading his blog, I have never heard him express anything but love for the streamlined simplicity of the app.
This snippet could help with the tinymce issues: http://drupal.org/node/106978 — and this module allows you to weight input filters: http://drupal.org/project/filter_default
You can also set tinymce to not show up on specific pages, and, for even further control, you can set it to appear by role, by node type, by using php snippets in the TinyMCE settings —
While this involves more setup time from the admin, once the work is done it allows a more streamlined end user experience —
@Matt — I’d love to see your module, even if it’s not contrib ready — it sounds useful for a variety of situations.
Cheers,
Bill
Sorry for the late response, but basically here’s some sample code that could be used in this type of context. In this case, some code for a module called falter could be used to modify the form to hide filter options and then add a hidden field that specifies the format. Alternately, I guess you could set this after the form has been submitted. Other code could be added to limit or open options for users with particular roles or permissions. I really like this approach b/c we didn’t have to hack core to make this happen.
function falter_form_alter( $form_id, &$form) {
if( $form_id == 'blog_node_form') {
falter_alter_blog( $form);
//print_r( $form);
}
if( $form_id == 'comment_form') {
falter_adjust_comment( $form);
}
} // function falter_form_alter
function falter_adjust_comment( &$form) {
$form['comment_filter']['format'] = array(
'#type' => 'hidden',
'#value' => 1, //id is input filter you want
);
} // function falter_adjust_comment
function falter_alter_blog( &$form) {
$form['body_filter']['filter'] = array(
'#type' => 'hidden',
'#value' => 3, //id is input filter you want
);
} // function falter_alter_blog
Related to the TinyMCE problem, we use a combination of XStandard and FCK Editor, but we’ve added code for certain users to be able to turn it off …
I hope that helps … oh, and let me know if you see any problems with our approach. We’re learning a lot about drupal, but there is still a lot to learn!
Thanks,
Matt
you can use codeprotect if you dont like tiny messing up everything.