Posts tagged as:

plugins

Most of you can likely ignore this post; it primarily exists so that I can easily check whether or not WordPress (or plugins or whatever) is properly handling code. The source of the code is linked to below if you’re involved at all with WordPress testing / development. To everyone else, well, thanks for stopping by for this one. :-)

Moving right along…

The following is meant to test WordPress’ handling of code posted via the Visual Editor.

Instructions

  • Copy the contents of example.txt
  • In the Write Post screen of WordPress, switch to the HTML view (required as we are pasting in direct HTML).
  • Paste the previously copied contents into the post.
  • Switch back to the Visual Editor — everything should look as it is meant to regarding spacing, characters, and so on.
  • Save the post (publishing it is unnecessary) or let it auto-save, and then preview it.
  • Go down through the examples, checking WordPress’ work.

Examples

Basic HTML: <a href="http://example.tld/?foo=1&bar=2">Link's Text</a>
Explanation: Angle brackets & ampersands should be output to the browser as encoded entities; single & double quotes should not be made curly.

Basic entities: ... -- --- " ' & < >
Explanation: The characters should be directly output to the browser (or encoded for such output, as in the case of the ampersand). Three dots should not be made into an ellipsis; double and triple dashes should not be converted into en or em dashes; quotes should not be made curly; ampersands and angle brackets should be encoded to maintain (X)HTML validity.

Block example (PRE tag wrapping our CODE tag):

<a href="http://example.tld/?foo=1&bar=2">Link's Text</a>

	...    --    ---    "    '    &    <    >

As above in the HTML & entities examples, all quotes and symbols should appear properly, as they do when seen via the Visual Editor. In the three blank lines, tabs should be preserved (2 in the first blank line, then 3, then 2 again). Prior to the final line of characters, a tab should be preserved. Lastly, between each character example in the final line, four ordinary spaces should be preserved.

Finally, here are the examples again marked up using shortcodes in order to test such plugins (if you do not have a [ code ] shortcode enabled, ignore the following:

Basic HTML: <a href="http://example.tld/?foo=1&bar=2">Link's Text</a>

Basic entities: ... -- --- " ' & < >

Block example (PRE tag wrapping our CODE tag). Disclosure: For this final example, I am not using a [ pre ] shortcode; the Visual Editor does not recognize text wrapped in [ pre ] tags as preformatted, and so it strips out linebreaks and tabs. However, the Visual Editor provides an easy enough means of making text preformatted, so I’m using the PRE HTML tag in this final example:

<a href="http://example.tld/?foo=1&bar=2">Link's Text</a> 		 		

	...    --    ---    "    '    &    <    >

Popularity: 33%

{ 2 comments }

WordPress 2.5 & Bad Behavior 2.0.x

by Rick on March 25, 2008

If you are a Bad Behavior user, upgrade to version 2.0.14, and you won’t have to worry about WordPress 2.5 compatibility problems. Also on another note, if you have a high-traffic site, Bad Behavior may not be right for you. It might have been my imagination, but I noticed a slight increase in site responsiveness when I disabled Bad Behavior here back when I first learned it had issues with WordPress 2.5. (Additionally, FYI, I noticed a ginormous increase in site responsiveness when I disabled the Text Link Ads plugin!)

Bad Behavior in the Blogosphere

Like probably most early adopters and testers of the beautiful1 2.5 version for WordPress, I’ve had a lot of fun checking out what’s new, what’s different, and all of that.

I was particularly excited to try out the new interface for uploading media, which I didn’t have to wait long to do, due to the convention of having a graphic to head each post.

So I chose a picture and attempted to upload.

Then it happened; I apparently had killed the Intarwebs, and WordPress started complaining about “403 Forbidden” errors which neither carried with them any explanation or even showed up in my server’s error logs.

Crap, now what? So I trekked off to the WordPress testers mailing list and sought the help of the experts, and I was promptly taught the ways of tracking down media manager debug information by Andy Skelton (thanks again!).2

And I stared long and hard at that debug information. Something in that smattering of code and status information was the answer to my problem. I compared file requests, file names, and user-agents between the debug code and my server logs.

Then it occurred to me: the uploader is using the user-agent “Shockwave Flash”; could that be the problem?

I scanned the list of blocked user-agents active on my server — it wasn’t listed. Just to be safe, though, I removed the blocks and tried again. Still nothing.

Finally I decided to do what I should have done to begin with — deactivate all of my plugins and try again. So I did, and uploading worked! Hmm, a plugin was at fault the whole time, and it didn’t take much to narrow it down. Upon glancing at the list, I remembered that Bad Behavior3 had a user-agent blacklist.

So I opened up /wp-content/plugins/Bad-Behavior/bad-behavior/blacklist.inc.php and started scanning. Not too far down at all I came across this bit of code:

$bb2_spambots_0 = array(
[snip]
"PussyCat ",		// misc comment spam
"PycURL",		// misc comment spam
"Shockwave Flash",	// spam harvester
"TrackBack/",		// trackback spam
"user",			// suspicious harvester
[snip]
);

There it was!4 Removing the “Shockwave Flash” line allowed the new WordPress media manager to function properly.

Hopefully putting this out into the blogosphere will keep anyone else from re-sending to the Testers email or posting to a WordPress bug report about this issue. It’s an easy fix that anyone can do. :-)

Popularity: 30%

  1. Specifically the new admin interface! []
  2. If you want to enable debugging in the media manager, open the file /wp-admin/includes/media.php, and replace debug: false with debug: true. Revisit the media manager to see the debugging in action; revert the change to turn debugging off again. []
  3. A great plugin for stopping possibly malicious users from ever even reaching your site. []
  4. The actual line # within the file was 41. []

{ 13 comments }