Remove q=node from required modules
Drupal became popular because it made a lot of assumptions. It assumed, for example, that you want a page on your website that displays all promoted and published content in reverse chronological order with teasers. This is the path q=node. There are other paths that display content listings (taxonomy module is full of them), but most (all?) of the others can be turned off. q=node stands out as the shining example of a content listing path that is _required_ by core, and can't be turned off. This has consequences: http://www.flickr.com/photos/43545096@N00/3287922589/ http://www.flickr.com/photos/robertdouglass/3238757628/ I would like to argue that the required bits of core should not offer any paths that display content listings, and that the behavior of q=node in the case that no content is published/promoted is particularly damaging and should be removed. The issue: http://drupal.org/node/545758 -Robert
I would like to argue that the required bits of core should not offer any paths that display content listings, and that the behavior of q=node in the case that no content is published/promoted is particularly damaging and should be removed.
I would basically agree--having a switch to turn it off would be VERY smart for many sites we build also. I have browsed to /node on some sites just to see what kind of garbage (i.e. not properly themed) comes up. Many sites have pretty ugly stuff. Thanks
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-w... Damien On Tue, Aug 11, 2009 at 12:24 PM, Fred Jones <fredthejonester@gmail.com>wrote:
I would like to argue that the required bits of core should not offer any paths that display content listings, and that the behavior of q=node in the case that no content is published/promoted is particularly damaging and should be removed.
I would basically agree--having a switch to turn it off would be VERY smart for many sites we build also. I have browsed to /node on some sites just to see what kind of garbage (i.e. not properly themed) comes up. Many sites have pretty ugly stuff.
Thanks
Since when do we expect end users to write code? I know it's easy to do. That's why it should still be easy to get the feature into D7. Robert Douglass The RobsHouse.net Newsletter: http://robshouse.net/newsletter/robshousenet-newsletter Follow me on Twitter: http://twitter.com/robertDouglass On Aug 11, 2009, at 12:52 PM, Damien Tournoud wrote:
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-w...
Damien
On Tue, Aug 11, 2009 at 12:24 PM, Fred Jones <fredthejonester@gmail.com
wrote: I would like to argue that the required bits of core should not offer any paths that display content listings, and that the behavior of q=node in the case that no content is published/promoted is particularly damaging and should be removed.
I would basically agree--having a switch to turn it off would be VERY smart for many sites we build also. I have browsed to /node on some sites just to see what kind of garbage (i.e. not properly themed) comes up. Many sites have pretty ugly stuff.
Thanks
Quoting Damien Tournoud <damz@prealable.org>:
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-w...
Sounds like a RemoveNode module waiting to happen. End users who don't code can get the benefit from those who do. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
I can understand noone searched or even just looked at the issue queue. After all, you need to read almost a full page of patches to find http://drupal.org/node/375397 Make Node.module optional . It's too hard to find, it's too well hidden. I understand.
Oh and if we want just this URL to be disabled, write a <1K contrib that hook_menu_alters 'node' to access callback FALSE.
For all that I respect your contributions and hard work, you can be somewhat abrasive at times. <brianV> what's the best way to get rid of the main ?q=node content listing? <chx> brianV: how big lart do you want to be applied on you? <chx> brianV: in other word, are you fucking kidding me? <chx> brianV: i already wrote the devel list a polite version of "stfw n00b" <chx> http://lists.drupal.org/pipermail/development/2009-August/033411.html <brianV> chx: I've been following. I'm not writing a core patch, don't worry. I think it's an important part of core. However, I can see the benefit of having a contrib module for it, so I am following up on that. I am doing it with hook_menu_alter, just curious if there is a better way <brianV> chx: anyways, good to see I have the ability to get your hackles up first thing in the morning Anyways, I am shortly going to commit a contrib module for this. I've done it on half a dozen sites I've built. I just never thought that it might be useful to others. Just wanted to make sure doing it with hook_menu_alter was the most efficient / sensible way. Brian Karoly Negyesi wrote:
Oh and if we want just this URL to be disabled, write a <1K contrib that hook_menu_alters 'node' to access callback FALSE.
Thanks for keeping up with basic IRC policies and asking permission to quote a chat to a public mailing list before doing that. On Tue, Aug 11, 2009 at 6:25 AM, Brian Vuyk<brian@brianvuyk.com> wrote:
For all that I respect your contributions and hard work, you can be somewhat abrasive at times.
<brianV> what's the best way to get rid of the main ?q=node content listing? <chx> brianV: how big lart do you want to be applied on you? <chx> brianV: in other word, are you fucking kidding me? <chx> brianV: i already wrote the devel list a polite version of "stfw n00b" <chx> http://lists.drupal.org/pipermail/development/2009-August/033411.html <brianV> chx: I've been following. I'm not writing a core patch, don't worry. I think it's an important part of core. However, I can see the benefit of having a contrib module for it, so I am following up on that. I am doing it with hook_menu_alter, just curious if there is a better way <brianV> chx: anyways, good to see I have the ability to get your hackles up first thing in the morning
Anyways, I am shortly going to commit a contrib module for this. I've done it on half a dozen sites I've built. I just never thought that it might be useful to others. Just wanted to make sure doing it with hook_menu_alter was the most efficient / sensible way.
Brian
Karoly Negyesi wrote:
Oh and if we want just this URL to be disabled, write a <1K contrib that hook_menu_alters 'node' to access callback FALSE.
I apologize. It was done out of anger at your off-the-handle response to an innocent question. I was merely asking a question in pursuit of something you suggested yourself moments later on the mailing list. As much as I respect your work and contributions, your attitude is very off-putting. Regardless, it was an unprofessional response on my part, and I do sincerely apologize. Regards, Brian Karoly Negyesi wrote:
Thanks for keeping up with basic IRC policies and asking permission to quote a chat to a public mailing list before doing that.
On Tue, Aug 11, 2009 at 6:25 AM, Brian Vuyk<brian@brianvuyk.com> wrote:
For all that I respect your contributions and hard work, you can be somewhat abrasive at times.
<brianV> what's the best way to get rid of the main ?q=node content listing? <chx> brianV: how big lart do you want to be applied on you? <chx> brianV: in other word, are you fucking kidding me? <chx> brianV: i already wrote the devel list a polite version of "stfw n00b" <chx> http://lists.drupal.org/pipermail/development/2009-August/033411.html <brianV> chx: I've been following. I'm not writing a core patch, don't worry. I think it's an important part of core. However, I can see the benefit of having a contrib module for it, so I am following up on that. I am doing it with hook_menu_alter, just curious if there is a better way <brianV> chx: anyways, good to see I have the ability to get your hackles up first thing in the morning
Anyways, I am shortly going to commit a contrib module for this. I've done it on half a dozen sites I've built. I just never thought that it might be useful to others. Just wanted to make sure doing it with hook_menu_alter was the most efficient / sensible way.
Brian
Karoly Negyesi wrote:
Oh and if we want just this URL to be disabled, write a <1K contrib that hook_menu_alters 'node' to access callback FALSE.
Robert I agree. This is embarrassing at times. Core can look if the system has any nodes at all , and only emit the welcome message if there are no nodes (not nodes promoted/published). That would take care of 90% of the cases, the menu_alter would take care of the rest. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
Core can look if the system has any nodes at all , and only emit the welcome message if there are no nodes (not nodes promoted/published).
The message isn't in Drupal 7 any more, or at least, not at /node, it's been replaced by a short message inviting you to add some content. The real answer to this is the other thread on this list at the moment - views in core, so that the default front page (and default taxonomy, forum, blog and other listings) is just a view which you can enable, disable or modify. Nat
I can't remember the last time I actually used /node. It's a great default for a fresh install and new users, but quickly becomes a problem for established users. I won't deny that a tiny contrib module would solve things, but it strikes me as the wrong solution. If I have to install a module that only does one menu_alter, then it really starts to sound like I'm having to work around a flaw instead of extending functionality. I don't think any of us want /node removed. We'd just rather have the ability to disable it, like we can with suggested menu items. ~Rob On Tue, Aug 11, 2009 at 9:20 AM, Nathaniel Catchpole <catch56@googlemail.com
wrote:
Core can look if the system has any nodes at all , and only emit the
welcome message if there are no nodes (not nodes promoted/published).
The message isn't in Drupal 7 any more, or at least, not at /node, it's been replaced by a short message inviting you to add some content.
The real answer to this is the other thread on this list at the moment - views in core, so that the default front page (and default taxonomy, forum, blog and other listings) is just a view which you can enable, disable or modify.
Nat
While the issue that you reference overlaps with my concern I believe they are different and therefore warrant two issues. My proposed change would find its way into the node module whether node module is required or not, and my concern would remain even if the patch you referenced went in. But thank you for cross checking. -----Original Message----- From: Karoly Negyesi <karoly@negyesi.net> Reply-to: development@drupal.org To: development@drupal.org Subject: Re: [development] Remove q=node from required modules Date: Tue, 11 Aug 2009 06:10:45 -0700 I can understand noone searched or even just looked at the issue queue. After all, you need to read almost a full page of patches to find http://drupal.org/node/375397 Make Node.module optional . It's too hard to find, it's too well hidden. I understand.
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-w...
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. Cheers, J-P
Some sort of glob- or regex-based URL locking-down,
Contrib. hook_menu_alter. I mentioned already :)
Well, that hook's certainly one starting place. But it doesn't on its own solve the broader problem of how a non-developer could lock down more than just q=node. How about extending the access rules interface and system, and then using hook_boot() to call drupal_is_denied()? http://code.torchbox.com/svn/drupal-modules/tags/ar_path/ALPHA-0.1/ar_path.m... Cheers, J-P
.. or just create a new permission for /node so that we can just block access to it. ~Rob On Tue, Aug 11, 2009 at 11:32 AM, J-P Stacey <jp.stacey@torchbox.com> wrote:
Some sort of glob- or regex-based URL locking-down,
Contrib. hook_menu_alter. I mentioned already :)
Well, that hook's certainly one starting place. But it doesn't on its own solve the broader problem of how a non-developer could lock down more than just q=node.
How about extending the access rules interface and system, and then using hook_boot() to call drupal_is_denied()?
http://code.torchbox.com/svn/drupal-modules/tags/ar_path/ALPHA-0.1/ar_path.m...
Cheers, J-P
Isn't there a way to create a view with an argument that will catch all calls to node and send it where ever you want them to go? Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Robert Wohleb <rwohleb@techsanctuary.com> Date: Tue, 11 Aug 2009 12:00:38 To: <development@drupal.org> Subject: Re: [development] Remove q=node from required modules .. or just create a new permission for /node so that we can just block access to it. ~Rob On Tue, Aug 11, 2009 at 11:32 AM, J-P Stacey <jp.stacey@torchbox.com> wrote:
Some sort of glob- or regex-based URL locking-down,
Contrib. hook_menu_alter. I mentioned already :)
Well, that hook's certainly one starting place. But it doesn't on its own solve the broader problem of how a non-developer could lock down more than just q=node.
How about extending the access rules interface and system, and then using hook_boot() to call drupal_is_denied()?
http://code.torchbox.com/svn/drupal-modules/tags/ar_path/ALPHA-0.1/ar_path.m...
Cheers, J-P
Quite close. I was thinking on the bus about this and I thought 'access content listings'. On Tue, Aug 11, 2009 at 12:00 PM, Robert Wohleb<rwohleb@techsanctuary.com> wrote:
.. or just create a new permission for /node so that we can just block access to it.
~Rob
On Tue, Aug 11, 2009 at 11:32 AM, J-P Stacey <jp.stacey@torchbox.com> wrote:
Some sort of glob- or regex-based URL locking-down,
Contrib. hook_menu_alter. I mentioned already :)
Well, that hook's certainly one starting place. But it doesn't on its own solve the broader problem of how a non-developer could lock down more than just q=node.
How about extending the access rules interface and system, and then using hook_boot() to call drupal_is_denied()?
http://code.torchbox.com/svn/drupal-modules/tags/ar_path/ALPHA-0.1/ar_path.m...
Cheers, J-P
What about redirecting it to <front> if it's not the front page and there is content? On Tue, Aug 11, 2009 at 12:00 PM, Robert Wohleb<rwohleb@techsanctuary.com> wrote:
.. or just create a new permission for /node so that we can just block access to it.
~Rob
On Tue, Aug 11, 2009 at 11:32 AM, J-P Stacey <jp.stacey@torchbox.com> wrote:
Some sort of glob- or regex-based URL locking-down,
Contrib. hook_menu_alter. I mentioned already :)
Well, that hook's certainly one starting place. But it doesn't on its own solve the broader problem of how a non-developer could lock down more than just q=node.
How about extending the access rules interface and system, and then using hook_boot() to call drupal_is_denied()?
http://code.torchbox.com/svn/drupal-modules/tags/ar_path/ALPHA-0.1/ar_path.m...
Cheers, J-P
participants (12)
-
Brian Vuyk -
Craig Gardner -
Damien Tournoud -
Earnie Boyd -
Fred Jones -
imaaxa＠gmail.com -
J-P Stacey -
Karoly Negyesi -
Khalid Baheyeldin -
Nathaniel Catchpole -
Robert Douglass -
Robert Wohleb