Support

Akeeba Backup for Joomla!

#9180 Folders and components remain after restore from a pruned dev site.

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
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

Joomla! version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by nicholas on Saturday, 26 November 2011 17:19 CST

user41018
Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? Yes
Have I searched the forum before posting? Yes
Have I read the documentation before posting (which pages?)? Yes
Joomla! version: 1.7.3
PHP version: 5.2.17
MySQL version: (unknown)
Host: HostUpon
Akeeba Backup version: 3.3

EXTREMELY IMPORTANT: Please attach your Akeeba Backup log file in order for us to help you with any backup or restoration issue.

Description of my issue:

This is not really an issue, but a request for some best practice
information.
My development site is in a subfolder (PLCdev) of the site root that contains the production website.
I make changes to the development site and then use Akeeba full site backup (& kickstart) of PLCdev to post the updated site to the production site.
This seems to be working well, with one exception. When I uninstall unwanted components etc from the development site, this procedure still leaves the folders on the production site that were deleted on the development site by the uninstall process.
Is there a better way to work with production & development sites that does not involve having to manually delete obsolete folders on the production site?

Thanks

Jim

nicholas
Akeeba Staff
Manager
Hello Jim,

To the best of my knowledge, there is no easier way to do it. The alternative involves using Git, SVN or RSync to manage the files and custom scripts to transfer the database contents from the staging to the live server. Moreover, all of those require using the command line through an SSH terminal. It's not very fun having to set up something like that, not to mention that a small mistake in such a solution could have grave effects for your live site.

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!

user41018
Thanks, Nicolas. I thought that might be the case. Not a problem.

But checking the development site and production site just now, I cam across a much more serious error, related to the the way I am using akeeba backup. If you look at this page

http://www.potluckceramics.ca/Cookware-Dinnerware-Catalogue/product/3574-cone-bowl/Itemid-134/category_pathway-22.html

you will see that it gives a page not found error. But if you look at the exact same page on the development site:

http://www.potluckceramics.ca/PLCdev/Cookware-Dinnerware-Catalogue/product/3574-cone-bowl/Itemid-134/category_pathway-22.html

there is no such error.

What is going on with the way I am using akeeba. This is an urgent issue now that the development site has gone into production this week.

Jim

nicholas
Akeeba Staff
Manager
Hello Jim,

It looks like you are not transferring sh404SEF's URL cache table. Take a look at your excluded database tables in the dev site's Akeeba Backup Control Panel page.

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!

user41018
Thanks for the pointer, Nicolas.

Please could you give me more explicit directions what I should be looking for and where and how to fix.

Thanks

Jim

nicholas
Akeeba Staff
Manager
Log in to the back-end of your website. Click on Components, Akeeba Backup. Make sure the backup profile displayed on the top of the page is the one you use to transfer your dev site to your live site. If not, please select the correct profile from the drop-down menu. Click on the "Database Table Exclusion" button. You will see a list of your database tables. Above that, you will see two links titled "Normal View" and "Tabular View". Click on "Tabular View". This displays the entire list of excluded tables. Make sure that no table belonging to sh404SEF is on that list. If it is, click on the trashcan next to its name to remove the exclusion. Then take and restore a new backup.

Alternatively, you can try something simpler. You can go to your live site and purge the SEF URL cache. However, this will invalidate all URLs and you have to visit all of your site's pages to "prime" sh404SEF's URL cache again. That's why I recommend the previous procedure, although it's a little more complicated.

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!

user41018
Thanks very much for the quick reply.

There are NO tables at all listed in the Tabular view. I will try the second procedure.

Jim

user41018
Clearing the URLs in SH404sef did not solve the problem, I still get some 404 errors.

Jim

user41018
I just notices that there is no entry in the sh404sef URL for the pages that give a 404 error. I wonder if it might not be better to get rid of the sh404sef component. It seems to be the sources of the problem.
But I'm puzzled why the backup is not giving identical copies of the development website.

Jim

nicholas
Akeeba Staff
Manager
The thing is that, unless you manually exclude something or use a buggy version, Akeeba Backup produces an exact clone of your site. Can you please verify that you've got Akeeba Backup Professional version 3.3.7 installed on your site? If you're using one of the alphas or betas I can guarantee that you'll have problems with them (just take a look at the CHANGELOG to see what I mean).

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!

user41018
Yes it IS 3.3.7
Akeeba Backup Professional 3.3.7 (2011-11-19)

I have not excluded anything that I am aware off and the empty Database tabular view confirms that...

It really is a mystery to me why this should be happening. It always worked fine in the test environment The problems only started when I moved to the production setup with the production site in the host root and the PLCdev site in a subfolder?

I do need to resolve this quickly. The clients will be on my case very soon......

Jim

nicholas
Akeeba Staff
Manager
Take and restore a backup. Immediately take a look at your jos_sh404sef_urls table (where jos is your database table name prefix). How many rows do you have on the table of each site? There should be no difference. If there is a difference, please let me know exactly how many records are on each site's tables.

The next thing to check is the oldurl field of the URLs in the jos_sh404sef_urls table (on any side, it doesn't matter which one). If you see the name of your subdirectory inside them, e.g. PLCdev/blah/blah.html then you have a problem, as all the SEF URLs on the live site will be invalid (different root folder than the one used) and they won't work. In this case, you can always install the dev site in a subdomain instead of a subdirectory. I would actually recommend doing that nonetheless, for too many reasons to cite them all over here. Let me just say that restoring from a subdirectory to the root is bound to break things very badly due to the way relative URLs are stored. Restoring from a subdomain to the root has no such adverse effect.

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!

user41018
There are NO references to PLCdev in any of the URLs in the URL manager of SH404sef. I assume I'll need to look at the size of the tables using PHPmyadmoin and I'll do that later.

I've created a subdomain development.potluckceramics.ca and amy bakcing up and restoring from that. I'll let you know how that goes and check the table size.

I really do appreciate all this help.

Many thanks

Jim

user41018
Still getting 404 errors after t backup and restore from teh development site.

Looking at the sh404sef_URL tables.
There are 178 rows in the database for the production site but only 155 rows in the databse for the development site.

Could this be a bug in version 3.3.7?

I think I am going to remove the sh404sef component from the production site, just to get rid of the 404 errors. At the moment I'm one step ahead of the clients on this, so I really do need to get rid of those errors in the next few hours.

Jim

user41018
I removed the sh404sef component from the development site and did a fresh backup and restore. That appears to have taken care of the 404 errors.

If you want me to replicate this problem I can do that on a different host that I use, but I don't want to mess with the production website right now!!!!

Many thanks for your help. It got me looking in the right direction for the problem.

Jim

nicholas
Akeeba Staff
Manager
Well, this is strange... I did some testing to see if there's a bug in database dump, with small and big tables on various platforms and PHP versions but I could see no problem. I'm not sure why there were missing URLs from sh404SEF's table :s

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!