Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I've been trying to debug this for a few hours and can't seem to figure it out. When I enable the skinr_panels module with skinr_ui, it does indeed put contextual links for all the panes on the page, but the overall panel page seems to be linked to the first pane element. In fact, when I click the "Edit skin" underneath the "Edit panel" link (for the panel page) and style the skin, it turns out that the first pane of the panel is what was actually styled.
This is for the entire panel page:
But styles the first pane element:
Which you can see also has it's own edit skin link:
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | patch_commit_0c754596e976.patch | 3.35 KB | moonray |
Comments
Comment #1
moonray CreditAttribution: moonray commentedWhat's the URL it creates (for each panel/pane edit skin link)?
Comment #2
markhalliwellThis is the url it generates for all edit skins in the pics:
../admin/structure/skinr/edit/nojs/panels/pane____new-1/configure%3Fdestination%3Duser
Comment #3
markhalliwell@moonray: Any chance you know what this might be?
Comment #4
moonray CreditAttribution: moonray commentedLooks like you're trying to use panels that are in code. As stated on the home page and in skinr_panels this is not possible due to some limitations in panels. See #1160924: Undefined property: stdClass::$did in skinr_panels_skinr_elements() (this is now marked as a duplicate of that issue).
Comment #5
moonray CreditAttribution: moonray commentedNote: there's a workaround at #1292662: Skinr throws multiple errors on home panels page.
Comment #6
markhalliwellActually the whole
$didissue is a separate issue, that I'm aware of. What I'm talking about is that the panel container (overall wrapper for the panes) is getting the same url as the first pane. So when I try to edit the page skin, it only skins the first pane. Please re-read my issue and notice the contextual outlines in the images.Comment #7
moonray CreditAttribution: moonray commentedAfter lots of digging in the code (and trying to fix this) I finally remembered that we dropped support for panel display (the panel page) elements.
There are several issues surrounding this problem... panels being not flexible enough to handle our use cases being chief among them.
I'm not sure why we still have code floating around to add links to the panel itself; we need to remove that.
Is there a good use case for allowing a panel to be skinned, vs using its surrounding container (usually a block or region)?
Comment #8
moonray CreditAttribution: moonray commentedAttached patch has been applied already, but is being posted as reference. It removes legacy code related to skinning of panels displays.
Comment #9
markhalliwellActually, no, you cannot skin the panel page's containing element. It is the system main block, which would style the block site-wide. Just like blocks and views, the panel page container should be able to be styled separately based on the unique id of the panel. Granted after also attempting to fix this issue myself and diving in to Panels and CTools APIs and code, I wasn't able to find an easy solution either.
I agree that the code should be taken out ATM, however I wouldn't classify this issue as "fixed". The problem still remains and that don't think that this should be closed just because it's impeded by Panels (or Ctools). I will do some more research with both and see if we can't get some patches implemented in either module to get this particular issue resolved.
Comment #10
moonray CreditAttribution: moonray commentedI agree that we would like a fix form the panels end, but you can achieve your goal by applying the skins to the surrounding block, and (with the newly included skinr_context module) limit which page it appears on. Not an elegant solution, but one that works.
Comment #11
moonray CreditAttribution: moonray commentedClosing. Though the solution isn't ideal, it should work.
Comment #12
markhalliwellThat's fine, TBH, I never liked panels anyway. This was for a very particular use case anyway. I typically use display suite when possible.