Hey folks,

I've been building a site using Panelizer / Panels Pages and Fieldable Panels Panes, and while it's been working great on my environment, when I export my layouts, the FPP's are added by a subtype that has the FPID. Since FPPs are content and not exportable, this causes the pane to explode when I deploy to any other environment. Update hooks aren't much of a choice either since there may be an FPP with the same ID on the other end.

So I'm proposing FPPs get a machine name, and are exported with a subtype of fp_machine:%machine_name%:%bundle%. Panels will load the FPP entity via machine name, and if the FPP of that machine doesn't exist, it'll create one of the same bundle so that the layout is maintained gracefully. This patch shouldn't effect those who use UUID and export the full FPP via uuid_features, as UUID takes precedence over machine name.

There are a lot of moving parts to this, so some thorough testing would be appreciated. Patch is attached below.

Files: 
CommentFileSizeAuthor
#11 fieldable_panels_panes-machine-name-1996442-11.patch10.77 KBwbobeirne
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]
#1 fieldable_panels_panes-machine-name-1996442-1.patch7.25 KBwbobeirne
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]

Comments

Status:Active» Needs review
StatusFileSize
new7.25 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]

Attaching patch

Status:Needs review» Closed (won't fix)

If you use uuid module, fpp's will get a uuid which is much better than a machine name because nobody has to specify one. And I don't think having both is wise.

In my opinion, entities in general don't have machine names. They're too difficult to maintain and it's unlikely that they'll truly be meaningful. Just use uuid.module and you'll get all the benefits already.

Status:Closed (won't fix)» Needs review

Hey Merlin,

UUID doesn't fit the use case I'm describing, because UUID featurizes content in addition to configuration, which to me is against the principles of Features. This patch just ensures that the layout is maintained without errors, and keeps content in the database. Entity Boxes uses a very similar approach.

I suppose if this doesn't make it in to FPP, I could spin off my own module that provides a machine name mapping to FPPs. I just think that UUID is a band-aid to a bigger problem of site structure being stored in the database.

I don't know what you mean by featurize. It seems to me that just because it allows features to export the content (and really, I can't imagine it'll do it well) doesn't require you to use it.

What you describe is, really,a problem of entities. If you allow field API, you basically tie yourself to a database because of the nature of field api. The whole point of FPP is to allow field api so that you can create panes that are rich with content.

I think this patch adds a burden to users that is unnecessary and gets in the way -- adding a requirement of a machine_name is pretty strong. As you hopefully know, I'm a big proponent of machine names, and I really believe that this is not a strong case for them.

I have to agree with wobeirne on this one - being able to use features with FPPs would be a big help on the project I'm working on - with 7 developers passing around configuration, machine names would be quite helpful.

I definitely see that it's a problem of entities as a whole, not just FPP, but I think given that FPP is directly tied with the layout of pages, it's important that it can be exported (Either by features or just the import / export form) without completely killing the FPPs. Since this solution only creates a blank pane of that bundle, the separation of content & configuration is pretty well drawn.

Maybe my real issue is just that I'm trying to avoid UUID as a whole. It's pretty bloated, and affects way too many aspects of my site to want to deal with it. It also makes it so there's no uninstalling it without a massive headache, since it changes the subtypes of panels (And the code in exported pages) to use UUID. This seemed like a good middle ground, but I can see why you wouldn't want the added burden of having to fill out a machine name for users. Perhaps having the field auto-fill and having an edit link would make this an easier transition from what users are currently used to.

Machine Names alone will not make fieldable panels panes any more palatable to features than UUIDs already do.

But the patch isn't just machine name, it adds the FPP bundle to the panels_pane subtype. That allows it to create a new blank one of the proper type. From the original post:

So I'm proposing FPPs get a machine name, and are exported with a subtype of fp_machine:%machine_name%:%bundle%

I'm sorry, what's that got to do with anything? I can read the patch. It doesn't do anything that UUID doesn't already do, at the cost of forcing people to come up with unique machine names that most users don't want or need. You can NOT ignore that cost.

Because UUID still doesn't provide a fallback for when an FPP of that UUID isn't found, you'll still get the broken / missing handler pane that's completely useless. This patch does, by providing you a pane of the same bundle for you to edit. And if we make the machine name field just auto-fill to something like %bundle%-%fpid%, users won't have to change their workflow at all unless they want a human readable machine name.

StatusFileSize
new10.77 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]

Attaching a new patch because the last one had a few mistakes & omissions.

  • Machine name field is now added in fieldable_panels_panes_entity_edit_form. I was adding it in the panels form alter, so it was possible to save a machine nameless panel via the regular add / edit form.
  • Machine name is now exposed to views.
  • Machine name now displays in the admin FPP list.

One known bug I've found is with Panopoly Magic, the preview function doesn't work. Because it runs through form validation, and saves a new FPP, it can only generate one preview. I don't really think this is a fault of FPP though, and more of the way Panopoly Magic handles it. The fact that it leaves behind all these unused FPP instances in the database indicates to me that's kind of a silly solution for generating FPP previews.

Issue summary:View changes
Status:Needs review» Needs work

At the very least, the bundle should be before the machine name. Furthermore, I'd suggest changing "fp_machine" to "fpp", thus the ID would be "fpp:[bundle]:[machine_name]", which makes more sense. It should also probably optionally default to using ctools_uuid_generate() if left blank, which would then also boost the module's requirements to CTools 1.4+.

Ok, rather than defaulting to UUID, the machine name should automatically work off the 'title' field and depend upon #1588882: Use title for entity label and make required.

Status:Needs work» Closed (won't fix)

You know, could this be taken a step further to be turned into a generic Panels/Panelizer add-on that could work with all entities, i.e. an alternative to UUID? I mean, what's the difference between embedding an FPP object or a node - in both cases you end up with the same difficulty with non-deployable system.

Based on this, I'm pushing it back to "won't fix" as I don't think the problem belongs in FPP, I think it's far more generic and should be handled as such.