Recently a staff member was updating a WordPress post by editing the post code. As soon as any edit was made and saved, the post lost all the <select> and <option> tags associated with a form (see before and after screen shots). The staff member had Editor level status.
During the troubleshooting, we have attempted to (1) modify the Editor capabilities, (2) change Editor to Administrator, and (3) create a new Administrator account. Further, we are editing in HTML rather than Visual. In all three cases we continue to have the same problem with code being stripped out. What will work is using the original site Administrator account, and creator of the post, to edit the post. It will then save correctly. This is the puzzle: why does it work correctly for one administrator but not the other?
We are currently have three sites on WordPress 3.1.2 with three sites operating. This particular site has the following plugins: All in One SEO Pack; Disqus Comment System; fbLikeButton; Google Analyticator; Jetpack by WordPress; Peter's Post Notes; Sociable; Wapple Architect; WordPress Breadcrumbs; WordPress Post Tabs; WP-DBManager; WP-reCAPTCHA; and Yoast Breadcrumbs.
UPDATED: Found another active plugin at the network level (so didn't appear in the site level plugin list): User Role Editor. Could have a role (no pun intended) in the problem.
I am stuck and hope for insight from the collective wisdom.
#miscjoy #wordpress #plugins #technology
Google+: View post on Google+
14 responses to “WordPress Strips Basic Code”
You might try looking at the server file kses.php under wp-includes, which lists all the allowable tags. On my server, select and option are not included, so presumably one would have to add or override those settings in order to be able to use them in forms within WP pages. But that wouldn't explain why one level of user permissions was able to add the tags and one wasn't, a definite mystery.
Here's a one possible workaround: http://www.dbuggr.com/smallwei/update-change-list-allowed-html-tags-wordpress-default/
Kenley, are you using a multi-author role-based plugin, as well?
The list of plugins above are the currently active ones on this site.
Now this is interesting. There is something called User Role Editor under the Users menu. It appears to be a plugin, but doesn’t appear in the plugin list. Hmmm.
I use the Role Manager plugin for our multi-site WordPress (3.2.1) site at Pollak Library, to define and assign a handful of different levels of permissions for our staff:
I haven’t run into the the problem you mention, as long as I have enabled HTML editing capability to the right permissions group. So, sorry, I can’t really offer insight on how the out-of-the-box WP multi-site handles HTML editing for default roles.
I’d suggest disabling a cache plugin, and attempting this again…but, you’re not using a cacheing plugin, so I’m stumped on this one.
Perhaps it’s a Network-wide plugin, activated for multi-site, that just doesn’t show up as a plugin for each child site? That’s really odd, though.
Let us know if these tips help. I'm really curious about what could be causing this.
You have Jetpack installed – do the affected users have Proofread enabled in their profile? That would cause the post content to pass through at least one other system with the potential for problems.
+JD Thomas – the Proofread option was a good lead, but that wasn't it either. Darn. I did some further snooping and found a network level plugin that didn't appear in the site level plugin list. It's called User Role Editor and I'm thinking that could be something.
Even if I change user to admin or create a new account as admin, they still have same problem. It's damn weird.
Kenley, I did note in the link I posted yesterday that apparently Admin users have access to all html tags, while all other users are restricted to a subset of tags, and presumably those specified by that kses.php file on the server, so you might try doing a quick edit of that file to add the select and option tags and see if they're then available to those with Editor privileges or not, you can always back out the edits quickly.
Have you ruled out plugins entirely by renaming your plugins folder (then visiting the plugins Dashboard page so they get disabled) and then trying the edit?
If it is a production site you may need to stay up late, but at least that would kill off a bunch of false leads if the problem persists with every plugin disabled.
Sounds like night or weekend work. That's the next step.
Looks like some late night work for me so I don’t disrupt our regular services. It’s quite puzzling.