I'd like to add a 'Add skin configuration' form which will let you edit any existing element on the site (that is implemented for Skinr).
This will help us work around most of the issues with Panels and Views without having to go all that way and do the full rules revamp (which will be pretty massive). We can reuse that code once we decide to implement the rules revamp.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | patch_commit_ecef4bacc3d7.patch | 28.08 KB | moonray |
| #6 | patch_commit_0f3cb537c6af.patch | 28.75 KB | moonray |
| #1 | patch_commit_1dec041b4fb1.patch | 10.41 KB | moonray |
Comments
Comment #1
moonray commentedThis patch adds a link to admin/appearance/skinr which allows you to 'Add skin configuration'.
Implemented for blocks, comments, nodes, views (panels is still too much of a mess... trying to wrap my head around that... again).
I'm not entirely happy with the language used in the interface. Also, this should include some JS like Fields UI
has to hide all the irrelevant Element options once you selected your Type.
Comment #2
jacineUsing contextual links would have been nicer, but unfortunately that's not possible. According to @moonray there is no context:
Given that, I think this patch is ok once all of the functions are documented and the validation portion is added.
Comment #3
moonray commented@jacine: Just to clarify... we ARE using contextual links. We're just not using the recommended hooks to add our links to them (which is what the above quote was about). The only elements we can't use contextual links on are panels' display and panels' regions.
Comment #4
jacineErr, yeah. I meant
hook_contextual_links_view_alter()Comment #5
moonray commentedHere's a functional patch. It includes some much-needed tests for our functionality plugins (including panels and views) to ensure our contextual links are properly added, and that the new hook_skinr_ui_element_options() returns the expected data.
The patch still needs integration with the panels_mini module.
Also, I got stuck writing the panels_node integration tests due to my inability to programmatically add panes to the panel node (see #1154468: Need a way to add content to panel node without using ajax). Any help there would be appreciated.
Comment #6
moonray commentedAnd the patch, of course...
Comment #7
sunFrankly, I'm not convinced that this patch is the right thing to do at this point in time. It adds a lot of custom and module-specific logic to Skinr -- whereas I actually hoped that our intention would be to decrease the amount of custom code.
It is definitely going to hinder progress on the further API changes that we need to do.
That's not to say this patch or idea would be entirely wrong, but for me it feels like trying to stick a piece of fancy on an ugly pig.
should trigger here.
_block_rehash() is not only not cached, but additionally, it's purpose is to rebuild and update the {block} DB table.
Powered by Dreditor.
Comment #8
jacine@sun do you see an alternative way of accomplishing it? This particular issue has been a problem for over a year, even with Drupal 6 before using contextual links. If you have any suggestions, they'd be appreciated. :)
We need this working though, so we can't wait around for perfection.
Comment #9
vrajak@gmail.com commentedTested the patch in #6 as working with general skins and panels, but I didn't extensively tests panel usage, just creating a panel page and using a skin there. I didn't try using mini panels since you said it still needs integrating.
Trying to add a view was initially giving me a fatal error until I updated the views module, then it was fine. Is there anything else I should try and look for/test here?
Comment #10
BenK commentedSubscribing
Comment #11
moonray commentedRerolled and updated the patch to work with the latest version. The call to _block_rehash() has been removed; it's been replaced by a custom function that replicates a lot of its code, but excludes the block table rebuild and includes some caching.
Comment #12
moonray commentedCommitted the patch.