WordPress Upgrade Implications Tutorial

WordPress Upgrade Implications Tutorial

Yesterday we saw with WordPress Upgrade Follow Up Tutorial as shown below that WordPress has a great Export and Import plugin to help migrate data after you upgrade your WordPress version. By the way, it is worth noting with this, that two WordPress default Widgets are useful as sanity checks for how the data migration is going …

1. Archives and/or
2. Calendar

… particularly if you are like us, and publish once a day.

Anyway, it is now time, once you are happy with data migration to turn to the implications of a happy data migration which is one where the default permalink “?p=[postId]” is equivalent for old and new websites, but the new website also accepts “/%postname%/” permalinks (in our case). This means that, with care, instead of “/wordpress/” being in users’ URLs you can ease them into “/ITblog/” replacing that in their URLs. So why the trepidation, why the “with care” bit? Well, I’m not sure, to be honest, whether all this contravenes a fairly big search engine (SEO) sin of having duplicate data. I’m, of course, hoping that with the search engine view of the Blog Post titles having that extra (middle name) “James” in them, plus a different “/%postname%/” permalink URL associated with them (but unfortunately with the same content) whether this will be enough to potter along for a while with both WordPress versions, while all the teething issues are sorted out, or whether the data migration will cause grief at the search engines … am an optimist here, but will keep you posted on that. You may wonder, why don’t we just cut over … well, maybe, one day, but am sure it is a thing to ease into, rather than a snap decision, especially as the snap decision does not improve anything about the “duplicate content” doubt up at the search engines.

So, back at the matter at hand … considerations of what can improve once a good data migration is achieved. Here’s one we can think of. If you are an attentive reader at this blog you may know about the PHP code of recent-posts-2.php which was first talked about with WordPress Recent Post Image Primer Tutorial and last changed (and talked about first regarding that) with FFmpeg Image Optimization Primer Tutorial. Well, we changed the code as per this link because now wherever a URL has “/wordpress/” it can now be safely mapped to “/ITblog/” and be hooking into the new WordPress blog website that way, as reflected by zero.html

So over coming days recognising these functionality improvements could be the go (like, do we do some .htaccess work or rather what we lean towards now, some mapping amendments at the WordPress 3.0.3 index.php end of things?), and it occurs to us to leave several days (to try things out (perhaps on a MAMP local web server, first)) for WordPress Blog upgrade work, to facilitate the changeover methodically. In the meantime here is today’s functionality change.

Did you know?

With using permalink /%postname%/ it sets you, on a Linux web server, in particular, to think about URL uppercase/lowercase confusion. After all, it is natural that somebody will wonder, with a URL such as …

https://www.rjmprogramming.com.au/ITblog/swift-dictionaries-and-arrays-primer-tutorial/

… whether …

http://www.rjmprogramming.com.au/itblog/swift-dictionaries-and-arrays-primer-tutorial/

… or even …

http://www.rjmprogramming.com.au/ITBLOG/swift-dictionaries-and-arrays-primer-tutorial/

… would also work, and with Apache / mod_rewrite / .htaccess / httpd.conf considerations … yes, it is possible (as long as mod_rewrite is installed). Let’s look at the web server alternative to ITblog folder called itblog (gobsmacked Windows (perhaps ASP.Net web server) afficianados cannot have this differentiation but also don’t have the issue to worry about in the first place … here’s the HTML a element information from w3schools in lowercase and (bits of) uppercase (with its URL) … anyone for a bit of I.T. history?) and what that new web server folder needs to make this happen to have this extra “convenience” …

1. httpd.conf change (for us, here, because we only allow .htaccess functionality, on a folder by folder decision basis … changes to httpd.conf need an Apache restart to happen, but a change to .htaccess should not need such a restart for the change to take effect)
   
<Directory [path to new itblog directory]>
# ... other directives...
AllowOverride All
</Directory>

2. .htaccess (in new itblog directory … chmod 644 … in large part, the same as WordPress installation’s .htaccess file created in the ITblog directory)
   
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /itblog/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /ITblog/index.php [L]
</IfModule>
# END WordPress
3. index.html (in new itblog directory)
   
<html> <body onload=" location.href = document.URL.replace('/itblog', '/ITblog'); "> </body> </html>

4. index.php (in new itblog directory)
   
<?php header("Location: ../ITblog/index.php?" . $_SERVER['QUERY_STRING']); ?>


… meaning that a misspelled URL with “/itblog” (which is quite understandable) should function the same as the “/ITblog” version.

Previous relevant WordPress Upgrade Follow Up Tutorial is shown below.

WordPress Upgrade Follow Up Tutorial

WordPress has a great Export and Import plugin to help migrate data after you upgrade your WordPress version, perhaps.

This came to the fore yesterday when we started (there is a lot more to do) on that migration path going from WordPress version 3.0.3 to version 4.1.1 as you can read a bit about with WordPress Upgrade Primer Tutorial as shown below.

So the two parts to the Export and Import equation are …

1. Export from WordPress 3.0.3
2. Import into WordPress 4.1.1

… now you may naively think that you will be able to export once and import once, but various things may get in your way achieving that …

1. the small settings for max_execution_time (eg. 30 should be temporarily 360) and max_input_time (eg. 60 should be temporarily 120) and memory_limit (eg. 70M should be temporarily 128M) in php.ini need to suit the memory requirements needed to create the Export file you upload to the live server
2. even fixing requirement for step 1 you may (or the symptom of needing to do something as advised in step 1), as you Export, get the PHP error message “Fatal error: Maximum execution time of ? seconds exceeded in …” … where ? was 30 for us here … this error message will appear in the last line of the Export file so
   tail -2 wordpress.2014-04-01.2014-07-01.xml
   would have been a Linux programmatical way of checking for the scenario shown a bit below
3. the small settings for upload_max_filesize (eg. 2M should be temporarily 32M) and post_max_size (eg. 8M should be temporarily 32M) in php.ini need to suit the size of the Import file you upload to the live server
4. even fixing requirement for step 3 you may (or the symptom of needing to do something as advised in step 3), as you Import, get the PHP error message “Fatal Error: Allowed Memory Size of ? Bytes Exhausted” … where ? is a fairly big number … and this error message may show on your web page window

So it is probably better to do this job in chunks. We think if there is a blog posting each day a three month span (or perhaps one month span) of Export could be good if comments are included as well. And how to exclude the comments? Supposing your Start Date is April 2014 and End Date is June 2014 then, at Linux …


$ cat wordpress.2014-04-01.2014-07-01.xml | sed '/^[ \t]*<wp:comment>/s//<wp:comment>/g' | sed '/^[ \t]*<\/wp:comment>/s//<\/wp:comment>/g' > xwordpress.2014-04-01.2014-07-01.xml
$ cat xwordpress.2014-04-01.2014-07-01.xml | awk '/<wp:comment>/,/<\/wp:comment>/' > comment_2014_4.xml
$ comm -23 xwordpress.2014-04-01.2014-07-01.xml comment_2014_4.xml > no_comment_2014_4.xml


… would result in a suitable no_comment_2014_4.xml to Import into the WordPress MySql database. We thank this link and this link and this link.

More WordPress upgrade information tomorrow. Thanks for reading.

WordPress Upgrade Primer Tutorial

It’s early days, and there is more to be done, but here at this WordPress blog we’re transitioning to version 4.1.1 from 3.0.3

Three major decisions involved …

1. Do I keep the same theme?
   • This one depends a bit, and we feel the answer stems from how you go piecing together on a local MAMP web server, for the MacBook Pro example, and how long you think it would take to transition in a change of theme. With this upgrade we tinkered with themes Twenty Fourteen, Twenty Thirteen and Twenty Fifteen with degrading success, and plumped instead to reinstall our previous theme Twenty Ten. Think it was a good decision, as if you are sticking with WordPress default themes, Twenty Ten is still a good theme in my opinion. Of course, you may have your own theme you like in mind and then you should invest the hours it will take to transition all the styling changes inherent in a shift of theme.
2. Do I change the permalink arrangement?
• In our previous WordPress blog we were using the default “?p=[postId]” arrangement which the search engines do not like … and you can understand why, in that to glean the best categorization of a webpage’s content gist, the search engines have to parse the whole page, whereas a permalink arrangement such as …
  
/%postname%/

  teamed up with a meaningful title, can tell a search engine so much about the webpage content just from its URL. So we went ahead and tried for the best option we’d read about, as above, and it all worked well at MAMP but getting to the live server we needed the great advice of this link from a WordPress forum, and it panned out for us that the WordPress install was doing everything right as far as its “.htaccess” file was concerned, but in our “httpd.conf” Apache configuration file we needed to specify …
  
<Directory [path to new WordPress document root directory]>
# ... other directives...
AllowOverride All
</Directory>

  to make things better
3. Do I filter comments more?
   • Definitely that would be good, and the great choice is between the Akismet plugin and Captcha option, or both, and as we suspected, we think more people like Akismet here, and I’ve always liked it more too, because Captcha excludes some users from ever accessing your blog. Akismet was already installed with WordPress, and activation for a personal blog like this one just involves getting an API_KEY from Akismet … so thanks a lot.

As you may imagine, this is an ongoing story, with more twists and turns to come. Hope you’ll join us for more information into the future, and hope to see you back at the new blog soon.

If this was interesting you may be interested in this too.

If this was interesting you may be interested in this too.

If this was interesting you may be interested in this too.