Has anyone attempted to create a "post here" module; in other words, if a user wanted to add content, they would automatically do so directly in the taxonomy that they are currently viewing?

I believe that would be easier for users, if they are viewing a specific category, the posting page would not ask them where they wanted to post and they wouldn't have the opportunity to make a mistake.

Of couse they could still use the regular "create content" link for universal access.

I am wondering if this has been attempted or if someone is already working on a similar idea, if not, I may try this as my first Drupal hack.

Thanks.

Comments

moshe weitzman’s picture

this does not exist yet ... i did edit bok.module to output a'create book page here' link in every book page. that link prefills the 'Parent' dropdown in the book ... similar idea.

fx-1’s picture

Here's a diff for a cleaner approach than the one I posted this morning. It entails patching node.module to add a new hook: _taxonomy_node_form()




This diff patches blog.module as an example of the proposed usage.




It also patches taxonomy.module to produce "post here" links for each node type at the bottom of pages generated by taxonomy_page()




Not convinced this is the "right" way but it is getting closer.




There are no access checks in this diff since it is intended for evaluation and comment as a way to address the issue, not as a submitted patch...




diff made against cvs HEAD. the usage of arg(3) kinda bugs me. but the alternative is modifying the arg struct of node_form and that begs for a lot of other changes.




[?

*** taxonomy.module 2004-06-10 12:15:29.000000000 -0700
--- /home/los/drupal-cvs/drupal/modules/taxonomy.module 2004-06-02 15:17:49.000000000 -0700
***************
*** 759,780 ****
drupal_set_html_head('
str_tids") .'" />');

$output = taxonomy_render_nodes(taxonomy_select_nodes($taxonomy));
-
-
- // Shortcut links to post to "this" term
- $output .= '

Create new: ';
-
- $tid = arg(3); // hack.
-
- $term = taxonomy_get_term($tid);
- foreach (node_list() as $type) {
- $output .= l(node_invoke($type, 'node_name'), 'node/add/'.$type.'/'.$tid)." | ";
- }
-
- $output .= ' in "'.$term->name.'"';
- $output .= '

';
-
-
print theme("page", $output, implode(', ', $names), $breadcrumbs);
break;
}
--- 759,764 ----
*** blog.module 2004-06-10 12:20:32.000000000 -0700
--- /home/los/drupal-cvs/drupal/modules/blog.module 2004-06-10 12:22:38.000000000 -0700
***************
*** 210,245 ****
}
}

$output .= form_textarea(t('Body'), 'body', $node->body, 60, 15, $error['body'] ? $error['body'] : filter_tips_short());

return $output;
}

- function blog_taxonomy_form($tids) {
- if ($tids) {
- $node->taxonomy = $tids;
- $output .= '

';
- }
-
- if (function_exists('taxonomy_node_form')) {
- $output .= implode('', taxonomy_node_form('blog', $node));
- }
-
- if ($tids) {
- $output .= '

';
- $output .= 'Message will be posted to: ';
- foreach (explode(',', $tids) as $tid) {
- $term = taxonomy_get_term($tid);
- $output .= $term->name . ' | ';
- }
- $output .= '
';
- }
-
- return $output;
- }
-
-
/**
* Implementation of hook_content().
*/
--- 210,224 ----
}
}

+ if (function_exists('taxonomy_node_form')) {
+ $output .= implode('', taxonomy_node_form('blog', $node));
+ }

$output .= form_textarea(t('Body'), 'body', $node->body, 60, 15, $error['body'] ? $error['body'] : filter_tips_short());

return $output;
}

/**
* Implementation of hook_content().
*/
*** node.module 2004-06-10 12:16:55.000000000 -0700
--- /home/los/drupal-cvs/drupal/modules/node.module 2004-06-10 12:22:39.000000000 -0700
***************
*** 1168,1180 ****
$form .= $function($edit, $error, $param);
}

- // Hook for taxonomy term handling
- $function = node_get_module_name($edit) .'_taxonomy_form';
- if (function_exists($function)) {
- $form .= $function(arg(3));
- }
-
-
// Append extra node form:
$form .= implode('', node_invoke_nodeapi($edit, 'form post', $error));

--- 1168,1173 ----

?]




Now if at this point you are thinking "this is an awful lot of hassle just to hide a form selector", imagine what it is like when you have five or ten vocabularies mapped to a node type.




I am reminded of a quote I can't properly attribute, but which went something like: "People have an information management problem, and then they say 'oh, I know -- I'll use an ontology (or controlled vocabulary)' -- and then they have TWO information management problems".




But this is in the case of some companies I have worked with a fact they have to deal with. Mixing the vocabularies isn't always an option, and the usabilty starts to seriously degrade when end-users who aren't savvy enough, encounter forms with too much information (or too many options) on them...




Anyway, I hope this is a step in getting this properly addressed one way or another.


ps. it looks like some filter tips updates snuck in there. those aren't my changes, must have happened in between making the changes and the diff.

ti’s picture

Isn't "post here" the same functionality as a Wiki? People can post not only to the same taxonomy term, but the same node, on a wiki. I might be misreading your original comment.

fx-1’s picture

hmm. i've done this, but it was a matter of patching multiple modules because this snippet of code:


  if (function_exists('taxonomy_node_form')) {
    $output .= implode('', taxonomy_node_form('blog', $node));
  }



... is not called just in node.module's node_form() hook, but rather called by blog.module, page.module, story.module, etc, etc...




if all one wants to do is pre-select a term, that's easier -- drop a couple lines in which pick up url args from $_GET. adding "&tids=1,2,3" to the "post here" target url for example, and applying it to node->taxonomy in node_form().


that still leaves the dropbox/select list on the form, which can pose usability / human factors issues. you might then wrap the term selector call/output in a div with style attrib of display: none set in the presence of your pre-selected url args. note: the output still needs to get generated, but hidden from display. the snippet above would become something like:

  // modified from blog.module

  $hide = 0;
  $tids = $_GET["tids"];

  if ($tids) {
        $output .= form_hidden("edit[taxonomy][]", $tids);
        $node->taxonomy = $tids;
        $output .= '<div tyle="display: none;">';
        $hide = 1;       
  } 
        $output .= implode("<br />", taxonomy_node_form("blog", $node)).'<br clear="all"/>';

  if ($hide)
          $output .= '</div>';





if you have enough time to spend on this you might be better served by studying how the nodeapi() calls work (as opposed to the node_form, node_view, etc hooks) and proposing some extentions to it to better support customization of term selection presentation and processing... it is on my list of stuff to do, too, but a bit down there.

jasonwhat’s picture

which patches above should I use to allow users to do the "Post here" or even better for me "blog this" and blog on stories they are reading adding it to that category. I'm no coder so I can't figure what from above is supposed to go where, or if it is working.

andynyc’s picture

I did create a full patch to add this functionality, however it was decided not to add to the core at this time. The patch is available here: http://drupal.org/node/view/9474

This does NOT add "blog this" capability. What it does, is if the user is viewing a single taxonomy (such as taxonomy/page/or/9, or other taxonomy-rendering module), it produces a "post to this category" link, and when the user gets the input form, there is no taxonomy list to select from... it has already been determined. But it does NOT do anything with the content of a node, like a "blog this" function would do.

Note that this is not a module... it requires changes to the taxonomy module, and any other module you use to display taxonomies (my patch also patches the "taxonomy_menu" module, but there are many more taxonomy-rendering modules). It also requires changes to your theme, which is what actually renders the link itself. My theme is based on XTemplate so I have patched that, but no other theme engines.

That being said, the changes are not too big so if you are reasonably comfortable with coding you'll be fine. I've tried documenting all the changes so you should be able to follow what is going on.

Sorry for the late reply, I'll follow this post more closely so if you have issues I'll try to help.