changing allowed HTML tags doesn't stick

Just want to confirm this bug.

As a workaround I replaced the file modules/filter/filter.module with its 5.5 version,
then added the needed tags to the list of allowed tags and replaced that file with its 5.6 version again.

Confirming. Seems that this was caused by Inconsistent behavior with filtered tags, a bux fix for drupal 6 that was backported to drupal 5.

There are two separate bugs in filter.module here:

- The submit function 'filter_admin_configure_submit' (line 619) is never called, because line 608 of the form building function 'filter_admin_configure' is wrong. It's
$form['#submit'][] = 'filter_admin_configure_submit';
while it should be
$form['#submit']['filter_admin_configure_submit'] = array();

- But even if you correct this line, the system variables are not saved. I found in this page that if you use submit functions in a system settings form, there is no automatic processing of the variables. I tested it: it's true! Maybe this has changed in drupal 6, and that's why the problem wasn't noticed?

Hmm, obviously I backported from 6 while forgetting the change in the FAPI syntax. Things have indeed changed between 5.x and 6.x in terms of the removal of the #base element from FAPI and its use in system_settings_form(). It's too bad that this got incorporated in 5.6 before anyone noticed it.

The attached patch I just tested and seems to solve the problem.

Tested #3, fixes the form saving issue, but the filter cache doesn't appear to be clearing...

@webernet: the cache-clearing call is the same as in function filter_admin_delete_submit() - does that one work?

I haven't had to edit the tags in Filtered HTML in a while, until today, when I had to do it (add a blockquote) and it wasn't working.

Anyway, the patch in #3 does solve the editing issue, in that you can add a tag to the list and the change is preserved.

But, as noted in #4, it doesn't seem to make a difference even after re-editing and saving the node. I manually truncated my cache tables and it displays correctly, however.

doh - in one function $format is an object, in another it's an int. This one seems to work to clear the cache.

Cleary I need webernet to test my patches or I'm lost...

I tested this patch on the same install (after reverting the earlier patch) and it works fine. Invalidates the cache correctly, and saved values persist on the filter configuration form. Thanks, pwolanin and webernet: this makes my life much simpler today.

Looks good. Works fine.

Fixes the issue for me too.

thanks for fixing the problem!

I'm new to this and noticed the same bug. How can I apply a patch to my upgrade?

Thanks for the help.

http://drupal.org/patch/apply

I had a weird issue where this bug appeared only on one site, but not on another copy on a different server. No idea why, but with this patch it works great on both servers. Let's commit!

Patch in #7 works for me as well.

Thanks for the link but it wasn't much help for me.

I managed to get it to work though - I just opened the file, and then replaced lines showing "-" with lines having "+" :)

works great.

Thanks again!

Hi,

I'm not sure if this is even the same issue but I can't add any html to my content.

I have tried to manually apply the patch to filter.module (as I don't have a local copy or ssh access on my hosting) but it's still not fixing the issue.

I have a 'out of the box' install of drupal 5.6 and It has never allowed me to add html to my content whether I choose filtered or full. When i try to preview or submit content with html tags in or if I change the input format configuration I just get redirected to the root of my site (i.e it doesn't display the same page with an 'updated' message it takes me to the base url).

view and rearrange work but configure doesn't.

If anyone has any ideas or is willing to give me some help I would be sooo greatful.

Thanks.

+1 on the patch in #7
Worked for me.

@liamgoldstein: this sounds like a different issue. Suggest you open a forum topic http://drupal.org/node/add/forum/22 in the first instance, or a new bug report http://drupal.org/node/add/project-issue/drupal. It's may be something to do with your server configuration interacting with Drupal in a peculiar way.

#7 patch worked, even I had to modify the file by hand (damn patch utility for windows did not patch anything...).
Now I can finally use windows live writer to post my blogs with images (had to add the tag to allowed html tags).

If anyone else is having trouble getting patch to work on Windows, there may already be another and hence conflicting "patch" program/command on your system. See http://drupal.org/node/60182#comment-634955

is there any kind of QA .. even minor revisions constantly break things :/

+1 on patch in #7 - thanks very much!
: )

Hi,

#7 worked for me, too. Thanks a lot!

Confirming patch #7 worked for me as well. Many, many thanks.

patch #7 works for me too, thanks

+1 on patch in #7

thank you!

+1 on patch in #7 working

Thank you!

#7 patched worked on WAMP server, used cygwin to patch.
Thank you!

Modified to more-completely use Form API and committed to 5.x. Make sure to thoroughly test patches before submission in the future.

How do I apply the patch if I cannot get a command line in the server?

Is it really obvious?

http://drupal.org/node/212338#comment-698979

Alternatively, now that the patch has been committed, you will be able to use http://drupal.org/drupal-5.x-dev instead of 5.6. You may have to wait for a few hours for the dev version to be (automatically) updated - it's currently still showing last update as being on Jan 11.

[Update: http://drupal.org/drupal-5.x-dev now includes this patch]

If you can't apply a patch then it follows from gpk's last comment that you can simply grab the /modules/filter/filter.info and /modules/filter/filter.module from the extracted 5.x-dev and replace just these two files on your 5.6 /modules/filter directory. I just did it and works like a champ.