This patch adds a link to edit the style of a pane using the In Place Editor. Thankfully, this turned out to be pretty easy since the callbacks are already there!
Haven't fully tested it, but I plan to today.
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | panels_ipe_style_plugins.patch | 824 bytes | populist |
| #3 | 881562_panels_ipe_style.patch | 830 bytes | blackdog |
| panels_ipe.patch | 807 bytes | jon pugh |
Comments
Comment #1
codewatson commentedWorks perfectly!
However i don't understand this part of your patch:
'title' => isset($content_type['edit text']) ? $content_type['edit text'] : t('Style'),With that any custom content panes the edit style title become just "Edit" which means you end up having 2 "Edit" links? Other pane types get a title of "Style" so i'm not sure why you are making custom content panes different?
Comment #2
codewatson commentedOh i see, that line is basically copied from line 77, which for custom content panes makes their edit link say "Edit" where as the other pane types become "Settings". I don't think that is necessary for this case, the style title should be the same no matter what.
so you could change that line to be:
'title' => t('Style'),Comment #3
blackdog commentedUpdated patch as to the remarks in #2. Works with all core styles.
Ran into issues though with Skinr (6.x-1.6):
Set a Style in the "regular" UI
Updates the Style in IPE
Style still appears, but when editing in IPE again, the value is not filled. Like it's caught in limbo somehow...
Might be issues in Skinr, or it's implementation, as it seems the variable isn't updated. Any ideas are greatly appreciated as this is a great feature!
Comment #4
blackdog commentedAny ideas on how to move this forward?
Comment #5
jason.fisher commented+1
Comment #6
populist commentedI think this would be a really cool addition to the Panels IPE functionality. With the right combination of styles or Skinr, you could make a really neat end user administration experience.
Comment #7
populist commentedAs a followup, this works less great in Drupal 7 despite the implementation looking to be similar. The two major issues I saw are:
1.) The style link is inconsistently applied. In my test, the two custom content panes had the style link but the standard breadcrumb pane and a custom content type I defined did not.
2.) When I clicked on the style link, it shows up with the right selection but when I went to save I got this error:
An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /panels/ajax/ipe/style-type/panel_context%3Apage-front_page%3Apage_front_page_panel_context/pane/1
StatusText: OK
ResponseText:
Fatal error: [] operator not supported for strings in includes/common.inc on line 2319
Comment #8
mropanen commentedThis would be the most awesome thing ever!
Comment #9
primsi commentedI think that would be a great feature and a nice addition to IPE functionality. It would be good to know what the maintainers position is regarding this.
Comment #10
Letharion commented@merlin, do you think this is a useful feature?
It sounds like a useful feature request to me. The patch should be made against D7 though, as we want to apply it there first, and then backport to 6, instead of the other way around.
Comment #11
merlinofchaos commentedYes, definitely a useful feature and something on the list of things we would like.
Comment #12
Letharion commentedGreat, so the next step is a D7 patch :)
Comment #13
populist commentedHere is an updated patch to add the style plugin in IPE for Drupal 7. It seems to work OK - testing this week - but there is an open question around how the CSS gets loaded if it isn't already loaded since it appears (from the rounded corners plugin) that the CSS wont lazy load and needs to be loaded in advance.
Comment #14
populist commentedThis patch is subsumed into large IPE redesign effort at #1471190: Redesigning the Panels IPE Interface
Comment #15
merlinofchaos commentedThis went in as part of the IPE redesign patch.