Closed (outdated)
Project:
Block Class
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
19 Jun 2015 at 20:02 UTC
Updated:
13 Jul 2018 at 00:06 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
devin carlson commentedA starting patch. There's probably a cleaner way to do this.
Comment #2
samuel.mortensonLooks like the index for $page has changed, re-rolling.
Comment #3
berdirWhat about opening an issue in page_manager to add a common base form id for those two forms so that form altering is easier?
Same here, would be nice if those forms would explicitly add the page/display to $form_state so that use cases like this don't need to mess with build info arguments.
Does this really work? I doubt it...
We possibly need to store this using the third party settings API directly on the page, keyed by display.block UUID or so. But that's tricky too, how will we access it then..
Possibly page_manager, (which needs config schema fixes anyway since what it does now doesn't fly) should provide a third-party-settings like place to store things per-block
Comment #4
s_leu commentedAdding a patch that covers suggestions in #3
This does in fact work. Also i don't see the need for this third party schema key as classes is actually pretty self explaining and in the right place as well. So i didn't change anything there.
Comment #5
rajab natshahTesting this patch.
Comment #6
berdirI can't imagine that this still works, will definitely need a reroll.
Comment #7
rajab natshahStill we can not see the CSS class(es) .. I used patch #4
I will try to use m patch #2
Comment #8
rajab natshahPatch #2 is not working too!!!
I will be working to have a working patch.
Comment #9
Yaron Tal commentedComment #10
mpp commentedIt's not clear how this could work but I guess the problem here is that page_manager is not adding the block ID. Not that we can't hack into page_manager to add another configuration.
Take this use case for example: a user creates a custom block and decides to give it a class using block_class. The user then adds this block to a page using page_manager.
It wouldn't make sense to create another setting for this block.
Comment #11
dobrzyns commented@mpp. I actually can see it making sense to have class settings for both the instance (when added using page_manager) and at the custom block level, where the two settings could be different. However, I'm not sure if the former should be implemented (at least to start).
The patch in #4 does not work for me either.
@berdir Makes excellent points in #3.
Comment #12
dobrzyns commentedLooks like this duplicates https://www.drupal.org/node/2710169
Comment #13
samuel.mortensonAt this point I think that it's a Core issue that Block Plugins can't generically be altered to allow for custom form elements and configuration. It should only take one alter hook and one submit handler to add Block Class support for all Block Plugin use cases (Page Manager, Panelizer, Panels IPE, Core Block Entities, etc.).
Comment #14
andypostComment #15
berenddeboer commented