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 …
- Export from WordPress 3.0.3
- 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 …
- 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
- 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 - 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
- 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.
Previous relevant WordPress Upgrade Primer Tutorial is shown below.
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 …
- 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.
- 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 - 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.
21 Responses to WordPress Upgrade Follow Up Tutorial