[development] Remove q=node from required modules

J-P Stacey jp.stacey at torchbox.com
Tue Aug 11 13:28:10 UTC 2009

>> The only true answer is: learn to add three lines of PHP code.
>> http://paris2009.drupalcon.org/session/how-use-light-side-bend-drupal-your-way
> Sounds like a RemoveNode module waiting to happen.  End users who don't code
> can get the benefit from those who do.

Would such a module be embargoed until after Gábor's talk? :)

Going back to Robert's original point, it would be good to have a way
of reliably stripping back fresh-install Drupal so that there are *no*
surprises like this. He only highlights one URL but other URLs "leak"
outside the q=admin namespace quite happily. Just writing a module to
fight q=node doesn't protect you against q=rss.xml, for example.

Admittedly both those examples are handled by node.module, so the
issue Karoly mentions would certainly be one solution to that, but you
shouldn't have to turn node.module off, or patch core, just to turn
q=node off. What if I (as a non-PHP site developer) want nodes of
content on my site (not unreasonably), but don't want q=node to
respond with a potentially theme-garbled page (also not unreasonably)?

Some sort of glob- or regex-based URL locking-down, and some sort of
developer tool to investigate and poke the callback registry in real
time (kitten.module, anyone?) without ploughing through var_dump()
outputs, would both be great. I'd love the chance to get involved with
rapid-prototyping this sort of thing at Drupalcon: hopefully the Light
Side will live on after the actual talk, all hazy and indistinct like
Alec Guinness.


More information about the development mailing list