nikosdion

Um, how did you even end up here? I mean, we delisted the plugin from the WordPress Plugin Directory in 2014. How did you even find this forum (which the Directory for some reason leaves open, but undiscoverable, after a plugin is delisted)?

Anyway.

Your problem is that the database tables were not installed when you enabled the plugin. Disable and uninstall the plugin, then retry installing and enabling it. Please do use the latest version of the plugin available from https://www.akeeba.com/download.html, not the decade-old version you will find in the Directory.

If the problem persists please check with your host that the database user has the correct privileges to create and drop tables in your site’s database. This is not a given with some “WordPress-optimized” hosts (which are rarely optimised for anything, but that’s another matter altogether).

First, um, how did you find this page? ?? We had delisted Akeeba Backup for WordPress from the directory since late 2015. I was quite surprised to see a new thread on what I thought was a forum archived years ago ??

In any case, if the problem is background images you should be looking at your CSS. It probably has absolute URLs like /wp-content/… (note the leading slash). If you are restoring in a subdirectory e.g. https://localhost/mysite these links are no longer valid as they now point to https://localhost/wp-content which is an invalid path.

The correct solution is to write your CSS with relative paths. For example, if your CSS file is in wp-content/themes/foobar/assets/css and your background images are in wp-content/backgrounds the URL in your CSS should read url(../../../../backgrounds/myimage.jpg) instead of url(/wp-content/backgrounds/myimage.jpg). This is how CSS, web browsers and web servers work.

Do remember that Akeeba Backup never modifies your CSS files. This has been true since its first Joomla days back in 2006. The reason is simple. We can’t be absolutely sure about what needs to be changed. It is possible to have a site which does use absolute URLs which resolve off-site and that’s intentional. There is no user-friendly way to convey that information so we chose to not do that kind of replacement and let you edit your files to use relative paths — as they should be all along to avoid problems even on your live site.

I hope that helps!

You’re welcome! I am glad I could help you!

PS: I was trying to tell you to do what you eventually tried. Trying to use the WP forums from 3G while on a ship (1.8 seconds ping!) is all sorts of fun ??

Hello Marco,

Sorry for the late reply. I am on vacations right now and I’m the only one who gets notified about posts on the WordPress forum because of the inefficient way it works. That’s why we don’t do support through the WordPress forums. Using our own site we have three people providing support with much less delay. Even when one of us is away, indisposed or otherwise unavailable there’s at least one other person being able to fill in the gap. But I digress.

I believe that the problem is due to an issue we have identified and currently working on addressing for our next release. For now, you can go to wp-admin, click on Akeeba Backup, System Configuration, click on the Update tab and set “Show Akeeba Backup for WordPress update in the Plugins page” to No. Click on Save and Close to apply this change. This should work around the issue you are experiencing. The next release will address this issue.

Yes, these are all Akeeba Backup tables. You can safely delete them from the database.

That said, they should have been removed automatically. Which version of Akeeba Backup did you have installed? Also, how did you uninstall it? Did you delete the folder or did you use WordPress’ Plugins page to uninstall it? Did you disable the plugin before uninstalling it? Thank you in advance for any pieces of information you can provide.

Thank you for the feedback.

Regarding the plugin page, I had checked soon after you told me it was unpublished and the notice wasn’t there (caching?). Now I can see it is. I apologize.

I still don’t understand why the reviews link in the (unpublished) plugin page is unclickable but the reviews themselves are available on the forum. It would stand to reason that once you unpublish a plugin all of the reviews and support requests are unpublished too.

Regarding the review, I consider any review that is contrary to objective reality to be false and I’m glad you agree. However, if you do not weed out lies like this it is very easy for developers to attack competitors and you’ll be none the wiser. I could just pay 10 Euros to random people with a www.ads-software.com account to write negative reviews filled with lies for competitors’ products. Falsehoods also “poison the well” for future users. No offense, but you should read some introductory books on behavioral psychology and neuroscience before you manage user reviews.

Also, about your assumptions. I do not assume that users –or you– are on the same technical level as me. If that was the case my software would not have a reason to exist. I’ve been developing backup software for ten years. I know exactly how inexperienced users are. I have a serious company, four strong, we do randomized user testing with an external UX company and we do take user feedback very seriously.

Regarding community spirit, you can look at the support requests I received and replied to. I tried to help people, for free, and even provided them with direct support on their own site. I even fixed issues that were not problems in my software.

What I got in return for my hard work was false reviews and a “screw you” by the directory. So please don’t lecture me on community spirit. Developers put all this time to make WordPress more useful to more people. What they expect in return is WordPress to protect them against the inevitable irrational people. Instead, you condone irrationality in user comments and talk down developers who protest that.

Speaking of which, you claim that my reply to that review was “over the top”. Someone openly attacked my professional ethos by accusing me that I hold their data ransom. That’s a blatant lie which, were it true, would make me a crook and possibly raise questions on legal action as you are very well aware. I had to make it abundantly clear that this is absolutely not the case if not for defending my professional ethos then certainly for legal reasons. I don’t consider it “rational” or “people skills” to accept unfounded accusations on my professional ethos. Apparently neither do you because you did send me an over the top reply with a bit of ad hominem attacks at the end when I insulted your professional ethos regarding your involvement in the WordPress plugin directory.

So, here’s my advice: Not all users are always right. Learn to deal with blatant lies like you should, instead of simply condoning their toxic behavior. There is always some real person on the other end of the plugin listing. Treat them as such.

That’s why I delisted the plugin from the WordPress Plugin Directory. When I contacted the directory team about this kind of obviously false reviews I was told, word for word, that “whether a plugin is free or not is the subjective user experience”. For this reason they wouldn’t remove these blatantly false reviews.

I even pointed out to them two cases where the user account was created minutes before filing two nearly identical negative reviews for two backup products (mine and another one) and right after that a very generic five star review for a competitive product. I was told very rudely that they know better than me to spot fake reviews.

It’s worth noting that you cannot list a paid plugin in the WordPress Plugin Directory. Therefore reviews claiming a plugin is paid can reasonably only have one of two results: a. the plugin is a fraud and must be removed from the directory; or b. the review is a blatant fake, it must be removed and the user who filed it blocked. Concluding that the plugin isn’t fake, the review is and doing nothing is amateurism at its finest.

Another display of gross amateurism by the WordPress Plugin Directory team is that delisting an extension doesn’t really delist the extension. It merely hides it from search results and blocks the developer from the SVN repository. If you have the URL you can still access the –now outdated– page. Google does have that URL, obviously, and won’t remove it since it still returns an HTTP 200 response and content! Any past reviews are still visible as part of the WordPress forum. Basically, any lies written by malicious, fake users remain forever and the developer can never get any redress from WordPress.

I’m glad I could help you!

We cache the result of WordPress’ get_current_user_id() in the PHP session. PHP saves the session ID in a cookie to your browser. The cookie is normally set per (sub)domain name and path. In some misconfigure servers it is possible that PHP can’t figure out the path to the site. For this reason we’re setting the path manually based on the plugin’s path returned by the core WordPress function plugins_url().

In extremely rare cases this URL may end up being wrong. This means that all your Akeeba Backup installations will share the same session, therefore the same WordPress user ID. However, the ID of the administrator user will be wrong for the second site you try to log in with the same browser.

The only solution I see is you clearing the cookies for your site before trying to access Akeeba Backup. If anyone can trace how plugins_url() works and figure out if there is a wp-config.php define you can modify that’d be great. Unfortunately I’m not on a computer with WP installed right now so I can’t check it myself ??

Not only it is designed to indeed transfer from any domain to another (be it localhost to live, live to live or live to localhost). Not only have I used it myself for this purpose. We even tell you in our video tutorial how to do it. However you need to keep in mind that:

1. Your target server MUST be compatible not only with WordPress but also all the plugins you have installed. If you have a different version of PHP or you are missing some PHP extensions required by the plugins you installed on your site then of course they will not work. This is not a problem with the method of transferring your site, though!
2. The same applies for MySQL. If your source server uses a recent MySQL and PHP version which support utf8mb4 but your target server does not then of course you will end up with broken data. This is a problem with the server and how WordPress is coded, not the transfer method.
3. WordPress and its plugins do store data in serialised form. While our solution is the ONLY one to replace them it is not always possible to have an accurate replacement, especially if you are transferring between different directories or using plugins which store double encoded data (e.g. some WooTheme themes – huge bug, never fixed, that’s why they offer an export and import of the theme’s settings)

I am pretty sure that if you do try transferring the site manually between the same servers you will observe the same issues. Does that mean that you are horrid at transferring sites and we should call you meowgrnightmare instead?

It has to do with a change in WordPress 4.2.0 and later.

WordPress automatically upgrades your database tables to UTF8MB4 (UTF-8 Multibyte) if your MySQL version supports it. Here’s the thing: not all versions of MySQL and not all versions of PHP support it. If you have the same PHP and MySQL version as someone else it might also NOT be supported because of MySQL library versions which is an entirely different beast.

Long story cut short: some servers support UTF8MB4 and some do not. Those who do not only support the old, plain UTF8 character encoding method. But how does that affect you?

If you backup FROM UTF8 and restore TO UTF8: Works.
If you backup FROM UTF8 and restore TO UTF8MB4: Works.
If you backup FROM UTF8MB4 and restore TO UTF8: Does NOT work.
If you backup FROM UTF8MB4 and restore TO UTF8MB4: Works.

Why is that? UTF8 can be upgraded to UTF8MB4. UTF8MB4 cannot be downgraded to UTF8. I guess that what happened in your case is that your source site is UTF8MB4 but your target site only supports the old UTF8 which is the only combination that cannot work for reasons that have to do with MySQL’s handling of data and how WordPress deals with the data encoding. In this case the only solution is upgrading your target host with a newer version of PHP and MySQL, sorry. It’s technically impossible for us to provide a different method in this case since the problem comes from UTF8MB4 being incompatible with UTF8 in the sense that you cannot downgrade from UTF8MB4 to UTF8.

Akeeba Backup CORE IS free of charge! Exactly as written in the description there are certain VERY SPECIFIC features WHICH YOU DO NOT NEED TO BACKUP, RESTORE AND TRANSFER YOUR SITE which are only available in the for-a-fee (paid) Akeeba Backup Professional version. Let me remind you EXACTY what I’ve written in the description:

START OF COMMERCIAL INFORMATION: THE FOLLOWING TWO PARAGRAPHS REFER TO WHAT YOU GET WHEN YOU PAY US (MONEY CHANGING HANDS INVOLVED)

If you want advanced features, such as uploading your backup archive to Amazon S3, Dropbox, Box.com and 40+ other cloud storage providers, import backups from S3, exclude files, folders and database tables using regular expressions, integrated restoration and much more you can subscribe to the commercial Akeeba Backup Professional for WordPress plugin on our site. Clarification: you need to pay us actual money to get access to cloud storage and the other features mentioned in this paragraph.

The plugin is free of charge, its support is not. You need a valid subscription on our site to request support. However its documentation, video tutorials, the troubleshooting wizard and searching the public tickets on our site is free of charge. Clarification: you need to pay us actual money to request support on our site (akeebabackup.com).

END OF COMMERCIAL INFORMATION.

Which part of it do you not understand? Did you find any, even ONE, of the features described OUTSIDE this block of text which is not ABSOLUTELY FREE OF CHARGE and available in Akeeba Backup CORE? Of course not. I know that because I bloody use it myself!

Seriously, I don’t know what else to do… I can’t teach you how to read and I can’t afford spending countless hours writing FREE OF CHARGE software only to get one star reviews from people like you who can’t be bothered reading a simple description.

I think your review is deceitful and unjustified. The EXACT wording in the plugin page is:

If you want advanced features, such as uploading your backup archive to Amazon S3, Dropbox, Box.com and 40+ other cloud storage providers, import backups from S3, exclude files, folders and database tables using regular expressions, integrated restoration and much more you can subscribe to the commercial Akeeba Backup Professional for WordPress plugin on our site.

So, yes sir, we did tell you that you need to pay for the cloud upload feature –if you’re unsure please look up the word “commercial” in the dictionary– but you just didn’t care to read it. Since the premise for your one star review is non-existent would you like to please remove your FALSE AND MISLEADING review? Thank you.

I beg your pardon? The restoration costs exactly ￡0. God forbid if we asked you to pay us to restore YOUR data. We’re not a hosted backup solution that charges you for data storage and restoration. You own your own data and I’d be damned if restoring it was not possible –?let alone that if you read the other reviews here you’ll see that these people actually restored their sites. You just need to use the free of charge Akeeba Kickstart software exactly as explained in the step by step video tutorial which is also available free of charge and linked to from inside the Manage Backups page of our software.

Also, three weeks ago we made a new version of Akeeba Kickstart available which makes restoration EVEN EASIER. Here’s the “difficult” steps you need to restore your site:
1. Download Akeeba Kickstart
2. Extract Akeeba Kickstart’s ZIP file and upload the kickstart.php to your site’s root
3. Visit its URL, e.g. https://www.example.com/kickstart.php
4. Navigate to the folder where you’ve stored your backups. Note that this is not pinned to a specific directory because a. the plugin’s directory name can be whatever you please and b. you can (and should have, assuming you read our documentation) change the backup output directory to a location of your liking.
5. Pick the backup archive you want to restore.
6. Click Start and sit back
7. Click Run The Installation
8. Pretty much click next until its done, unless you want to customise something during the restoration
9. Click Clean Up

If you do pay for the €40 version (that’s about ￡28) you get to replace steps 1-4 with selecting the backup record, i.e. you just don’t have to upload Kickstart and pick the directory. I don’t think that uploading a file and picking a directory is so demanding a task that guarantees a one star rating for the software.

Alternatively, you can do this:
1. Download the archive
2. Extract it with out FREE OF CHARGE Akeeba eXtract Wizard desktop software available for Windows, Mac OS X and Linux
3. Upload all extracted files – or just the installation directory if you only want to restore your database
4. Visit https://www.example.com/installation/index.php where https://www.example.com is the URL to your blog
5. Follow the on-screen instructions, i.e. pretty much clicking on Next until it’s done

Again, a very simply approach which doesn’t even mandate that the backup software is installed on the target server. Even if you completely screw up your site and have absolutely no way to log in to it you can STILL restore it. That’s the whole point of Akeeba Backup. Unlike other backup solutions it can restore a site from the dead without having to learn an entirely new process to restore your site. I think you’d agree that you’re most likely in need to restore your site when it’s completely dead, so here’s that.

As for the time to backup your site it depends on the size of your site and the speed of your server. On a fairly run of the mill shared hosting provider (Rochen) and a fairly small site (10Mb compressed) it takes 15 seconds flat. A site twenty times this size (300Mb compressed) took less than 4 minutes to back up. If your site takes hours and it’s smaller than several Gb big then may I respectfully suggest that you are in dire need of a better hosting provider.

In this case you should NOT add that to your .htaccess file. For more information please DO ask your host. These .htaccess line are entirely server-specific. Your host has configured the server, therefore your host can tell you what you should or shouldn’t add to your .htaccess file to enable one or another version of PHP. I can’t answer that question properly since I’m not your host.