DIV id's being stripped out .... any ideas?

We have users (administrators) that have pages that are breaking when they save them. It turns out that DIV ID's are being stripped out when they save, this is happens in visual or html mode and whether or not they switch back and forth from visual to html, it occurs with the visual editor disabled as well. This also occurs with revisions, they are unable to restore older working versions of the page because those too will have the Div's stripped out.

As a super admin this does not occur for me, but when I create a new administrator for an account I can reproduce the error, so it is clearly related to permissions, it does not affect super admins....

Has anyone else experienced this? Anyone have any ideas?

Any feedback appreciated!


    Is it happening with just one example of code or many? Can you provide an example of what they're trying to add in along with a link to a post where y we can see what's being stripped?

    One thing that comes to mind is the html tag order being incorrect. For example, something like the following:


    I recall wordpress choking on that but it's been a while since that's come up.


    It happens to every DIV ID, every time... it's consistent, unless you're a super admin, then there's no problems.

    I can create a page with the following and the ID will be stripped
    <div id="cheese">TEST</div>

    I've tried removing unfiltered-mu for no good reason to see if that might be related to no avail....


    No, fancy double quotes. Some editors like MS Word, instead of using the normal double quotes that look like the normal lowercase L characters, use what looks like actual quote marks. Like the first two examples here:


    Wordpress is supposed to either strip those out or replace them with the more web correct two lowercase L marks.

    I;m wondering if this is a bug. You're not copying and pasting this from somewhere, are you?


    I see what you're saying, nope.... I'm just typing directly from my keyboard. Wonder if anyone else can reproduce this when they are NOT using a super admin login? That's the confusing thing, I kept trying to reproduce with super admin login to no avail and was like "whuuuuuuuuuut?" and then sure enough, after logging in as normal admin, was able to reproduce error.... even when restoring revisions with ID's, those are stripped.... that's pretty crazy, haven't seen that before.


    Hey guys, divs are not on the built in whitelist for allowed tags unless you have the "unfiltered_html" privilege. They are stripped just like script and embeds, and as far as I recall it's always been that way in WPMU.

    What is different is that in WP 3.0 Multisite Superadmins now have the "unfiltered_html" privilege, which in WPMU they didn't. I applaud that change personally.

    If you want to allow the div tag you will have to use our "Additional Tags" plugin. Adjust the array in there appropriately, you don't want to allow everything!


    First of all, thanks for your help guys and Aaron, I greatly appreciate your input to clarify this, thank you.

    I totally failed to mention we're using MU Unfiltered.... I removed it to see if it could be the cause thinking ID's were allowed without it and came to the wrong conclusion it wasn't related to the issue when ID's were still stripped out without it....It looks like it was the issue as it doesn't seem to be working in 3.0 (http://wordpress.org/support/topic/413974?replies=3) ....

    We have removed MU Unfiltered and installed Additional Tags and ID's are still stripped out.... Is there anything else we need to add to the Additional Tags plugin to mimic the behavior of MU Unfiltered? Classes are not stripped out, btw and it looks like the plugin is supposed to allow ID's by default based on a quick peak at it, but they aren't being allowed....


    Updated with some much needed TLC:

    1.1.0 - 07/13/2010 - Aaron Edwards
    - WP 3.0 compatibility
    - Ability to allow additional tags for supporters only via Super Admin -> Options
    - Removed default adding tags to allowed list for comments. Can be re-enabled via define in plugin header
    - Update Notifications support