WordPress MU

When I add pictures to my posts via the TinyMCE and select either align left or right and a 1px border, the picture appears correctly aligned, BUT the 1px border is missing. I checked my stylesheet and the entries are there. When I check the source code, the class has been stripped out. I try manually entering the class in via the CODE tab, but when its saved, the class is stripped.

Is WPMu 1.2.2 stipping out class from IMG?

check the /wp-includes/kses.php file for allowed tags. You can always add in customized list for allowed tags with a mu-plugin.

Ahhh! I forgot about that. Yea, class was stripped out of img. In the kses.php on line 99, just add this after:

'class' => array(), 'class' => array(),

Reason this is important, for me anyways, is because it will validate as xHTML 1.0 strict.

Thanks kingler!

When did classes start getting stripped out with kses?

It's been recently, for sure.

Stripping out a class? I don't get it, not one bit.

What's next, id's?

Looking through it, the class attribute has been removed from all kinds of stuff.

Guess I'll have to remember to not upload a new kses then, and add it into my list of hacked/non-core files.

I use classes on all kinds of things. Granted, most of the bloggers don't, but I sure do.

About three weeks ago. Looks like he did a lot of work on the file.

I don't understand why the class would be stripped out? Was there a particular reason?

I'm with luna, I use class for a whole lot of things to make new theme implementation easier.

but the design of kses.php allows custom hacks easily. Simply put your own allowedtags as a kse-hack.php file in the mu-plugin. Donncha's changes are coming upstream from the WP development, so we'd better look at the WP trac instead for the history for this.

I cannot overstate what a disasterous change this is to Wordpress.

It basically completely removes microformats support from the platform.

Why would the WP devs make such a retrograde step? Do they realise the knock-on impact of this change? No hcard, no hreview, no hcalendar possible on any Wordpress blog.

I'll check the WP trac to try and figure out the reasons for doing this.

Hmm, those changes have been in main WP code for a very long time so I wonder is class implicitly accepted as we currently have no issues posting microformats markup to 2.1.x blogs. False alarm?

Conoro, this is how what happened. So I upgraded to 1.2.2, and went to edit an old page. The images I have were floated left & right with a border (i.e. class="img_left img-border") which works perfectly in the previous version (1.2.1). After I edited the page to take a section with a picture, I saved it and BAM, all my classes were stripped out. Thought it was a glitch, went back in and added all the class tags back and saved, BAM, stripped again. So I went back, added the tags again, switched to viewer and switched back to the code and they classes were once again stripped.

So I went to another domain that I had with a fresh Mu 1.2.2 install. Tried it with the default theme, the classes kept getting stripped out.

kingler: I realize that we can hack the kses, but I mean this is something that shouldn't need to be hacked. I mean next to IDs, classes are like the second most important thing. This is something, IMO, is a core thing and shouldn't necessitate hacking.

Exactly PQ. That's what I do with my images as well.

I have a class for a left float, a right float, etc. Ones for all kinds of stuff and whatnot as well, and not just for images.

I fully understand I can add hooks to it, but the thing is, for basic functionality like this I shouldn't have to.

I ran a compare (love that FileMerge) against the version of kses on my live site and the one in 1.2.2, and the only difference is the tag arrays and all the stuff being stripped out.

I can fully understand script, style, etc being taken out.

Let's look at just an anchor tag:

Before:

		'a' => array (
			'class' => array (),
			'href' => array (),
			'id' => array (),
			'title' => array (),
			'rel' => array (),
			'rev' => array (),
			'name' => array (),
			'target' => array()),

After:

		'a' => array(
			'href' => array(), 'title' => array(),
			'rel' => array(), 'rev' => array(),
			'name' => array()
			),

class, id, title, rev, and target were all removed.

I don't get it, really. Class and id were removed? That hurts because...

OK, an end user can sometimes turn out to be one of the lesser sharpened tools in the shed, but that being the case they probably don't have a clue about class or id anyway.

I haven't looked in depth yet to see, but doesn't inserting an image from your personal files associated with your account still add in an id tag? Just to have it stripped out.

I know. It sounds like I'm ranting, but I'm really not. I just don't comprehend the need for removing support for these.

That being said, I'll just keep using the kses file I have, and skip the new one. Problem solved.

I'm almost tempted to reviret back to the old kses...

That's what I'm doing.

Running a local compare showed no differences after the two arrays at the top that setup what is/isn't allowed.

You can put the old kses in a hack file in the mu-plugins folder. That is pretty what I am doing, and it is easy to add in new tags.

Yes, it is. But, again, I don't think that we should have to be doing it in the first place.

I have confirmed that WP 2.2 does not strip class or id but WPMU 2.1.2 does.

There has been no real change to the WP trunk of kses.php for several months so this looks like a regression rather than something intended.

However it is a huge problem for those of us who rely on microformats support in WP/WPMU/wp.com for many different reasons.

I hope this regression doesn't make it into the wp.com trunk.

I've opened a trac ticket for it. http://trac.mu.wordpress.org/ticket/357

Oh cool! I wanted to submit a ticket also, but didn't know how to.

I'm hoping this whole stripping thing was accidentally done and not intentional.

It seems the ticket is closed and the issue wont be fixed. I wonder why: class attributes are absolutely essential for microformats, useful as CSS hooks and completely safe.

If this isn't reverted then we'll have to dump WPMU as the platform for our reviewblogs.loudervoice.com site.

If this gets into the main trunk then the entire Wordpress platform is rendered useless for user-entered microformats.

BTW, Blogger just announced support for hAtom so they are heading in the opposite direction.

Looks like a Blog Post is required to highlight this. Ironically on a Wordpress blog.

I may also bring it up on the microformats mailing list.

Timing for OpenSource MT4 may be perfect......

My bad, I didn't see the responses to my ticket so they got no feedback from me. Updating them now and re-opening ticket.

"If this isn't reverted then we'll have to dump WPMU as the platform for our reviewblogs.loudervoice.com site."

:'-(

<roll eyes>

I would think this is an easy issue to resolve on the user admin level.

It's like if the tires aren't good enough on a Ferrari, your welcome to buy higher performance tires, not dump the entire Ferrari because the tires suck from the factory.

Of course there is the "it's open source, if you don't like it, change it yourself" argument that makes total sense but there is a much bigger issue here and that is the large degree of code commonality between WPMU and wordpress.com.

If this change makes it into wordpress.com then that's 1.2m blogs which cannot support user-entered microformats. This is something I (and many others) care very deeply about.

As far as the tyre analogy goes, if Lamborghini, Pagini and Bugatti all use Z-rated Pirellis but Ferrari starts using cross-ply whitewalls, then you have to stop and ask why?

Movable Type, Live Journal, TypePad, Blogger and wordpress.org all support user-entered microformats. WPMU did until the second last release. I doubt Six Apart and Google would leave themselves wide-open to major security holes for all these years.

We've been Wordpress and WPMU fanboys for a very long time and have converted many users of other platforms over to them. But as a minuscule unfunded start-up we genuinely don't have the resources to maintain and continually security test our own branch of WPMU. My talk of dumping WPMU is simply a reflection of that. If we have to use a less capable platform that supports microformats then that's what we'll do, very very reluctantly.

Then you obviously would rather whine about it, vice simply adding in a revised array with an mu-plugin or simply using the previous kses version which supports that.

Point being, you can't fault developers for reducing possible exploits. You, as an end user, have to option (and very easily in the case) to where you can make the change.

WP/MU/Automattic/WP.com aren't google, or anyone else. They will proceed with security measures to make their products safer to use. If that's a bad thing to you, feel free to customize it to fit your needs.

conoro, you make a good point, but my coworker has a saying: "Security and convenience is 180 degrees..." and I think the WP Devs are very concentrated on the security point at the moment. I don't agree with the class being stripped out, but at the very least, they made it easy to be *fixed*. I personally don't use WP.com, so I didn't mention anything, but I can understand people's frustration if classes were going to be stripped from WP.com.

At the same time, I think the classes won't be stripped out of WP.com. Since Donnacha is the only person developing WPMU, I think he gets to make calls like this, I could be wrong.

Donncha did post initially as to why it's taken out, and even pointed to a detailed explanation of the possible exploit. It doesn't necessarily affect just class, it's any possible attribute. Id, height, etc, and that it can be prematurely ended.

When it comes down to it, unless your MU install is a private collection of your own stuff, you don't know who's actually on the other end, nor what their intentions are. So, in cases like this, erring on the side of caution is the more logical approach from a developers point of view.

That being the case, it's not like it's a compiled program that you can't customize to your liking. If one doesn't have the capabilities to do so, then there are plenty of resources to either learn how, or hire a professional.

@peiqinglong - if it is a serious security problem surely Matt and the others at wp.com would be all over it 12 months ago when it was revealed?

I'll continue to believe this is a bug and not a feature until wp.com changes too.

@lunabyte - If absolute security is the aim and erring on the side of caution is the more logical approach then why doesn't WPMU simply ban HTML in blog posts just like Vox or Bebo?

Can you also tell me how I customise wp.com?

I have been maintaining a custom kses.php file for many months to allow for the use of class/id in tags like abbr. Up until now we've been able to work around the same issue on wp.com. We cannot work around the blanket banning of id/class.

I read the specific exploit info that Donncha pointed (and the original source) but can find nothing there or anywhere which shows class or id to be general security holes. There is a supposition that "well maybe somehow someone somewhere might create one using class/id" without any supporting examples but that brings us straight back to whether any html should be allowed.

I know Donncha and have enormous respect for him but that doesn't mean I won't pass comment on the direction of publicly released software, free or not, open source or not. Surely open debate on all software should be encouraged with the understanding that BDFL gets final call on everything? Or does all dissension rate as whining here?

WP.com != MU.

MU came first, then they customize to suit their needs. Which, is one of a hundred reasons you won't see most of their customizations in MU.

And only whining rates as whining, which it sounds like you're doing.

If you don't like their array(s), look right above it. It looks for a custom one first.

"if it is a serious security problem surely Matt and the others at wp.com would be all over it 12 months ago when it was revealed?"

See above. What they do there, after the fact, is whatever they want. Sometimes they are nice enough to share a little bit of the trivial stuff, but are in no means required to do so.

So no, it isn't a bug. It works as intended, and provides a hook for people who would like to customize it further. That's just the way it is.

Why WP works different, is that it's completely your blog. If you add an editor or an author, usually you know who they are and have an existing relationship where trust is involved.

With MU, it's designed so anyone can sign up by default. You don't know these people, and there is no existing relationship or trust. In general, of course, as there are exceptions to every rule.

So, debating it over and over is really pointless. If you don't like how something works out of the box, you have the power to change it.

Hi folks,

As far as I can tell, there's quite a bit of misapprehension afoot with regard to the variable width encoding exploit that has been given as the justification for the radical de-featuring via the latest kses.php. If I have understood correctly, the exploit doesn't just require carefully crafted nasty stuff inside an attribute. It also requires a spare unescaped/unentified double quote floating around somewhere else. (This was pointed out and acknowledged by the exploit's author on the very day it was published, in August 2006.) WordPress doesn't output those anyway, except within CODE tags -- and the older kses.php already prohibited any extra attributes within CODE tags.

Again, as far as I am aware, without both nasty stuff in attributes and spare double quotes, there is no attack vector.

In my book, it's no good telling people "that's just the way it is" and suggesting they should go fix it themselves if that's what they want, particularly when we are talking about a major reduction in end-user functionality that does not seem to be well justified by the reasons that have been given for it. (I know that the magical phrase 'security fix' makes it tempting to suspend critical thinking, but it really shouldn't...)

Ironically enough, both WordPress and WordPress MU currently ship with a kses.php that has been known to be buggy since April 2005. My suggestions: 1) adopt the fixed kses.php that is currently available, and 2) give users back their ability to style their posts in the accepted 21st century fashion.

More ramblings on the kses.php changes are available here:

http://whereelsetoputit.com/blog/restoring-lost-wordpress-functionality/

All the best,
Greg

"In my book, it's no good telling people "that's just the way it is" and suggesting they should go fix it themselves if that's what they want, particularly when we are talking about a major reduction in end-user functionality that does not seem to be well justified by the reasons that have been given for it. (I know that the magical phrase 'security fix' makes it tempting to suspend critical thinking, but it really shouldn't...)"

Sorry, but that's just the way it is currently.

All the bitching and repeated discussion on it is pointless until those in charge decide to change it.

They've said it was stripped for security, and left it at that. If they change it, fine, but until then the only way around it is to customize it yourself.

Sorry if you don't like how they run things, but most of us have adapted and accepted it.