This is first, very rough, iteration of drush block configure command.
This enables you to control block placement using drush command.
example usage:
# Place Development menu block in right sidebar
drush block configure --module=menu --delta=devel --region=sidebar_second --weight=-1 --theme=garland
# Disable development menu block
drush block configure --module=menu --delta=devel
# or
drush block configure --module=menu --delta=devel --region=-1
Disclaimer: I don't quite understand the proper use for drush command arguments and options so i may have made wrong choice using options. I'd greatly appreciate it if some one explains to me the different use cases of both, i'll fix the script accordingly.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | blocks-679316-17.patch | 4 KB | seanr |
| #16 | blocks-679316-16.patch | 4.07 KB | seanr |
| #11 | block.drush-6.x.inc_.txt | 3.84 KB | AStroP |
| #6 | block.drush_.inc_.txt | 3.85 KB | litwol |
| #1 | block.drush_.inc_.txt | 3.3 KB | litwol |
Comments
Comment #1
litwol commentedAnd the file..
Comment #2
greg.1.anderson commentedI'd suggest updating to drush-HEAD to get the changes I committed just a few minutes ago ;) and then make commands "block-configure", "block-enable", "block-disable", etc.
Looks like a good concept; I'll review your patch later.
Comment #3
litwol commentedConcept of "enabling" a block is placing it in a specific region. Same for disabling a block is placing it in region <none>. I dont think in core its possible to have enabled block that is in region <none> or disabled block that is in visible region ...
For that reason i'm not sure it make sense to have commands such as block-enable block-disabled since they are misleading.
I can see block-disable work by ignoring passed in arguments and setting region to BLOCK_REGION_NONE. cant say the same about block-enable though...
What do you think about having block-configure and block-disable ?
Comment #4
robloachHaha, nice.
Comment #5
moshe weitzman commentedAt first blush, not so keen on this for drush core. We just can't maintain the CLI version of everything an admin might want to do related to core drupal. Multiply all that by 3 versions of core and you have a major headache. I'm OK with user commands, mostly because we have to routinely kill of spammers or register new site users (for closed sites). For me, block commands belong in an external project. After all, it aint hard to use pm-download + pm-enable.
Comment #6
litwol commentedMaintaining support for multiple core versions is certainly a pain. Is there a "drush extras" project ?
#2: Refactored commands into block-disable and block-configure
Comment #7
greg.1.anderson commentedI think that Moshe means that you can set up your blocks using the features module and then turn them on and off with pm-download followed by pm-enable.
Nifty.
Comment #8
moshe weitzman commentedI suggest making a full project for this Drush Blocks, for example.
Feel free to ask questions about the APi as needed.
Comment #9
kishorevaishnav commentedI hope this is only for Drupal 7 not for the older versions right ? Do you have any idea how to do it for older versions (Drupal 6) ?
Comment #10
greg.1.anderson commentedThis issue was closed; re-opening and moving to drush_extras for consideration for inclusion there (assuming it does not already have a home in some other module by now).
I think that the provided patch is for d6. Don't know about d7.
Comment #11
AStroP commentedI think #6 is for D7.
I replaced drupal_theme_initialize() with init_theme() and drupal_form_submit() with drupal_execute(). That way it seems to work for D6 - at least for me.
Btw. many thanks to litwol for this really useful extension.
Comment #12
greg.1.anderson commentedCommitted with minor adjustments and the addition of a block-show command.
Comment #14
ñull commentedWhen I use any parameter I get an error message. Example:
Must have to do with the disclamer. I use it with drush --version 5.8
Comment #15
greg.1.anderson commentedYes, this command needs its help options updated for Drush-5 compatibility, and should also be tested with D6, D7 and D8 to make sure it works in all environments.
Comment #16
seanrI got this working in D7 with drush 5.8. Patch against current dev attached.
Comment #17
seanrLast patch had a bit of testing cruft in it.
Comment #18
dwwConfirmed #17 looks clean and is working on a D7 site. I'd RTBC but I haven't tested in D6 or D8 as requested in #15. If I get a chance to test either, I'll update here.
Comment #19
greg.1.anderson commentedI must have thought I was in the Drush queue in #15; we don't need D8 for drush_extras. I'll retest on D6 and commit when I have time; bump this if I forget.
Comment #20
aiphesHi
i would to use it to manage blocks on a D6 multisite install.So i do this and i get error :
infos :
Comment #21
greg.1.anderson commentedSorry that this hasn't been committed yet. (?) Anyway, Drush now required commands to explicitly declare all options. As a workaround, until this is fixed, you can do as the error message suggests, and add --strict=0 to the commandline. You could even add 'strict' => 0 as a command-specific option for the block-configure command.
Patches welcome.
Comment #22
aiphesok thanks for explanation.
Comment #23
seanrgreg.1.anderson - have you had a chance to test #17 yet? Still applies cleanly, but I haven't had a chance to test it on D6. From my understanding that patch conforms to the current Drush docs. If not, please enlighten me as to what needs to change. ;-)
Comment #24
greg.1.anderson commentedNo, haven't tested yet, and I'm super-busy getting ready for DrupalCon Prague; I'll try to squeeze it in. I looked at #17 quickly, and it looks fine; maybe #20 wasn't using #17?
Comment #25
seanrYeah, that would be my guess.
Comment #26
aiphesi confirm that i didn't patch my drush extras module file ,but it works with :
drush --uri=http://provence-formation.vmdev block-configure --module=block --delta=34 --region=col_G1 --weight=-1 --strict=0Comment #27
greg.1.anderson commentedCommitted with some code cleanup; also, added a shorthand mode where arguments can be used in place of options in cases where doing so is unambiguous.
Note regarding the OP's disclaimer: the original implementation using options is proper. This implementation is always unambiguous; bash scripts that call Drush block commands should always use the option notation. For quick access to blocks via the commandline, though, it takes less typing to use the arguments in cases where you know that the specifier you wish to use is unambiguous. It is therefore useful to support both modes.
Comment #29
mauro.digiovanni commentedhello,
exists a comand drush to configuration blocks in drupal 8?
do I have to install the devel module?
tks;)