Posted by greg.harvey on May 31, 2010 at 8:46am
25 followers
| Project: | Chaos tool suite (ctools) |
| Version: | 7.x-1.x-dev |
| Component: | Page Manager |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
Hi,
I'm not sure if this would be a Panels issue or a Features one. There's some background here: #740074: Exported panel variants as features are incompatible with each other.
If the Panels UI allowed for the naming of contexts then you could prevent them from over-riding one another and conflicting in the Features module (and there may be other use cases too). I'm actually working in D6, but I guess D7 would be the place to raise a feature request like this.
Anyway, just wondering if you think this is something Panels should do, or if Features should be responsible for managing conflicting Panels context names?
Comments
#1
Naming of contexts? I don't understand what this really means or what it affects?
#2
Hmm, problem is neither do I! ;-)
Ok, in Features, when you export Panels pages, you get some "things" exportable. For the node view pages there's one called 'node_view_panel_context' under Page Manager, for the term view page there's one called 'term_view_panel_context', etc. The problem comes when more than developer/feature contains a variant of the term view/node view/etc. (choose your poison). All of them are called the same, which causes conflicts amongst features, SVN commit battles and all round fist-fights amongst development teams. It's easily worked around by renaming this string to something else, something unique, in your Features include files, however I don't understand:
1. Where these strings are generated (Features or Panels)?
2. If it's possible to change them without fiddling with the code?
So this feature request is, I suppose, more a support request that could become a feature request, or vice versa! I haven't worked out yet if this is something for Panels or something for Features to resolve (or maybe even neither but actually CTools instead!)
I apologise if this is a bit garbled, but it's because I don't really understand what I'm looking at. All I know is these 'context' strings cause us deployment pain, we can fix it in code but it would be nice to be able to define 'node_view_panel_context' (by way of an example) as something else, e.g. 'node_view_panel_context_greg' in the UI, somewhere, so they don't cause us pain any more! =)
Hope that's a little clearer...
#3
Aha! Ok, those are the auto generated names of variants. Names of variants are more or less invisible; when exporting them to share, they do need to be changed or they will conflict. Perhaps features needs to be made aware of this and understand how to change the name, or maybe Page Manager needs some export option to tell it to change the name so that the variant can be exported for sharing.
You can change these names safely (be sure to check for other instances of the name and you'll be fine).
#4
Really, the right thing to do here would be a UUID implemention.
#5
Subscribing.
#6
Subs
#7
You can get it to work by changing the machine name of the exported variant, but then there is a problem when it comes to running features-update, since when Features/Ctools attempts to recreate the feature, it reverts to using the node_view_panel_context machine name again.
#8
I *think* this is what is meant by the OP.
#9
After editing the handler name, reverting the feature makes everything work properly. Make sure your feature is up to date before doing this.
Also note, "editing the handler name" means changing three things:
In .info:
features[page_manager_handlers][] = "VARIANT_NAME"In .pages_default.inc:
$handler->name = 'VARIANT_NAME';$export['VARIANT_NAME'] = $handler;
It still would be very cool if this could be done in the UI.
#10
Moved this issue to ctools, as the variants is provided by page_manager which is in the ctools module.
This patch checks if the module called "UUID" is installed, and if it is, it will set the variant name to a generated uuid instead if the "original".
The "original" function still exists as a fallback is UUID isn't installed.
#11
Forgot to attach the patch in #10. sorry
#12
The patch doesn't solve the feature request.
#13
I think that'd be better off as a separate issue, I think.
#14
In #4 there is a clear merlinofchaos states that UUID is the way to go, or am I missing something?
#15
1. I'd recommend that CTools itself have a UUID generator built in rather than relying upon another module for this.
2. I disagree with merlinofchaos on the usefulness of UUID vs something that at least references the duty a panel object is used for, but it's his module :) Maybe an alternative would be for the default to be based off the manually entered name, a UX pattern that is used throughout Drupal & contrib? Lets move this discussion to #1362624: Improve naming convention used for variants, possibly with UUIDs.
3. The original request was for a field within the UI to change the automatically generated name be manually changed. Rather than bumping this request to another issue, I spun off the discussion of changing the default variant ID to its own issue: #1362624: Improve naming convention used for variants, possibly with UUIDs
So, back on topic: allowing the variant name to be manually overridden via the UI rather than having to manually hack it via an export.
#16
Why not just prefix the variant/handler name with the feature module name? That would protect from namespace collisions? Maybe CTools could provide a hook to see which modules "implement" a
node_view_panel_context(or term or user, etc)?#17
For #15, The problem with #2 is that variants do not typically have manually entered names. In most cases people leave the name they have. The fact is that I can't find anything unique to build a name off of easily.
Allowing the variant name to be overridden by the UI would be a good workaround but it does not really solve the problem; it just lets people who are in the know fix the problem a little more easily.
Also, one problem with this solution is that variants do not have any common UI. Some variants have absolutely no UI. THough, I guess for those variants it also does not really matter that much. It mostly only matters for the panel_context variant. Hm.
#18
In fact, we do have $object->export_module but I'm not sure that actually helps us. Because what really needs to happen is that variants need to be renamed on export.
However, maaaaaaaaybe the bulk export tool can help us here! Because when an item is being exported I *think* we might actually know the name of what's exporting it.
However, renaming it without reverting it will then cause duplication.
Which means we probably actually just need to have some kind of features integration that does what we need to do. When a variant is featurized, rename it and delete the original?
#19
#20
So... this popular thread is stuck in an impasse. Let's see if I can give it a push!
About #18, seems like a looong way around! And even using the $object->export_module ... are we 100% sure it will resolve the issue? Can't two different variants be exported to the same module by two teams working in the same project?
About #17, "Allowing the variant name to be overridden by the UI would be a good workaround but it does not really solve the problem; it just lets people who are in the know fix the problem a little more easily.".
I think this workaround is more about easily preventing the problem to happen, so that a further fix won't be needed. Ok, it doesn't avoid collisions 100% sure, but seems like a fair step forward and if you choose wisely the variant name, you can be comfortable about this problem being avoided.
I'm submitting a testing patch, which simply simulates the UI I'm thinking about, by enabling the machine-name for variant creation. Just to be sure I've understood correctly the initial idea!!
#21
Just ran into this situation myself.
I have 6 node_view pages using different views for displaying my node types. Ended up with the following variants:
node_view_panel_context
node_view_panel_context_2
node_view_panel_context_3
node_view_panel_context_4
node_view_panel_context_5
node_view_panel_context_6
Only "node_view_panel_context" showed a conflict in features. I'm assuming because it is the default for nodes? Since the others are numbered, I guess something is checked for duplicates but is not catching the first?
Anyway, I used the solution in #9 and altered things by hand.
#22
Has there been any movement on this issue? It looks like Merlinofchaos agrees that this is worth a fix. But the last thing done was a simulation posted 6 months ago.
#23
Subscribing.