Drupal’s “Promote to Front Page” option is a bit borked

I’ve just realized that the “Promote to Front Page” option – which lets users flag their content so that it will be displayed on the front page of the Drupal site as well as in their own blog/group pages, is rather borked. The setting that enables this option is part of the “Administer Nodes” access permission. Enabling that permission also grants the user to edit any content in that instance of Drupal. Which might be fine in a small and closed system, but when you’ve got a system like weblogs.ucalgary.ca with a growing number of users, and they’re using it for academic purposes, it’s not a great scenario.

Here’s what I just had to post on both weblogs.ucalgary.ca and the Education ePortfolio Drupal sites:

I have temporarily disabled the “Promote to Front Page” option (and the set of related content-administration options). Turns out that the setting that opens up these options for users while writing content also enables them to edit any piece of content in the system. That’s a Bad Thing™ – especially now that we’re starting to roll this service out for use in the classroom. I’m looking into possible ways to enable the Promote feature (or something similar) – for now, if you have a post that you’d like to see on the front page, email me the link, and I can set the proper flag.

So… Is there a way to enable “Promote to Front Page” without slapping an “Edit” button on every node in the database? I’ve read about the hack to add a Feedback link that emails an admin with a request to manually promote a node, but that sucks, and won’t scale. Ideally, just a separate setting that exposes the Promote option (and even more ideally, the “Published” option as well) to Regular Users.

8 thoughts on “Drupal’s “Promote to Front Page” option is a bit borked”

  1. I’m not sure how this is going to come through. If you want to change the node.module the change is below and starts on line #1302. I’m not sure how familar with the code you are.

    // Add the admin-specific parts. if (user_access('administer nodes')) { $output .= '<div class="admin">'; $author = form_textfield(t('Authored by'), 'name', $edit->name, 20, 60); $author .= form_textfield(t('Authored on'), 'date', $edit->date, 20, 25, NULL, NULL, TRUE); $output .= '<div class="authored">'; $output .= form_group(t('Authoring information'), $author); $output .= "</div>\n"; $output .= "</div>\n"; } $output .= '<div class="admin">'; $node_options = variable_get('node_options_'. $edit->type, array('status', 'promote')); $options .= form_checkbox(t('Published'), 'status', 1, isset($edit->status) ? $edit->status : in_array('status', $node_options)); $options .= form_checkbox(t('In moderation queue'), 'moderate', 1, isset($edit->moderate) ? $edit->moderate : in_array('moderate', $node_options)); $options .= form_checkbox(t('Promoted to front page'), 'promote', 1, isset($edit->promote) ? $edit->promote : in_array('promote', $node_options)); $options .= form_checkbox(t('Sticky at top of lists'), 'sticky', 1, isset($edit->sticky) ? $edit->sticky : in_array('sticky', $node_options)); $options .= form_checkbox(t('Create new revision'), 'revision', 1, isset($edit->revision) ? $edit->revision : in_array('revision', $node_options)); $output .= '<div class="options">'; $output .= form_group(t('Options'), $options); $output .= "</div>\n"; $extras .= implode('</div><div class="extra">', node_invoke_nodeapi($edit, 'form admin')); $output .= $extras ? '<div class="extra">'. $extras .'</div></div>' : '</div>'; //}

  2. Jason, thanks for the ideas! I’ll give it a shot first thing in the AM. Both of the sites that need this are still running 4.6.5 – I didn’t want to push 4.7b3 into full production yet (although I did sneak it into a project, so I guess I will have a 4.7-series site in production – but that one doesn’t require this granularity).

    Thanks again! Much appreciated!

    • D’Arcy
  3. Actually better yet, remove line #1672, #1686-#1694 removing the if statement completely. If you are working with something other than beta 3 let me know and I can forward the change.

  4. I thought of two possible options since Drupal core does not afford you that granular of permissions.

    The first is to create a taxonomy called “Promote to Front Page” and require it on new content with “unpublished” set as the default. Then you can change your front page in your config to a custom node.

    The second requires you to edit the core node.module line #1683 in Drupal 4.7 beta 3. Just copy that line down somewhere between line #1688-1693 where the user section is defined. This does require you to maintain a fork though.

    Maybe there are some other ways, but I couldn’t think of any off the top of my head.

  5. Ignas – yeah this page looks borked. Likely something in the first comment blew out the structure of the page. The comment is useful, though, so I’d rather live with a bit of noise for now. I’ll see if I can clean it up, but I think this is the only page affected, so it’s not a site-wide thing.

  6. ah. easy fix. just encoded the brackets in the code in the first comment. better… Thanks for the heads-up!

Comments are closed.


The spammers win. I've disabled comments. Again. It's just not worth having to deworm my site from the inane autospam jabber that trickles through the spam filters. Sorry. I can be contacted via the Contact form here on the site, or out on the internets (I'm @dlnorman on twittar).

BUT I WANT TO POST A COMMENT HERE. WITNESS THE OPPRESSION INHERENT IN THE SYSTEM.

If you need to post a response, trackbacks are enabled and will be displayed normally.

The Trackback URL for this post is:
http://darcynorman.net/2006/01/23/drupals-promote-to-front-page-option-is-a-bit-borked/trackback/