Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Please advise. On a fresh install of D7.18.
From URL: ../admin/config/system/backup_migrate/destination
Notice: Undefined index: scheme in backup_migrate_destination_remote->glue_url() (line 1048 of /home/user/www/drupal/sites/all/modules/backup_migrate/includes/destinations.inc).
Notice: Undefined index: host in backup_migrate_destination_remote->glue_url() (line 1052 of /home/user/www/drupal/sites/all/modules/backup_migrate/includes/destinations.inc).
From other URLs, admin pages there is no error.
/**
* Glue a URLs component parts back into a URL.
*/
function glue_url($parts, $hide_password = TRUE) {
// Obscure the password if we need to.
$parts['pass'] = $hide_password ? "" : $parts['pass'];
// Assemble the URL.
$out = "";
$out .= $parts['scheme'] .'://';
$out .= $parts['user'] ? urlencode($parts['user']) : '';
$out .= ($parts['user'] && $parts['pass']) ? ":". urlencode($parts['pass']) : '';
$out .= ($parts['user'] || $parts['pass']) ? "@" : "";
$out .= $parts['host'];
$out .= !empty($parts['port']) ? ':'. $parts['port'] : '';
$out .= "/". $parts['path'];
return $out;
}
/**
* Break a URL into it's component parts.
*/
function set_url($url) {
$parts = (array)parse_url($url);
$parts['user'] = urldecode(@$parts['user']);
$parts['pass'] = urldecode(@$parts['pass']);
$parts['path'] = urldecode(@$parts['path']);
$parts['path'] = ltrim(@$parts['path'], "/");
$this->dest_url = $parts;
} *********** line 1048 **************
/**
* Destination configuration callback.
*/ *************** line 1052 *************
The line numbers above are (of course) not in my module file.
Any suggestions?
Comments
Comment #1
volkan@bd CreditAttribution: volkan@bd commentedsame issue, same problem. Any help?
Comment #2
rCharles CreditAttribution: rCharles commentedNo, no community help on this yet.
Comment #3
soulston CreditAttribution: soulston commentedUPDATE:
This turned out to be due to a migrate database being specified without any connection information, endpoint or port etc. specified.
---------------
Using: Version 7.x-3.1
Seeing this error also:
/admin/config/system/backup_migrate
Notice: Undefined index: scheme in backup_migrate_location->glue_url() (line 388 of
/admin/config/system/backup_migrate/export/advanced
Notice: Undefined index: scheme in backup_migrate_location->glue_url() (line 388 of
And fails to render the page at all.
Comment #4
rCharles CreditAttribution: rCharles as a volunteer commentedWould/could this be due to a server configuration using/showing localhost instead 3306 on installation?
Comment #5
ultrabob CreditAttribution: ultrabob commentedI'm having the same issue, I'd be happy to help investigate it. I've tried uninstalling the module, thinking that perhaps some legacy information in the settings was causing issues, but that seems not to be the case. I have two databases in my settings.php file because I'm running a migration. It seems that this very likely relates to that, or I guess more people would be reporting it.
Comment #6
ultrabob CreditAttribution: ultrabob commentedIf anyone has a solution to this, please do let me know, it is extremely irritating!
Comment #7
DamienMcKennaFirst off, there's duplicate code in these classes: #2703351: Redundant methods in backup_migrate_location_remote
Comment #8
ultrabob CreditAttribution: ultrabob commentedAs far as I can tell that issue is legit, but only related to this one inasmuch as the duplicate methods he refers to would also duplicate the issues in glue_url(). The errors I'm seeing. (with and without @DamienMcKenna's patch applied) is
Notice: Undefined index: scheme in glue_url() (line 388 of /var/www/pubtest.iges.or.jp/public_html/sites/all/modules/backup_migrate/includes/locations.inc)
and
Notice: Undefined index: host in glue_url() (line 392 of /var/www/pubtest.iges.or.jp/public_html/sites/all/modules/backup_migrate/includes/locations.inc). =>
I've put some effort into debugging this, and it seems to be related in some way to the database configuration info being stored in the settings.php file, and possibly with having two databases configured there. When I manually input a database into backup_migrate glue_url returns something like
mysql://db-user@localhost/db-name
Whereas for sources that are configured in settings.php I get:
:///
because the $parts array glue_url is receiving looks like this:
Comment #9
ultrabob CreditAttribution: ultrabob commentedIt seemed like a workaround to this issue would be to overwrite the database settings, and provide the information via form, but this doesn't work because the machine_name generated by the system contains colons which are illegal for me to enter into the form. Here is my sanitizes db configuration from settings.php:
The machine name comes out being:
db:outputdb:default
so I cannot save my override.Comment #10
cozzamara CreditAttribution: cozzamara commentedSame Issue fo me....with 2 database like #9
Comment #11
cozzamara CreditAttribution: cozzamara commentedI forgot to type that my issue happen only on remote 1and1 server. On my localhost nothing happen, but I don't find why...
Comment #12
cozzamara CreditAttribution: cozzamara commentedThe only difference between local and remote that is the mysql host and user are different. On local is "localhost" root while on 1and1 is "xxxxx.db.1and1.com" xxxx user.
Comment #13
cozzamara CreditAttribution: cozzamara commentedAnther difference....the two database have different hosts and different user name...
host1: xxxxx.db.1and1.com user: xxxxxx
host2: yyyyy.db.1and1.com user: yyyyyy
Comment #14
cozzamara CreditAttribution: cozzamara commentedAnther difference....the two databases have different hosts and different user name...
host1: xxxxx.db.1and1.com user: xxxxxx
host2: yyyyy.db.1and1.com user: yyyyyy
Comment #15
aramboyajyan CreditAttribution: aramboyajyan commentedI encountered the same issue and narrowed the problem down to
parse_url()
.It was unable to parse access information in certain cases (e.g. when passwords contain some special characters). Changing this fixed the issue and the error messages are not displayed anymore.
Just thought to post it here in case someone else is having the same issues.
Comment #16
couturier CreditAttribution: couturier as a volunteer commentedIs there a chance you could upgrade to the 7.x-3.2 version released September 27, 2017? The code for the 2.x branch hasn't been updated in 4 years. The newer code might resolve this issue.
Comment #17
couturier CreditAttribution: couturier as a volunteer commented@DamienMcKenna has proposed that the 7.x-2.x branch be marked as unsupported once the upgrade path to 7.x-3.x is verified. See this issue: Verify 7.x-2.x -to- 7.x-3.x upgrade path, mark 7.x-2.x as unsupported
Comment #18
ultrabob CreditAttribution: ultrabob commentedI didn't even realize this issue was on the 2.x branch. I was having the issue on 3.x. The only way I got the issue to go away was to get rid of the second db.
Comment #19
digitaltodd CreditAttribution: digitaltodd as a volunteer commentedseems I get this when upgrading from 7.x-3.1 to 3.2 - I have two sites with 3.2 have the notice, and two without, no notice. My notice refers to line 388
Comment #20
tobiberlinI had the same notice. Checking my settings.php I found out that the 'host' value for the database setting was empty:
Turning
into
solved it for me. Module version is 7.x-3.3
Comment #21
hanksterr7 CreditAttribution: hanksterr7 as a volunteer commentedI wrestled with this for around a day, and got it to go away, but I'm still confused.
Fwiw, here's what I found
The problem appeared when I upgraded from php5.4 to 5.6. I'm on b_m 7.x-3.4 (I was on 3.1). I think php 5.6 is more picky about missing indexes that 5.4 (at least in terms of warning me)
The fact that the notices about missing indexes were showing in the log did NOT indicate the backups were failing. I was finding the backup files in the appropriate location
I too had extra db's defined in settings.php. If I got rid of the extras, the problem went away (but I wanted to keep the extras around).
I could get the missing index notices to go away by modifying glue_url() in backup_migrate/includes/locations.inc, doing a check for an empty scheme index on the $parts array
But now, magically, I don't need this check any more. Not sure why.
I also did some checks in backup_settings_default() in backup_migrate/includes/filters.backup_restore.inc, bypassing the call to
if $source->get_id() returned the name of one of my extra db's (in the form of db:dbcodename:default). That also no longer seems necessary
I had some bad passwords for the db's defined in settings.php. Maybe once I got those fixed, proper values for the $parts elements got saved someplace, which would be why the missing index messages are no longer happening
I played around with the formatting of my databases entries in settings.php. Nothing seemed to matter.
My main drupal db is defined by this syntax
and my extras are defined uses this syntax
So, overall, I'm confused as to what happened, but glad the problem is gone
Comment #22
couturier CreditAttribution: couturier as a volunteer commented@hanksterr7 Is it possible for us to close this issue then?
Comment #23
hanksterr7 CreditAttribution: hanksterr7 as a volunteer commentedYes, feel free to close
Comment #24
couturier CreditAttribution: couturier as a volunteer commentedPlease re-open with more information on how to duplicate the error if anyone continues to have this problem, thanks.