Posted by tim.plunkett on January 3, 2013 at 7:41pm
6 followers
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | views_ui.module |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | Block plugins, Blocks-Layouts, VDC |
Issue Summary
In #1535868: Change notice: Convert all blocks into plugins, we did a straight port of the Views block integration.
With plugins and derivatives and all the new stuff, we'll want to revamp our code.
Specific things to target:
- The naming of \Drupal\views\Plugin\views\display\DisplayPluginBase::viewSpecialBlocks()
- The $type parameter of viewSpecialBlocks(), which is currently always 'exp' for exposed blocks
- Maybe make views_add_block_contextual_links() a method, or find a way to move that to contextual.module
Comments
#1
#2
#3
There really seems no use-case for anything else then exposed forms, and if someone needs it, nothing prevents him from doing that in any kind of other custom code.
#4
There's still a reference to special_block above views_add_block_contextual_links()
#5
Good point, thank you!
I would be really surprised if there would be test-coverage for these kind of blocks.
#6
I think the only thing left is #3 from the OP, making views_add_block_contextual_links() a method on ViewsBlock
#7
Oh totally forgot that, did I talked about working at night before ;)
#8
#9
Rerolled.
#10
Fixed some small bit.
As you didn't made any other suggestions is that RTBC?
#11
Yes, I believe it is!
#12
+++ b/core/modules/views/lib/Drupal/views/Plugin/block/block/ViewsBlock.phpundefined@@ -78,9 +78,35 @@ public function build() {
+ // Do not add contextual links to an empty block.
+ if (!empty($output)) {
+ // Contextual links only work on blocks whose content is a renderable
+ // array, so if the block contains a string of already-rendered markup,
+ // convert it to an array.
+ if (is_string($output)) {
I'm surprised that Views has to check this for its own blocks, can they really be both?
+++ b/core/modules/views/lib/Drupal/views/Plugin/views/display/DisplayPluginBase.phpundefined@@ -2640,20 +2640,21 @@ public function getSpecialBlocks() {
+ if (arg(0) == 'admin' && arg(1) == 'structure' && arg(2) == 'views') {
+ return;
Couldn't this use menu_get_item()?
#13
Good points, here is a new patch.
According to b261004a4825e1b6eb1398e849ef3729acd4de97 this went in, so this just changes this specific parts of it.
#14
Oh hell yes, this patch removes two of my least favorite parts of Views :)
#15
The last submitted patch, drupal-1879256-13.patch, failed testing.
#16
Ahh, when the drupal_render() is removed, it's not built fully.
This "fixes" it, but seems like overkill (those methods have an isset at the top of each in case they've run before, so its not too bad).
@dawehner, I hope you have better ideas :)
#17
The last submitted patch, vdc-1879256-16.patch, failed testing.
#18
#16: vdc-1879256-16.patch queued for re-testing.
#19
The last submitted patch, vdc-1879256-16.patch, failed testing.