backup_migrate/profile/list/add will fail if databases are not online or do not exist, with message:

PDOException: SQLSTATE[42000] [1049] Unknown database 'mysite_civicrm_staging' in backup_migrate_destination_db->_get_db_connection() (line 212 of /path/to/backup_migrate/includes/destinations.db.inc).

The website encountered an unexpected error. Please try again later.

Destinations can be created successfully without the DB existing, or the connection strings validating. Profiles should work the same way, IMHO.

In my particular use-case, I am trying to pre-fab some profiles for my staging environment, which uses database names that do not exist in my local environment, i.e. mysite_civicrm_staging.

Comments

ronan’s picture

ronan commented
Status: Active » Closed (won't fix)

Removing this dependency would break the ability to set the exclude/nodata tables for the specific db, and more people want that feature.

andrew_mallis’s picture

andrew_mallis commented
Status: Closed (won't fix) » Active

I think understand where you are coming from.

I don't think I expressed myself clearly enough, though, so I'm going to try again, if I may.

First, I think we could improve the error message a bit. Perhaps we could catch this exception and return an error message that, minimally says something like:

"Backup and Migrate was not able to connect to your specified database. Please verify the configuration of your destination $destination_name [link to edit form]."

Further, though, If the user has a remote database specified, and that remote is unavailable, they cannot edit any profiles.

Would it not be feasible to wrap the call to check db connection in the "Default Database Backup Options" form with some logic that returns a connection failed message (as above) if the DB is not found? That way the user could proceed to configure other parts of their profiles.

I'm not suggesting to remove the dependency on setting data table/table data exclusions. That's a truly awesome feature and core to the vision for this module. What I am suggesting is removing the dependency on all destination connections resolving in order to edit a profile.

tdway’s picture

tdway commented

I agree. It seems better to:

1) handle the error so profiles can still be edited when some destinations are offline
2) only show exclude options for online destinations OR make the exclude field a textarea so dynamic population isn't required

ronan’s picture

ronan commented
Version: 7.x-2.2 » 7.x-2.x-dev
Status: Active » Fixed

I have fixed this in the 7.x branch. Offline db's no longer appear as an available backup source.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.