This patch adds a ctools.drush.inc file which enables you to export all exportables with on command to a module.

Command example: drush ctex module_name
This will select all known exportablles and write following files a sub folder called 'ctools_export' (can be overridden):

- sites/all/modules/ctools_export/module_name/module_name.info
- sites/all/modules/ctools_export/module_name/module_name.module
- + all other files (eg. module_name.views_default.inc etc)

Files: 

Comments

merlinofchaos’s picture

Status: Needs review » Fixed

Committed! This is pretty awesome!

Followups that I think are necessary:

1) There needs to be some way to control what you export.
2) There probably needs to be a command for listing what's exportable.
3) The ability to export one exportable per file. This should be totally possible if we're creating the file structure.

I almost think that having a file that defines what we're exporting would be really handy, because then doing a drush ex --file=definition file would be an awesome way to just refresh everything exportable. Follow that up with the a drush revert everything and build these modules up very quickly.

merlinofchaos’s picture

Also, being as you posted that on Dec 25, thanks for the Christmas present!

swentel’s picture

Status: Fixed » Needs review
FileSize
1.16 KB

Great! However, we broke this due to #1331694: Use vertical tabs for Bulk export selection page getting in, should've tested this with both together, mea culpa. Follow up patch posted wich also fixes a small notice in the UI.

I've got a set of other commands on my local machine allowing todo this:

- list all tables
- list all tables with exportables
- select on table level
- select on table -> exportable level

Our testing revealed we didn't really used these commands a lot since it involves a lot of typing. However, I could try and convert the selecting of exportables with the multiple select that's built in in Drush.

My local code also has the concept of remembering previously remembered exportables. This was stored in a simple serialized variable, which can be relatively big with a lot of exportables, so maybe this should be moved to a dedicated table. This is handy for my colleagues using the UI so they don't have to remember which they selected previously, and on the command line level, this indeed prevented exporting everything over and over again instead of those we just need. In theory, this concept could be extended with having multiple sets of exportables (think features packages), but in the end I didn't go through with that since we just wanted to export the site, not a package. I'll post some patches, most likely somewhere next week, got hold up this weekend sadly enough with something else.

swentel’s picture

FileSize
3.27 KB

Ok, nicer patch with the fixes included from #3 + some minor cleanups in spacing, extra lines in generated code (eg extra line before the @file block), consistent key names.

merlinofchaos’s picture

Status: Needs review » Fixed

Yeah, the worry about typing too much definitely is there. Having the actual exports needed stored somewhere is a good idea. I'd be just as happy with a file as a database table (the file is more portable, I think, since it can be part of the module).

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.