WordPress’s Pyethon trap

One of the most drudge-like tasks of writing a book is assembling the endnotes, but if there is anything even more tedious, it is converting those endnotes into HTML. But I promised readers of Dreaming in Code that I would do so — so many of the references are Web-based, it makes a lot of sense to provide them with working hyperlinks.

I’d hoped to have this done before the book was published, but I’ve only just finished. Ed Yourdon wanted me to do it; how could I let him down?

But in posting this material, I discovered something very odd. Sometimes WordPress simply did not want to upload a page (I’m using WordPress’s static page feature for the whole Dreaming in Code site). At first I thought I’d hit some undocumented limit on the number of characters, or maybe number of links, on the page; or, I thought, there’s so many links on these pages, maybe it’s overloading the cool WordPress pinging/trackback stuff, so I just turned all that off.

No go. Certain pages just would not save properly, the browser would just hang. By removing chunks of text I slowly zeroed in on the problem: three notes that contained the word “Python,” as in the programming language, were causing the trouble. If I removed them, no problem!

I just tried to post one of them here as an example and this instance of WordPress won’t allow it either — it generates a “file not found” message, oddly. A quick hunt through WordPress’s documentation “codex” offered no clue. Anyone have an idea? Is WordPress’s dedication to php so intense that it will not even allow a mention of the competition?

I couldn’t even use the word “Python” in the headline of this post — it caused the same error! I had to misspell the forbidden name in order to get this post to publish properly. Very odd.

UPDATE: Thanks to the commenters who pointed me to apache’s mod_security, which is plainly to blame, and not wordpress itself. A little creative escaping of the “P” in “Python” and I now have restored the previously unpostable endnotes. Live and learn…

Post Revisions:

There are no revisions for this post.

Comments

  1. Paul Brown says:

    Depending on who your hosting company is and/or how you have Apache configured, you may be experiencing a filter installed in Apache where it won’t permit potentially executable content in a POST. (Check out mod_security.)

  2. That makes a lot of sense, thanks, Paul. I figured it might be some sort of screen on executable content, but this does have the strange effect of banning the word “python” (let’s see if I can post it here…) from a lot of use. I wonder if there’s a way to escape it out, or something like that? (I know, I’m desperately hand-waving here!)

  3. Paul Brown says:

    You can use entities to enter the character codes of some of the letters, e.g., “p” is &112;. (Google’s first choice for ascii table is a good one if you need codes for more letters…)

  4. Andrew Brown says:

    Off the top of my head, you will have the same problem with “perl”, and possibly “bash”. That would be the diagnostic test for an executable filter. all of them might be preceded by “!#” to make a unix script which apache would not want uploaded.

    But what an unlikely little problem!

    (Did you get my piece about the book, btw?)

    http://technology.guardian.co.uk/opinion/story/0,,1992552,00.html if not.

  5. Firas says:

    It’s certifiably not a WordPress issue, and almost certainly mod_security.

Trackbacks

  1. [...] I’m delighted to report that the end-notes are now available; you can find them here. And you can find Scott’s amusing blog posting here, about the difficulties he had accomplishing this task. All of which demonstrates, in yet another small way, that software is hard. [...]

Post a comment