not available for comments?
robotjox - June 26, 2007 - 14:29
| Project: | Filter by node type |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
Hi,
thanks for this module.
However, I have a problem.
I have 2 input formats on my site; 'Full HTML' and "Wikiformat'.
I want authenticated users to be use 'Full HTML' on the forums and 'Wikiformat' in the wiki.
The problem is that they are able to choose from both input formats in the forums when replying to posts, which I don't want (it'll confuse the poor bastards).
I see no option in this module to restrict formats for comments.
Is this possible somehow?
thanks
Morten
#1
Comments are not currently supported, just node bodies. It's probably possible to extend it to do comments, but I haven't tried doing so.
#2
i would like to have this possibility also.
thanks,
pht3k
#3
yes - that would be nice ...
greetings momper
#4
The code below should work but needs some refinements.
<?php
function filterbynodetype_form_alter($form_id, &$form) {
if (isset($form['type']) && 'node-form' == $form['#id']) {
//use the existing code
}
// ********* APPLY TO COMMENTS *********************
if ('comment-form' == $form['#id']) {
$node = node_load($form['nid']['#value']);
$type = $node->type;
$formats =& $form['comment_filter']['format'];
foreach (element_children($formats) as $element) {
if (! variable_get('filterbynodetype_' . $formats[$element]['#return_value'] . '_' . $type, 1)) {
unset($formats[$element]);
}
}
if (2 == count(element_children($formats))) { // 1 format and 1 extra item for the link
// If there's only one filter left, fold it down to just the description
$formats = $form['comment_filter']['format'];
unset($form['comment_filter']['format']);
// We don't know what the IDs are of the two fields, so we have to iterate to get them.
foreach (element_children($formats) as $element) {
if (isset($formats[$element]['#title'])) {
// This is a filter, so we assign it to the filter set as the only option.
$form['comment_filter']['format'][$element] = array(
'#type' => 'value',
'#value' => $element,
'#parents' => array('format'),
);
$form['comment_filter']['format']['format'] = array( // I have no idea why it uses this structure, but this is what filter.module does.
'#type' => 'item',
'#description' => $formats[$element]['#description'],
);
}
else {
// It's the guidelines text.
$form['comment_filter']['format']['guidelines_link'] = array(
'#value' => $formats[$element]['#value'],
);
}
}
}
if (1 == count(element_children($formats))) { // 1 extra item for the link, which means there's no filters left
// Do nothing. The form becomes unsubmittable all on its own.
}
}
}
?>
Hope it helps..
#5
@tjerah: Can you roll a proper patch? Thanks: http://drupal.org/diffandpatch
#6
@tjerah : Correct me if I'm wrong your but your solution only alters the form so a user can't select a non-allowed filter. This is probably all a lot of sites need however a malicious user could still manually enter another filter option. In most case this level of paranoia probably isn't warranted. But if you were trying to restrict users from PHP filter access on comments or you had a really bad case of persistant link spammers then maybe it could be a problem.
Anyhow I've hacked by own shorter version of this. I'm not using 'Filter by node type' at the moment so this doesn't depend on it.
<?php
function mymodule_form_alter($form_id, &$form) {
if($form_id == 'comment_form') {
$formats =& $form['comment_filter']['format'];
foreach($formats as $i => $f) {
// delete all filter options apart from filter '1'
if(is_array($f) && $f['#title'] && ($f['#return_value'] != 1)) {
unset($formats[$i]);
}
}
}
}
?>
Thanks pointing me in the right direction.
#7
Nope. Drupal's Form API, by default, will check to ensure that a submitted value for a select box or radio button is one of the values listed in the form. That was one of its original reasons for existing. If the form, as it exists post form_alter, has only 2 possible radio buttons, then Drupal will reject any other value before it ever gets back to our submit handler. Form API is cool like that. :-)
#8
That is indeed cool. Thanks for letting me know.
#9
subscribing
#10
New features only accepted against the D6 version. And this still doesn't have a patch.
#11
Here's a patch for a version of the module that handles comments per content type identically to the content types themselves. I've used some of the code from the module and the code from tjerah's post, and modified both slightly.
#12
Actually, that patch doesn't apply the permissions settings. Here's an updated patch.
#13
Haven't looked at the code yet, but it doesn't make sense, IMO, to restrict comments to the same format as the node. That makes sense only for forums, but not for anything else. It should either be all comments period, or comments-per-nodetype. The latter is probably more flexible.
#14
There's a bit of misunderstanding here. Reading my post again, I can see why, but the patch gives comments-per-nodetype.
Here's what the form layout looks like (list items for checkboxes):
Allowed input formats:
Specify which input formats will be allowed on this node type's body field. Note that a user must still have access to the appropriate input format in order to be able to use it.
Allowed input formats (comments):
Specify which input formats will be allowed on this node type's comments. Note that a user must still have access to the appropriate input format in order to be able to use it.
#15
Ah! OK, good, that's what we should do. :-) I'll see if I can review this soon, but, um, no promises. (Anyone else who wants to jump in here and review the patch, feel free.)
#16
applied patch from #12, see no changes at all in the node type settings form
well scratch that. this was due to http://drupal.org/node/326373,
new options do show up, settings work fine. approved.
#17
changing the title
#18
well, thinking about that - you should apply the fix from http://drupal.org/node/326373 to you patch also. It's just one letter :)
#19
Oh, forgot, one more thing
this line
<?phpreturn if user_access('bypass filter restrictions');
?>
gives php error
#20
Here's the updated version.
#21
will this feature be backported to D5?
#22
Personally I only learned D6 coding, so it won't be backported by me, sorry.
#23
The D5 version is in support mode now, so I won't be adding new features to it. I don't have enough spare bandwidth to work on new features for both versions.
I'll try to test this patch as soon as I get the chance. Others are welcome and encouraged to do so in the meantime. :-)
#24
I gave this patch a run-through today, and it works well although I have some comments on the code and implementation
- This patch also fixes a typo bug (the role 'administer filters' is mis-spelled in filterbynodetype_form_node_type) which has already been fixed and committed in #326373: Non-uid 1 cannot set configuration
- I think it makes more sense to put the comment input filter settings under 'Comment Settings' rather than in 'Submission Form Settings' with the other choices.
- There is a lot of repeated code here and I'm thinking there should be a way to break it out into a function call for the sake of maintainability.
Otherwise this is great and well-needed.
#25
Thank you for reviewing the patch heyrocker.
Previous reviewers asked for that change to be included in this patch. I remade the patch to do so. I do not know which way to go with this now.
#26
The dev release of this module already has that bugfix, so the patch here won't apply if you try to fix it again. Don't fix what's already been fixed. :-)
#27
Okay, I have attempted to address these issues:
I agree, but I don't think it is possible. The comment module uses hook_form_alter, just like filterbynodetype does. comment.module thus overwrites the comment section with a blank fieldset element, erasing any fields which filterbynodetype may have added to it. Going by this, there's nothing I can do about this.
I've done that in this new version of the patch. I didn't move everything inside the if blocks, but trying to move all the code out would require a lot more if statements and probably create more maintenance worries.
#28
We can always push the module weight up to be comment.module +5 or something. That can be done in the installer and in an update hook.
#29
I've applied that technique, but I also had to move some of the code around, so this patch is now bigger than either module file. I've also patched the install file, which allowed me to add variable clean up to filterbynodetype_uninstall() as well.
#30
Subscribing, greetings, Martijn
#31
Hello,
I made a patch to support comments before finding this discussion. It does solve some the most important issues you mention here, however, so I submitted it anyway. It's against 6.x-1.2, so a made a separate issue. I needed it in production, so I didn't even think about working with 6.x-dev - sorry about that!
Anyway, please check out #351313: Comment support, maybe it could be useful.
Marcin
#32
Through my own use I did find a bug with this patch and I fixed it.
#33
the patches in #32 are working for me.
I have re-rolled them though into one file.
#34
I found some typos in a comment or two, those have been fixed in this patch
#35
Thanks jrglasgow.
I've been using the old version for about 3 months, and this new version for about a week now with no problems.
With that plus jrglasgow's review, would it be appropriate to status change this to "reviewed & tested by the community"?
Maybe even... get it into the module?
#36
I feel that it is in fine working order. I think it should be considered tested
#37
This patch has been committed, thanks all for your help and patience.
I'm going to do some slight code cleanup and roll a new release later today.
#38
#39
Automatically closed -- issue fixed for 2 weeks with no activity.