Database restore needs some work

If you would please let me know exactly what was the problem you had with the database restoration I can help you.

We currently have a much better database data replacement solution than anything else written for WordPress. For example, Search and Replace (whose code I did study before writing my own solution) uses precarious regular expressions to perform the database changes. These do break serialised data in many circumstances, especially if the serialised data contains deeply nested arrays / objects.

I suspect that your problems have to do with the database encoding which is easy to work around. However, if all I’m given is a two star review and “needs work” I can’t help you. I can do many things, but read minds is not within my skillset ?? Please help me help you.

First issue: After many failed attempts to restore, I found that Akeeba Backup added an empty line to the bottom of my wp-config.php file causing a “header has already been called” error when trying to restore via Kickstart 4.0.0, making it impossible to get to my /wp-admin page and set the permalinks after the database restore. This was a major source of frustration.

When I finally did get it to where I thought the database restore worked, the results were corrupt. Copyright symbols and em dashes turned into diamonds… entire sections of the website did not appear (sidebar).

For Joomla Kickstart I always use the intuitive defaults (check boxes) and it works brilliantly. For WordPress I was hoping for the same. Maybe I need to un-check or check a box?

I appreciate your offer to help because as I stated before, I’m a die-hard Akeeba fan and would love to do away with my Duplicator and switch to Akeeba for WordPress, but I was really let down. I love your extension so much that I was trying to figure out how to still keep using Akeeba Worpdress, just without the database section (which is what I ended up doing to get it to work). Ultimately though, this won’t work for me in the long run and will prove to be more of a hassle than anything.

Happy to revise my review if you can come up with a solution. A glowing review is not out of the question.

Your issues are actually neither as grave as you present them nor impossible to work around. Let me explain in detail.

The empty line in wp-config.php. You have terminated your wp-config file with the closing PHP tag (?>). This is a bad practice, discouraged by the people who wrote the language. The closing tag is only required when terminating in-line code. When your .php file ends with a PHP block you must not put the closing tag. However, that’s easy for us to fix so thank you for pointing out that in 2015 there are still people doing what has been called a bad practice for a little over a decade ?? For your information, WordPress (at least since version 3.8 which is the oldest I have at hand now) does NOT end wp-config.php with a PHP closing tag.

Regarding the database restoration issues, as I thought, you have an encoding issue. It’s simple to fix. The third page of the restoration process is Site Setup. There are two fields there, Database charset and Database collation. You should use utf8 in the first and utf8_general_ci in the second. Unlike Joomla! which automatically forces the characset and collation to UTF8, WordPress doesn’t do that. If your new database doesn’t use the utf8_general_ci collation by default (most cPanel installations default to latin1_general_ci, for example) you get “funny characters”. This is actually how MySQL works and an oversight in WordPress (it’s 2015, even the Japanese, the last people using legacy charsets, have given up on legacy charsets and use Unicode in UTF-8 encoding…). It seems that most people don’t understand the importance of database collation, so we might have to force a default value there EVEN THOUGH the value read from your wp-config.php is an empty string. It’s an architecturally incorrect solution, but if the architecturally correct solution earns us two-star reviews…

TL;DR. Here’s what you can do right now and use Akeeba Backup just fine:
1. Get rid of that PHP closing tag in your wp-config.php
2. Remember to set the Database charset and Database collation OR create your database with utf8_general_ci encoding. Either way should work.

Try it out and please let me know how it works for you.

Will do Niko. FYI, I never added that php closing tag, as I don’t create wp-config files from scratch, I just edit the three effected values for installations (DB_NAME, DB_USER, DB_PASSWORD (DB_CHARSET (if needed))). That closing tag was there when I inherited this website. That is good info to know though.

On another note, does Akeeba regularly change php file code when compiling or restoring? The reason I ask is that I had an older Joomla website I used Akeeba for and found that the backups became unusable because extra lines of “empty code” had been added to many files throughout the site. Ultimately the website was old and a new one was needed, but it would be nice to have that website available for my portfolio, and at this point, I cannot install it without errors.

“It’s an architecturally incorrect solution, but if the architecturally correct solution earns us two-star reviews…” Quite a blunt statement lol. I understand your desire to keep your reviews clean and accurate. If the solutions you’ve suggested work, rest assured your review will be revised.

I’ll do as you’ve suggested and get back to you.

Probably another plugin (or another site integrator) added that line.

Regarding the restored files, Akeeba Backup NEVER, EVER modifies the contents of your .php files EXCEPT for the site configuration file (configuration.php in Joomla!, wp-config.php in WordPress). I can tell you why your files became corrupt: you’re using FTP and you have a Windows computer. Now I freaked you out. How can I possibly know that? Because it’s the only way empty lines can be added ?? Transferring files over FTP in ASCII file transfer mode converts line endings from LF (Linux, Mac OS X) to CR LF (Windows) and back. CR LF on Linux and Mac OS X is seen as a line followed by another empty line. Mystery solved. Always use FTP in Binary transfer mode.

Regarding the blunt statement, well, that’s the truth ?? I need to earn a living to continue writing software (it’s hard to write software when working 10 hours a day to almost make a living, trust me, I’ve tried it), which requires good reviews to convince enough people to pay for the Professional version. I value code architecture as much as the next guy but if that cleanliness has an adverse impact on being able to stay in business there’s not much of a choice. I do get your point of view, though. You expect things to Just Work?. And just like I do with all Joomla! shortcomings I’ll do the same with WP: code around them, even though I do understand it’s bad architecture. Between starving and being mocked by developers for “bad architecture” I’ll take the latter any day of the week. Blunt? Yep. The truth no developer wants to talk about? Absolutely.

Getting closer…

I entered utf8 and utf8_general_ci as suggested and the site installed, and I can even get to the /wp-admin page. But none of the images are showing up. So I ran the trusty interconnect/it DB S&R and there were all the db references not changed… about 1100 of them (I selected all tables in the last S&R Akeeba step, not just the WordPress core).

I’m uploading from my localhost XAMPP to a sub-directory on my live server (with an sub-domain pointing to it). When I use interconnect, all I have to do is localhost/site =(changed to)= site.domain.com and it works flawlessly.

1. Why did Akeeba miss all those references?
2. What is the “wp_” there for in the last S&R step, and is it needed (I left it there not wanting to screw things up; didn’t the db tables already get prepended with wp_ in the earlier step)?

1. In the replacement boxes you need a From entry reading localhost/site and a corresponding To entry reading site.domain.com While the restoration script tries to guess the replacements required it may not always get them correctly – it actually relies on your server giving it the correct URL information which may not always be the case.

2. I’m not sure what you’re referring to. A screenshot would be nice. I’ll have to reply based on what I guess you meant. If you see something like oldPrefix_ in the From columns and newPrefix_ in the To column (where oldPrefix_ is your old database table name prefix of the site you backed up and toPrefix_ is the new database table name prefix of the site you are restoring to) this is normal. WordPress stores the database table name prefix in several of its options. If you have a multisite installation this happens for both the master site and for each one of the children sites. The prefixes in the options do need to get changed or you’re losing some of your settings. Some third party database replacement solutions do that, some forget about it (they assume you’ll always be using the same database table name prefix when you move sites). I wanted to be sure we’re covering all bases.

I’ve already reinstalled so many times my fingers are bleeding. Please see below instead of a screenshot.

1. This is exactly what was entered (see line item a below). I removed line item b, but left line item c intact.

2. The default entries were:

line item a:
• left entry = localhost/site
• right entry = domain.com/folder/site (I changed this to site.domain.com)

line item b:
• left entry = /site
• right entry = /folder/site

line item c:
• left entry = (blank)
• right entry = wp__

Hopefully this helps.

Thank you for the details!

We’ve been able to reproduce the bug. We’re currently fixing it. Once it’s fixed we’ll publish a new release. The problem seems to be that the second line doesn’t have any effect.

We were not, however, able to reproduce the third issue, line c. I can’t understand where it’s coming from either. It’s not the database prefix, I made several tests without success (that’s why it took me so long to get back to you). However, it seems to have no bearing on the outcome you are experiencing so I think we’ll have to ignore it for now.