It would be great if somehow we could track the database prefix, and then re-save it back to settings.php when restoring the database so that the user doesn't have to worry about what database prefix they put in during installation.

Comments

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

Corresponding issue: #339695: Save table prefix

I'm not sure whether we really want to force the stored (previous) DB prefix. What if I create a snapshot in one database with a prefix and want to replicate this site to several other servers that do not require a db prefix?

I mean, if we could "suggest" the original prefix during the setup in the database connection settings, that would be fine - but install profiles do not allow to alter the forms at this stage, AFAIK - if we could, we could also skip the whole installation process, just restore the snapshot, and redirect to the ready site.

robloach’s picture

robloach
he/him
commented

Skip the installation process? But you have to know what database to restore the dump to. And which dump to restore when your installing the site..... What if we scanned the .sql file for the table_prefix (rather simple regex on the first X characters of the file), and then rewrote that change into settings.php?

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

Nah, adding the previous db_prefix to the .info file is not a problem at all. If that helps to make this profile wicked, I'm fine with it. ;)

However, now that you mention it - Demo dumps all database tables "as is", including a prefix (if there is one), so the user is not able to change the prefix upon installation using the profile (as long as we do not implement a customized version of prefix.sh I wrote some time ago, which allows to alter the table prefix in a database dump that contains a prefix already ;).

So yes, for now the ideal solution would work like this:

  1. Intercept the database settings form to prefill and disable the table prefix field, add Demo's snapshot selector, and override the form submit callback.
  2. In the custom submit callback, create settings.php (like the regular submit function) and invoke demo_reset().
  3. Redirect to the ready site.

If I'm not mistaken, the current profile unnecessarily performs a regular installation of Drupal core modules (and Demo module). So the goal should be to intercept the installation process as early as possible.

Slightly OT: Most probably we also want to search for snapshots in (or below) the installation profile's folder, since there is no file directory path at this stage.

robloach’s picture

robloach
he/him
commented
Version: 6.x-1.x-dev » 7.x-1.x-dev

Pushing to 7.x due to the awesome sauce.

Leeteq’s picture

Leeteq commented

Slightly related:

The demo_profile module's project page states:
"REQUIRED: Use the same table prefix you were using for your original site."

But the demo site module itself has no _requirement_ for a db prefix, AFAICS.

So perhaps that sentence on the project page should read something like:
"REQUIRED: Use the same table prefix you were using for your original site, if it is using one."
(Plus add it to the readme.txt file as well.)

Then users would not need to find out whether the main demo site module is requiring db prefixes...