Ability to set variant machine name in Panels UI

Naming of contexts? I don't understand what this really means or what it affects?

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).

Really, the right thing to do here would be a UUID implemention.

Subscribing.

Subs

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.

I *think* this is what is meant by the OP.

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.

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.

Forgot to attach the patch in #10. sorry

The patch doesn't solve the feature request.

I think that'd be better off as a separate issue, I think.

In #4 there is a clear merlinofchaos states that UUID is the way to go, or am I missing something?

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.

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)?

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.

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?

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!!

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.

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.

Subscribing.

The patch from #20 probably needs to be rerolled.

This patch appears to be functional. It expands upon #20 to provide a new Machine Name field that is then appended to the task name should it be filled in. The current scenarios explain it in more detail:

• The name defaults to "{$task}__{$handler}", e.g. if the task is 'node_view' and admin title is blank then the name will be "node_view__{$handler}". This is changed from the current codebase in that it separates the task and handler with two underscores, to help differentiate them when exported.
• If the machine name is filled in then the name will be changed to "{$task}__{$machine_name}".

Reviews would be appreciated :-)

it would be great to be able to change machine name of existed variants either.

I'm using an old version of ctools, so I updated ctools module manually according this patch, the setting variant machine name on adding new variant works fine.

The patch works fine in our project.

@rogical, if you use features (I hope so) you can solve that by "Search & replace" of the configuration. Imho, adding an edit-behaviour would be some more work, that should be done in a separate issue.

Added a new patch based from #2129033-18: [Meta] CTools 7.x-1.4 release from Damien. This will generator a UUID if a machine name isn't specified.

PS. Make sure you test this patch on the ctools sandbox. listed in the above issue, otherwise it may not apply cleanly.

The last comment says to apply this against the sandbox in the other issue, but that was nearly a year ago and that issue is closed so I tried applying it against the current ctools code. It did apply with no issues but I can't get it to work.

First, I tried simply re-generating the feature after applying the patch (and CCing) to see if anything changed and nothing had. Then I tried editing the variants looking for the new form field but didn't see it. I looked closer at the code and it says it's on the "add_form" so I thought maybe it only showed up on new variants but creating a new variant didn't have it, either.

I'm going to leave this at "needs review" because it's quite possible that I'm just missing something here that maybe someone else would get. At this point, all I can say is that the patch does apply cleanly to the current ctools code.

The patch applies cleanly, but it does not appear in its current form to solve the feature request of allowing manual overriding of the machine name via UI. After investigating, it appears that this is because the machine_name field has been given a source attribute, which causes it to not display a field, but rely on the source field for generation instead.

If I am understanding the feature request, hopefully the attached patch will move us forward.

I tested out the patch in #32. It applies and the ability to add a machine name shows up on new variants. When the variant is exported, I get "$handler->name = 'page_test_2__machinename';" and "$handler->conf = array([snip] 'name' => 'machinename',);"

Note: The new form item still does not show up on existing variants. If that is not the intent, then this still needs work. If it's only supposed to be on new variants, then it works fine.

This would greatly help out distributions using panels :-)

However, there are some things I'd like to see fixed before this gets committed:

1. Machine name should automatically get typed out, like what you see on node-types add page
   
2. You should be able to edit the machine name for existing variants.

Otherwise it looks good!

I'm going to give this a shot this afternoon.

I think I may have figured this out. This patch works with customizing new machine names and editing old ones, including legacy generated ones from existing variants.

The machine name editing part of this solution will require separate patches from panels, panelizer, and any other module that supplies a context plugin for a new variant type. I'll go ahead and roll one for panels and link it back here.

Lets wait to get this in until I have the panels patch that implements it nicely.

Panels patch submitted here: #2410293: Add ability to edit machine names

Panelizer patch here: #2410363: Add ability to edit machine names

Testing instructions:

1. Before applying the patch(es), install the dev version of each module and set up some custom page variants, using core page manager (HTTP response code), panels, and panelizer variant types if possible (easier to test all three at once).
2. Apply the ctools patch, as well as the panels and panelizer patches if you're testing those too.
3. Visit the general tab for each of your existing variants. You should now be able to edit the machine name of each one.
4. Verify the legacy variants still work as expected.
5. Create some new variants, you should be able to customize the machine name during the variant creation process, and edit them after you've created them.
6. You may notice when you save a variant with a new machine name you're being redirected to a path that includes the new machine name. If the variant works at the new path, and the old one doesn't, that's a good indication that the machine name has successfully been changed.
7. You can also verify the updated machine name by exporting the variant.

I tested this along with Panels and Panelizer as per the instructions and it works great! When I applied the patch, it said it was offset by 10 lines so I am uploading a new patch just to fix that. I didn't make any other changes to it so please don't give me the credit for the patch.

Leaving at needs review just to be sure I didn't mess anything up with the new patch.

Thanks for the reroll Michelle! I've rolled one more time just to fix the spacing issue identified by Damien in the Panelizer version of the patch (#2410363: Add ability to edit machine names), which has already been committed. As long as this patch goes green I'd say this is RTBC.

Looks good to me, and works without the panels patch.. well it at least shows the machine name, even if it cannot be edited yet ;)

Committed.

Does this need to happen for clone too?

@joelpittet: Please open a new issue so we can review what, if anything, is needed for the 'clone' action.

@joelpittet: forgot to say - thanks for bringing that up.

Thanks I will:) FYI this error brought me here: #2445203: Error trying to clone a variant

Follow-up created here: #2477637: Ability to set variant machine name in Panels UI for Cloning and Importing variants.