By ventoo on

Am using Drupal 6.4, Bluemarine theme, with fckeditor only non-core module installed.

I want to filter out certain keywords a user might type in posts or comments.

I've observed the following:

1. For Commments, the first and last comma-separated keywords defined under Actions ("Unpublish comment containing keyword(s)") are totally ignored by the corresponding Triggers ("Trigger: After saving a new comment" and "Trigger: After saving an updated comment")

In other words, if the keywords are: cowboys, vikings, giants, bears

then: "cowboys" and "bears" in a comment will NOT result in the comment being unpublished

Workaround (if using fckeditor): define keywords as follows: cowboys, cowboys, vikings, giants, bears, bears

It appears that this problem is due to fckeditor rendering the keywords field as follows:

cowboys, vikings, giants, bears

and the <p> and </p> become part of the first and last keywords

So one can either use the above workaround or not use fckeditor!

2. For Posts, all keywords are simply ignored. It does not work. The same keywords as above will NOT result in unpublishing posts when I assign "Unpublish post containing keyword(s)" to "Trigger: When either saving a new post or updating an existing post" under Content.

I have been unable to find a workaround. It's strange that what works for comments does not work for posts. I'd have thought the same code would be used for filtering either comments or posts.

Is this a known problem with 6.4? Anyone have a workaround for 2. above?

Thanks!

Edited by: VeryMisunderstood: Added code tags around HTML tags so that didn't get stripped

⋅ Categories: Drupal 6.x

Comments

vm’s picture

vm commented

seems to me you want to investigate wordfilter.module and because the line break filter is probably enabled may explain why the <p> tags may be causing static.

With regards to fckeditor, I can't comment I don't use it. When deploying an editor I ensure I create a new input format with minimal filters enabled on that input format. This does a lot to insure that the applying of a filter isn't interfering with a node created with an editor.

heather’s picture

heather commented

The issues queue will get you a better response (more informed, quicker), and it will be easier for developers to track the bug.

1. http://drupal.org/node/add/project-issue/fckeditor
- Just copy and paste the message in your first question there, selecting which ever version is appropriate. This is a bug.

2. http://drupal.org/node/add/project-issue/drupal
- This is the main Drupal project issue queue so you should select the "Component" >trigger.module in pull down menu. This is a support request.

Best of luck!

ventoo’s picture

ventoo commented

Thanks, Heather!

bcn’s picture

bcn commented

Do you still have the same problem (with action/triggers not un-publishing) if FCK is disabled?

ventoo’s picture

ventoo commented

Yes, no change with FCK disabled: Actions/Triggers works as expected for unpublishing *Comments* containing defined keywords but NOT for Posts.

Disabling FCK does make the workaround for the minor problem with Comments (first and last defined keywords being ignored) unnecessary....but at the loss of the editor! Actually, I ended up excluding the use of the Fckeditor for the fields in which one defines keywords. Fckeditor of course isn't needed there anyway.

So everything works as desired for filtering user Comments but not for Posts (including Blog posts).

WorldFallz’s picture

WorldFallz commented

Regarding #2: I have tested this on 2 d6 sites with page, story, and blog content types and cannot reproduce the problem. With a normal authenticated user the nodes are properly unpublished upon submission, with user 1 they are not and i would think that's by design (as user 1 should be able to publish anything).

Since the op has already decided to drop drupal, i'm not sure following up in this thread, at this point, is going to be productive.

For anyone else stumbling across this problem, the exact steps required to create the problem would be helpful. However, heather is correct-- posting to the proper issue queue is the best way to proceed.

===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz

ventoo’s picture

ventoo commented

Again for Comments, I'm finding that the "offending" Comments DO get unpublished, even for User 1. NOT deleted, but unpublished and viewable to User 1 and others with proper permissions.

I suspect that if you look at your "Recent log entries," you will see an Action listed that is setting the Blog entry (or other node) to unpublished. I'm even seeing that for Posts even though the Posts do not actually get unpublished (even for a normal authenticated user with minimum permissions). So Trigger/Action is reporting unpublishing even for Posts....but in the case of Posts setting the status of the Post to unpublished never actually happens.

heather’s picture

heather commented

the forums can be frustrating. i know worldfallz does alot of great work pointing people in the right direction. i find myself just pointing people to g.d.o. (groups.drupal.org) or the issues queue most times!

had i seen that other post i still would have posted the advice...

@worldfallz... i'm assuming good faith here- but i'd venture to guess posting a link to that person's plea for help, maybe it would incite emotional responses rather than solutions, and exacerbate the problem. what happens outside the thread isn't relevant, in a way, since this issue/concern may come up for someone searching the same topic. and threads can get dredged up years later. ( i think i remember writing a "plea for help" post in my early days, and it still gets posted to once in a while just to make me cringe.)

@ventoo... looks like your #2 is an issue and not a support request in that case- but a bug. to double check, in your case- i'd set up another test site, trim out any other modules you don't need to test this, and double check the error is reproduced. then, when you submit the issue, you can describe the exact environment, specific module versions, etc., set up so it can be tested. sounds like alot of work, but it's the path to a solution, i'd hope!

best of luck to you!