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

volkan@bd’s picture

same issue, same problem. Any help?

rCharles’s picture

No, no community help on this yet.

soulston’s picture

UPDATE:

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.

rCharles’s picture

Would/could this be due to a server configuration using/showing localhost instead 3306 on installation?

ultrabob’s picture

I'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.

ultrabob’s picture

If anyone has a solution to this, please do let me know, it is extremely irritating!

DamienMcKenna’s picture

ultrabob’s picture

As 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:

array (
0 => FALSE,
'user' => "",
'pass' => "",
'path' => "",
);
ultrabob’s picture

It 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:

$databases['default']['default'] = array(
    'driver' => 'mysql',
    'database' => 'db',
    'username' => 'user',
    'password' => 'pass',
    'host' => 'localhost',
    'prefix' => 'main_',
    'collation' => 'utf8_general_ci',
  );

  $databases['outputdb']['default'] = array(
      'driver' => 'mysql',
      'database' => 'db2,
      'username' => 'user2',
      'password' => 'pass2',
      'host' => 'localhost',
      'prefix' => 'xoops_envirolib_',
      'collation</code>' => 'utf8_general_ci',
    );

The machine name comes out being: db:outputdb:default so I cannot save my override.

cozzamara’s picture

Same Issue fo me....with 2 database like #9

cozzamara’s picture

I forgot to type that my issue happen only on remote 1and1 server. On my localhost nothing happen, but I don't find why...

cozzamara’s picture

The 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.

cozzamara’s picture

Anther 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

cozzamara’s picture

Anther 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

aramboyajyan’s picture

I 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.

couturier’s picture

Status: Active » Postponed (maintainer needs more info)

Is 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.

couturier’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)

@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

ultrabob’s picture

Version: 7.x-2.4 » 7.x-3.x-dev
Status: Closed (won't fix) » Active

I 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.

digitaltodd’s picture

seems 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

tobiberlin’s picture

I had the same notice. Checking my settings.php I found out that the 'host' value for the database setting was empty:

Turning

// Database settings
$databases = array (
  'default' =>
    array (
      'default' =>
        array (
          'database' => 'database',
          'username' => 'user',
          'password' => 'password',
          'host' => '',
          'port' => '',
          'driver' => 'mysql',
          'prefix' => '',
        ),
    )
);

into

// Database settings
$databases = array (
  'default' =>
    array (
      'default' =>
        array (
          'database' => 'database',
          'username' => 'user',
          'password' => 'password',
          'host' => '127.0.0.1',
          'port' => '',
          'driver' => 'mysql',
          'prefix' => '',
        ),
    )
);

solved it for me. Module version is 7.x-3.3

hanksterr7’s picture

I 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

if (empty($parts['scheme']))
       return $out;

$out .= $parts['scheme'] .'://';

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

$out['sources'][$source->get_id()] = $source->backup_settings_default();

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

$databases = array (
  'default' => 
  array (
    'default' => 
    array (
      'database' => 'dbname_drupal',

and my extras are defined uses this syntax

$databases['ls']['default'] = array(
  'database' => 'dbname_other',

So, overall, I'm confused as to what happened, but glad the problem is gone

couturier’s picture

@hanksterr7 Is it possible for us to close this issue then?

hanksterr7’s picture

Yes, feel free to close

couturier’s picture

Status: Active » Closed (cannot reproduce)

Please re-open with more information on how to duplicate the error if anyone continues to have this problem, thanks.