Support

Site Restoration

#33692 database info pre-populates on restore

Posted in ‘Site restoration’
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

PHP version
n/a
CMS Type
Other
CMS Version
n/a
Backup Tool Version
n/a
Kickstart version
n/a

aimlesslady

I maintain several websites. I always test the backup on a directory with separate databases.
When I restore the website to the backup directory, I have noticed that most of the sites have the database info pre-populated but a few do not. I was wondering what setting regulates that so I can be consistent.
I also noticed some sites wil return a 404 error when I navigate the site. I know how to fix this- I add the directory name after the RewriteBase / in the .htaccess file. But what I don't know is why some sites do this and others do not. Again, is there a setting to regulate this?

nicholas
Akeeba Staff
Manager

Please read the documentation:

The first thing you see is the column in the left hand side of the page. It is pre-populated with the connection settings of the site you backed up. If you are restoring to a different site than the one you backed up from it will be blank, indicating that you must specify the correct connection information for the new server.

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!

aimlesslady

I understand this. What puzzles me is that on a few of my sites,the behavior is different and I don't know why. Same host, new directory and database for restoration. (basically, I create a copy of the Joomla installation in a directory in the root of the server with a separate database). With some sites, the database info is pre-polulated with the live site's info, (which I need to change to the backup database), but some sites the fields are blank. Is ther a setting in the backup configuration that I inadvertently set to cause one way or the other?

nicholas
Akeeba Staff
Manager

OK, it wasn't clear that you were already aware of the operating principle.

The first thing to consider is what the server itself reports as the effective site URL and absolute path to the site. Please note that the protocol and subdomain matter for the site URL. This is to say that https://www.example.com, https://example.com, http://www.example.com and http://example.com are four different sites as far as the restoration is concerned since there is no way to reliably know if they are served by the same or a different path on your site (and, trust me, I've seen servers which would indeed serve a different site on each of the four URL variants!).

Regarding the site root, thing are easier. If it's a new directory it's a different site.

The other thing to consider is that browsers and third party browser extensions offer form autofill and caching. A browser can very well try to auto-fill your connection information, usually with the wrong information (most likely your login username and password) because the form autofill is very lax about matching credentials with sites. It's also possible that the browser has cached the contents of the form from a previous restoration and autofills them for you without asking. Unfortunately, even though an autofill="off" attribute exists for form fields, browsers are ignoring it since circa 2017 because it was being abused by sites to prevent password autofill in login pages. So, yes, browsers decided to break the specification they created themselves and this non-intuitive behavior is even documented in the Mozilla Development Network!

Finally, if you go back and forth in the restoration interface you will see that the database page's fields are autofilled if you have already filled them in before backtracking to that page or reloading the restoration. This is intentional. You can go back to the first page of the restoration and click the red Start Over button at top of the page to clear the temporary storage used by the restoration script.

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!

System Task
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

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!

Summer vacations: Our support will be closed for replies and new tickets from August 6th to August 21st, 2022 due to summer vacations.