Today, I noticed that it is no longer required to escape the backslash (\), known as the “escape character” on *nix systems, inside the pre HTML tag in order not to be removed by WordPress’ HTML filters. This bug has lived long enough to be considered as a WordPress feature, but the devs have suddenly decided to address it. So, no more pain when using the escape character inside pre tags. Good!! But, what happens to the code that has already been published with escaped backslashes? WordPress is one of those free software projects which leave some really difficult homework to their users from time to time. So, here follows my solution.
After you have upgraded to the latest WordPress version, 2.3.1 at the time of writing, create a dump of your WordPress database:
mysqldump -u wpuser -p --opt --databases mywpdb > mywpdb.sql
After the database has been dumped, those backslash pairs in your posts’ data would appear as four (4) backslashes in the MySQL database dump. This is because this file contains the raw strings of your data.
To get an idea about what a raw string is, launch the python interpreter and test the following:
>>> "string with escaped backslash \\" 'string with escaped backslash \\' >>> r"raw string with escaped backslash \\" 'raw string with escaped backslash \\\\'
All the above python-thing is not required at all, but it is good to know what really happens. As you can see, the escaped backslash is represented by four backslashes in the raw string and this is how it has been written by mysqldump in the mywpdb.sql file.
All you have to do in order to repair all that code, while leaving all non-escaped backslashes in place, is to use a good text-stream editor, like sed in the way presented below.
Assuming that you have kept a backup of the dump, use sed to repair it in-place:
sed -i 's/\\\\/\\/g' mywpdb.sql
You can now import the repaired dump back into the MySQL server and replace your data with the corrected one.
mysql -u wpuser -p mywpdb < mywpdb.sql
Your previously escaped backslashes should now appear as single backslashes in your posts, but displayed correctly by WordPress.
I haven’t noticed any problems after performing the above operation. It might not work for you though. Use at your own risk.
If I miss anything, please let me know.
Backslashes inside pre HTML tags in WordPress by George Notaras is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Copyright © 2007 - Some Rights Reserved
There are some free software projects which value their user’s data, and backwards compatibility. Whenever an incompatible change is made, they provide one or more of:
A documented upgrade process
The option to disable the new feature
A transition period, in a “stable” branch, for those who cannot go through the pains of the upgrade today, but can do it later.
That takes a lot of work, but maybe a similar development model can help WordPress too :)
You are absolutely right. I have changed the phrase I had written initially as its meaning was very general and I did not like it either.
Old phrase:
Replacement:
This is one of the numerous times in the history of wordpress that a change is not accompanied by a maintenance script or other means of adapting the already published work to the new wordpress standards. I believe that this is part of the wordpress developer community’s mentality. They want to create something good, but they absolutely do not care about backwards compatibility. They somehow know/believe that WP will not lose its user base. This is probably true as the community of the users might complain for a week or maybe two about an inconvenience, but it will eventually get over it and continue to use the web application.
I really doubt that FreeBSD’s target audience’s mentality is anywhere near that. FreeBSD primarily provides solutions to the corporate world or to users with deeper knowledge of computing. What you have described in your comment is the professional approach. I agree 100% that a similar development model would be a significant benefit to wordpress as it would provide some assurance to publishers who would wish to use it as a content management system and not just a blogging platform.
Thanks a lot for your comment :)
Fantastic. I didn’t really want to *change* anything in the original text, but that’s great :-)
As long as the text was admittedly unfair for many open-source projects, there would be no point in keeping it that way. :-)
I never know, that this problem will occur with current version of WP,
but your help is highly appreciated, successfully implemented. Thnx!