Archive for the ‘wordpress’ Category
Blog Conversions to WordPress
We decided to convert the blogs on our other commercial sites from Blogger to WordPress, and have done nearly 10 conversions including several clients, as well. The experience of exporting Blogger content presents a series of technical challenges getting everything converted and properly imported into WordPress.
The reason for moving from Blogger to WordPress is that our blogs and many for our clients were self hosted and published through Blogger via ftp. Blogger announced earlier this year that ftp publishing support was being discontinued (first date was March but extended to May 1, 2010). To maintain better control our advice was moving to the WordPress platform.
WordPress and Blogger are different. Blogger uses labels instead of categories, plus may truncate file names sometimes dropping words like “the” or “and” in favor of mostly key words from the blog post title. In addition, redirects from the old file names for labels, archives, and some posts were needed for the new WordPress version to avoid page not found errors.
Based on our experience and the desire for maximum control of site content, our first choice for new blogs will continue to be WordPress in the future.
WordPress Attack Requires Upgrade
If you own or manage an older version of a WordPress driven website or blog, the team at WordPress warns you MUST upgrade to the most recent version v2.84 because of a SERIOUS security threat taking place now.
In the announcement WordPress warns readers to upgrade immediately before reading their complete post it is that serious. Consider this comment from the official WordPress post linked above about upgrading:
If you are using a WordPress version after 2.7, the nag screen on the WordPress Administration Panels will alert you to upgrade. If you are using an older version, upgrade now. Don’t know what version you are using? Without a nag screen to tell you to update, you’re using an old version. Checking the Administration Panels footer will help, but don’t waste time looking. Just update now!
For our clients who have a custom WordPress blog designed and managed by us, your blog is not affected! Rest assured your WordPress installation was already at v2.84 before this virus attack began. In addition, we use automatic dBase backups as added security to avoid any recovery problems if needed in the future.
Invalid XHTML Blog Mystery
After converting a client’s blog from Blogger to WordPress recently an invalid xhtml blog mystery was uncovered. The blog home had 88 xhtml errors due to an invalid reference to class=msonormal in the code when validated to W3C. Two years ago the custom Blogger template and css styling that was created did not have that class defined, so how the code was inserted into the content required a closer look to solve the mystery.
While testing the WordPress blog with all posts imported from Blogger it was discovered the xhtml code errors were the result of the class=msonormal showing up in just two posts that the customer had published. The custom tutorial that was provided for creating and publishing posts in the original design was very specific about writing drafts in plain text with NotePad and using copy/paste to publish in Blogger.
The code errors were introduced in Blogger and imported into WordPress because the client wrote those two out of all their posts in MicroSoft Word. The problem with composing blog posts with word processing software like Word or WordPerfect is they create content in machine code that only looks like plain text. They may retain formats that are hidden and then show up when the post is published.
The solution to the invalid xhtml blog mystery of the class=msonormal code errors was to copy and paste the post from html view into NotePad, and then edit. In addition, the Word format inserted empty paragraphs with opening and closing p tags between paragraphs, so those and the reference to the class=msonormal were removed.
Finally, the last step was using copy/paste of the text from NotePad back into the WordPress post edit screen, and then republish. This easy solution using plain text removed the hidden formatting and the home page tested valid to W3C without any of those 88 xhtml code errors.