I have installed two Drupal sites in my local Ubuntu desktop 15.10 Apache2 (2.4.12) environment: One is a fresh install of Drupal 8 and The second is a copy of an existing working site built with Drupal 7 (which is mostly core-modules based, very humble by means of pages). Both sites are working fine without any problem, anywhere.

My aim is first and foremost upgrading the Drupal 7 site to Drupal 8. I did all the preliminary stages like configuring the same languages, Keep minimal by means of modules (uninstalling any modules in the D7 site that I could easily bring back after the Upgrade), making sure the same modules are installed in both sites, etc, and now I just want to "Transcend" (hope its a good phrasing) my Drupal 7 site into the fresh Drupal 8 one.

To achieve my aim I've installed the Drupal Upgrade module in my Drupal 8 site, went to localhost/sitename/upgrade, and filled in all the details of the Drupal 7 site.

When I clicked the "Review upgrade" button I got the error:

Source database does not contain a recognizable Drupal version.

I've googled this error as an exact phrase ("Error") and found very few results; Most of them seem to me to require a PHP programming knowledge that I've yet acquired, so I can't determine if the error is due to a bug (especially since this module is still under heavy development) or due to my mistake in understanding the concept\functionality of this module.

  1. What reasons are there that the D8 Drupal upgrade module wont "like" the D7 database I provided? Especially while the Drupal 7 site is working fine both online and locally.

  2. Would migrating be a decent alternative for upgrading, if upgrading isn't possible for whatever reason? If so, what is the best most simple solution You could think of for migration?

enter image description here

I went to /var/www/html/benia/modules/migrate_upgrade/src/MigrationCreationTrait.php and did:

-- return $version_string ? substr($version_string, 0, 1) : FALSE;

++ return 7;
++ return $version_string ? substr($version_string, 0, 1) : FALSE;

Than got this error in top of the screen.

enter image description here

  • 1
    All I can see is that it doesn't like like that database contains a Drupal 7 installation, just like the error says. Something has to be wrong in your configuration or you didn't import it where you expect it to. – Berdir Dec 31 '15 at 9:54
  • Why won't it like the DB? The D7 site with this DB works pretty well without any probs... – user16289 Dec 31 '15 at 12:42
  • 1
    Oh and @Berdir by "configuration" you mean to the conf in the Drupal Upgrade module in the D8 site? I was sure the details I filled where all I need, I'll check if I've missed anything... You think I missed something?... – user16289 Dec 31 '15 at 12:44
  • Have you tried instead localhost already? (As it maybe really doesn't get through to a database at all with your current upgrade config) – leymannx Jan 1 '16 at 23:20
  • Sorry I think I did understand... Can you please rephrase what you wrote? Much thanks!!! – user16289 Jan 2 '16 at 2:01

At this stage, I don't think there is a simple option to upgrade from 7 to 8. As you can see on the release note:

Once you are ready, Drupal 8 core also includes the Migrate module to update existing Drupal 7 and 6 sites to Drupal 8 directly. Migrate is marked "experimental" in Drupal 8.0.0, but will be fully supported in an upcoming release. https://www.drupal.org/news/drupal-8.0.0-released

A little bit technical behind the scene: From 7 to 8 version, they keep the same concept when building site (like node, entity, permission, views...) but not the core. I would say: they changed everything to OOP, Symfony component, architecture... So there is no way to upgrade your drupal site directly from decent version to 8.0, you have to migrate. Here is how the migrating process should look:

  1. Recreate the site with the same functionality to your d7 site.
  2. Recreate the theme (using twig template)
  3. Migrate content over

The cost to this process is (unfortunately) same to recreate a new site or more. With the no 3, take a look at this article by Phase 2: https://www.phase2technology.com/blog/upgrading-to-a-drupal-8-site/

| improve this answer | |
  • I have started to manually building a rewritten site in Drupal 8... It is good indeed that many of the modules I used in D7 went into the core; I hope that in the time being when I will migrate to Drupal 9, the migration technology would reach a state where it can be more partial, done in different contexts, Node on-page data & meta data, node redirects, files, Views, Panels, everything to it's own as much as possible... splitting the process to different stages (when you could start from each possible stage whenever you like) is something I hope to... – user16289 Jan 6 '16 at 5:18
  • Sorry to unapply: I just posted my answer below with specific details on what most probably happened, please see. The bounty is with you, of course. – user16289 Sep 24 '16 at 7:52

Your error message is an exact match with the string contained in the line at http://cgit.drupalcode.org/migrate_upgrade/tree/src/MigrationCreationTrait.php#n40 within the code of the "Drupal Upgrade" module (https://www.drupal.org/project/migrate_upgrade).

It shows that it is not a bug, but instead an "exception being thrown". Looking at the 3 preceeding lines of that code, I think it is only a problem in setting up the connection.

Maybe this helps also:

  • a quote from issue https://www.drupal.org/node/2628440 (comment nr 3):

    To check that the source database is a valid Drupal database, and to determine the version of the database, the upgrade process looks at the 'system' table - is that table present in the database you specified in the form? Is the Drupal installation in that database prefixed (and if so, did you enter the prefix in the "Advanced options" section of the form)?".

  • Followed by comment nr 4 in that same issue: "Providing tables' prefix solved the issue.".

And of course, the comment from benjy (thank you!) would also help to get more details about the actual error you're running into, i.e.:

you could print out $e->getException() here cgit.drupalcode.org/migrate_upgrade/tree/src/… and then you'll see the PDO error

You could (temporary) add such print between lines 122 and 123 in the code shown via the link.

| improve this answer | |
  • As I mentioned in the question I don't have the PHP knowledge to understand what's the problem from that vast PHP code... Can you please edit the question and explain in simple words what is actually this "Exception being thrown" and what is the stepped way to handle it? Please as simple as you can, I'm just starting to taste PHP. – user16289 Jan 2 '16 at 16:24
  • @benos It simply means that very probably something very trivial is misconfigured in your migrate settings. A typo, a wrong password, a wrong URL. Something like that. – leymannx Jan 2 '16 at 18:17
  • @benos, you could print out $e->getException() here cgit.drupalcode.org/migrate_upgrade/tree/src/… and then you'll see the PDO error. – benjy Jan 3 '16 at 2:28
  • @leymannx If I've created 2 DB's locally (one for D7 one for D8), only the one of D7 should have exactly the same details is the online site I want to upgrade, right? – user16289 Jan 3 '16 at 20:10
  • @leymannx I've recreated everything. The local D7 data is exactly the same at the online D7 site: The site's folder is the same; The DB name and Username are the same, and the passwords are the same; I also added the prefix and though everything seems to be in place I still get the same error. – user16289 Jan 4 '16 at 19:44

The moment you force the codebase to skip reading {system} it dies with not finding the next database table, {field_config_instance}. In other words: it is not reading your D7 database. Perhaps it tries to read the D8 one, perhaps something totally else, how could we know? More than likely you are entering the wrong DB configuration (say, the two sites are on different servers with mysql server being localhost on both but localhost is not the same server). I just checked the Migrate Upgrade contrib module and the core migrate module code both and it'd extremely surprising if there'd be a bug relating to prefix as both handles an entire database settings array, not piece-by-piece.

It's impossible to say without having access to your infra on how to fix this. Sorry. If I could I would vote to close it but since there's a bounty, I can't. We can't help you and this question won't help others. The only possible help is this: read and understand your Drupal 7 settings file and give the right credentials to the Migrate Upgrade module (The huge amount of comments are already showing this is going nowhere.)

One possible longer term solution would include a feature in the contrib module where people can upload their settings.php and then we could try using that. This is extremely fragile but worths a shot I guess. When someone will have time to code it...

I have no idea why people upvoted this so heavily. Is there anyone else who has the same problem?

| improve this answer | |

Much time has passed since I posted this but I think I now know what was the problem:

I left 2-3 modules installed, which I (then) thought to be "so basic" so I was sure they have a migration path just as all core modules have.

These were, if I remember correctly: Metatag and Redirect (you move from D7 Globalredirect & Redirect to just Redirect in Drupal 8).

Not only I left these in the D7 site, I also installed them in the D8, so none of the versions of my site were core-only, as needed.

It was my first migration and I did that mistake as a total freshmen to the project. I was really convinced that "it can't be" that these modules won't have a migration path (and when you think of it, they really should have), but then I discovered that indeed, usually only core modules have and anything else should have a custom or contrib migration path.

Just so you know --- These, and other modules does have contrib migration paths that you can use by patching them with this migration path (you "inject" it into the module with the path).

Anyway, it wasn't the case for me back then and I was sure it comes with the system...

I was painfully wrong and this seems to me the sole reason why the migration above was failed; I even reinforced this assumption with a small experiment I did before my last successful migration about 2 months ago.

| improve this answer | |

Once I got that error message. It turned out to be the $db_prefix set by me "drupal_". You should put that in advanced options.

Regards, Carlos Aleman

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy