Support

Akeeba Backup for WordPress

#21332 Migrating in WP is not as smooth as Joomla

Posted in ‘Akeeba Backup for WordPress’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

WordPress version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by nicholas on Wednesday, 29 October 2014 11:01 CDT

Pettigrew
Hi,

I've started to use the akeebabackup for wordpress and everytime I migrate a site, I doesn't show correctly right away. I'm used to the Joomla version where everthing works correctly right from the start. So I am wondering if I'm missing a step, or this is normal behavior, or it is a bug.


For instance, I migrated the live site http://example.com/ to our test environment http://example.org/example/. You can see that on the test site that some images are not showing. They use relative path. It would be easy to fix by just adding a dot before the slash (ex: ./wp-content/themes/something/images/logo.png). It would be tedious to change one by one all these images everytime I migrate the site.


Do you have suggestions to avoid that issue?


The other issue was related to 404 errors with the submenus. I fixed this by going in the admin>settings>permalinks and changing the options from "Post name" to another value, saving it, and saving it back to "Post name".



Thanks for your help!


Michael

nicholas
Akeeba Staff
Manager
TL;DR – Your problem is moving from the domain's root to a subdirectory. As we are also saying for our Joomla! extension: it is strongly recommended to create sites in subdomains, not subdirectories. Moving FROM a subdirectory TO another subdirectory or the domain's root is far less problematic. This holds true for both Joomla! and WordPress (and pretty much everything else we've tried backing up and restoring)

The gory details

Images: this is not a problem unique to WordPress. Joomla! has the same issue. In fact, it is not something you can possibly "fix" automatically. All CMS store relative paths. If the installation path of your site relative to your domain's root changes (moving from root to subdirectory, from subdirectory to root, or from one subdirectory to another) the stored relative paths are now invalid. If you are moving FROM a subdirectory TO a different subdirectory / the domain's root it's easy to perform an automatic replacement and we do. We substitute /your_old_subdirectory with / and we're done.

Moving from root to a subdirectory, however, is a whole different story. Think what would happen if / was replaced with /subdirectory in your content. If you had a link to http://www.example.com/something.html it would now become http:/subdirectory/subdirectory/www.example.com/subdirectory/something.html. That's a major problem. Dealing with it requires to have a context on each URL being processed. This means that we would need to open each article, parse the HTML, parse every img and a tag (probably more tags), decide if it's a relative path and then do the replacement. This is possible... but it will cause memory usage, CPU usage or timeout issues on the majority of servers. It's like performing a backup which requires 10x the CPU power of the regular backup. Therefore this is a case we can't handle automatically.

Regarding the menu items: it is also exactly like our Joomla! extension. The problem you have is your .htaccess file. Just like with the Joomla! extension we do not touch the .htaccess file. The .htaccess file WordPress created was made for use in the domain's root. You need to go to Permalinks and save your options again, which creates a new .htaccess for the new location of your site (the new location of your site is stored in WordPress during the restoration by our restoration script).

Note: would you mind us making this ticket public? I think it'll be useful for other people using our backup software as well.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Pettigrew
That's a good suggestion. Thanks for your explanations!
Please remove my URLs and use dummy examples if you want to put this public.

nicholas
Akeeba Staff
Manager
Thank you! I have changed the URLs and will now make the ticket public :)

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!