1

My live/staging Drupal site on remote host was installed without git version control (I don't even recall, but I guess I used wget). Also it has content, modules and themes I wish to keep. The new dev site is also Drupal 7.x but was installed with git version control. To update the dev server I'm thinking to pull down all the content, modules, etc. See if I can get it running, then push it back into a new git repo on remote.

I've added the necessary alieses, and with drush, I copied everything in sites to the local dev site,

drush core-rsync @test:%sites @dev:%sites

Now I wish to use drush sql-sync to pull down the database for the whole site, but minus core. Reading the drush help file for sql-sync, I can only see: 

--tables-list  A comma-separated list of tables to transfer.

Which puts me in the same boat if I did a dump from MySQL.

What is the drush sql-sync arguments for modules, themes, sites, but "not core"?

Improve this question

2 Answers 2

Reset to default
3

There are also the --structure-tables and --skip-tables options. The --skip-tables option will completely remove the tables when dumping or syncing, while the --structure-tables option will sync table structure but not the data.

I don't think you want to drop the core modules tables in your development enviroment, so I suggest adding the tables to the --structure-tables option. You can add configure drushrc.php to have the tables listed separately, like this:

$options['structure-tables']['common'] = array(
  'cache', 'cache_*', 'history', 'search_*', 'sessions', 'watchdog');

And then you can use the --structure-tables-key option:

drush sql-sync --structure-tables-key="common" @project.prod @project.dev
Improve this answer
6
  • I don't understand why --skip-tables is a problem if I'm only trying to get module data. I imagined there would be a problem syncing databases if the destination isn't exactly the same. But modules, for example, should be an add to the database and outside of core, no? What I don't see in your answer is a drush workaround or shortcut to skip core tables. I'm surprised, given your drushrc.php example, there isn't a --structure-tables-key="core" but I need the inverse! Woe!
    – xtian
    Aug 1, 2014 at 20:43
  • If you're talking about module configuration, it's really up to each module, though most support exporting configuration to code using the Features module. But if you're talking about module data, as in content, you will find that most content in Drupal is connected to other content (flags to nodes to users to roles) so you will have a very hard time separating core data from module data.
    – Capi Etheriel
    Aug 1, 2014 at 22:21
  • Ok. The situation is certainly not normal for a site owner--make the live version the new dev,
    – xtian
    Aug 1, 2014 at 22:26
  • I'm going to give a point just for a good explanation, but what I still don't understand (keeping me from accepting the up votes for answered) is how --structure-tables would work exactly in this exclusion case. The description makes it sound like it only works in the positive case through a definition in drushrc.php. And given your comment, its touch and go at that. Right?
    – xtian
    Aug 1, 2014 at 23:01
  • What's more, it seems the modularity that exists in the code (each module, theme has its own upstream repo, as does Drupal core), is broken in the database! You can't manage the database in the way I'm approaching the cloning problem (making my question really, how to make a non-git core under version control synced with drupal.com)
    – xtian
    Aug 1, 2014 at 23:05
0

Drupal simply is not segregated the way that you think that it is. The largest counterexample to your expectation is the "variables" table, an unstructured collection of named variables where core and contrib modules store data.

The --structure-tables and --skip-tables options are occasionally useful; for example, it is possible to transfer users, permissions and roles from one site to another by transferring only these tables. However, in general it is not possible to migrate partial data from a site by carefully selecting tables. In order to be successful at this sort of an operation, you will need to export and then re-import your data. Look at the features or ctools_export_bonus modules for configuration, and the migrate module for data.

Improve this answer
5
  • In the context of the question, I have, essentially, a remote site without git and I want to clone it locally, but under git version control. Are you saying the way to solve this problem is to use features, ctools and migrate? Sounds complicated.
    – xtian
    Aug 1, 2014 at 21:04
  • It is not really clear to me what your question is. The first half you are talking about files -- rsync and git. At the end, though, you are talking about sql-sync and --structure-tables, and transferring partial databases. Doing that -is- very complicated. If you just want to clone a site, create a new git repo (git init), clone it somewhere, and then duplicate the entire database. sql-sync without --structure-tables will do the trick there; if you copy the whole db, you will avoid a lot of trouble.
    – greg_1_anderson
    Aug 1, 2014 at 21:29
  • Ok. So taking this route to a solution (clone the old site to the new dev, dump db and import), can I then create a git repo in the new dev clone and sync that back to drupal.org to manage drupal core?
    – xtian
    Aug 1, 2014 at 22:04
  • Yes, of course you can, but I would recommend against using drupal.org for maintaining your site repository. github or a repo on a private server would be more appropriate. We are getting quite off-topic for Stack Exchange, though.
    – greg_1_anderson
    Aug 1, 2014 at 22:24
  • ?? I think you've misunderstood my meaning. But that's ok. It happens :) I'm following the Drupal.org page, Building a Drupal site with Git. So what you're suggesting could happen is already covered there. And so, the answer I'd accept, in this context, is the core-sync of just %sites is not the best route to cloning a non-version control with a fresh drupal install. If the ultimate goal is to sync core with drupal.org's git repo, to follow through with what I've started, would require the other solutions mentioned, etc.etc.
    – xtian
    Aug 1, 2014 at 22:33

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.