Feature request: subgroups

[CNG]

No idea what kind of a technical challenge this would be, but it would be great to be able to have variable numbers of groups of fields within an existing group.

[padawan]

Could you give an example / rationale of this please?

[CNG]

Let's say I'm using a field group products that contains fields name, description and image and using these to display a list of a variable number of products. I want to add some arbitrary bullet points to be associated with each product, perhaps for links to related products.

Ideally I would add to products a subgroup related_products that would contain the fields text and url. Since I can't do that, I currently need to do something like adding to products the fields related_1_text, related_1_url, related_2_text, related_2_url, related_3_text, related_3_url, etc., but I would then be limited to the arbitrary number of fields I decide to define.

Let me know if that was too vague of an example.

[meancode]

I think he just means a group within a group. This would be really helpful in a number of different applications.

[padawan]

It's clearer thanks. I initially thought to mimic the MT5 UI for creating and ordering hierarchical categories, but for groups and fields (merged in one screen). This could still work with sub-groups, though I haven't learned enough about the code to make a guess at how difficult it would be to implement.

[CNG]

OK, well at least you see what I'm trying to do. I just wanted to bring it up in case you or anyone else happens to want to try implementing it. :-)

[padawan]

Sure. My idea is to get rid of the separate screens for fields and groups, as well as the need for the arrows and the group drop-down in a field. Taking this FR into account, you would go to a screen where you can add groups and fields and order them using drag-n-drop exactly like you currently do with categories. If you place a field under a group, it becomes part of that group. If you place a group under another group, it becomes a sub-group. As for their properties I'm not yet sure (groups can easily be edited within that page, but I would favor a separate edit screen for editing individual fields, I'm not a fan of the current collection of giant pop-ups crammed into a single page, it's too easy to make a mistake while editing multiple fields).

[CNG]

That sounds spot on!

[padawan]

Coincidentally I just received a client request today that would require nested groups of fields :-). Unfortunately he needs it for yesterday :-(.

[meancode]

Well of course! I can tell you there have been a number of instances when nested groups would have really been great to have. Keep in mind though, that it would be most useful if they worked for both MT4 and MT5.

[padawan]

I can change my mind if you give me good reasons to, but to me since both MT4 and Melody are dead, and none have the listing framework I need to create the UI I have in mind, I want to focus on MT5. One of the rationales for me to work on this MT5 port is precisely to remove one reason to not migrate to MT5! It's also an issue of time, it feels like a waste of time to me to bother with MT4 (I haven't done any new site with it since MT5 was released).

[CNG]

I did want to keep compatibility for the sake of not having two parallel Field Day repos that would get out of sync with updates... perhaps we could have subgroups by an MT5 only feature... again, no idea how modular the new functionality would be and if it would be something we could easily expose only to MT5.

I say focus on 5 for this feature if you do it, and we can look after it's done what was involved and see if making the plugin MT4 compatible would be too much work.

[padawan]

OK, I need to explain further what I have in mind. I don't plan to make any further work on this FD fork beyond making it work with MT5 and behave exactly as the current FieldDay for MT4. Beyond that, I plan to create a brand new plugin that will be MT5 only and quite different in terms of UI and tags (removing cruft and weirdness, I want the look & feel to be as close to MT5 and Custom Fields as possible).

[CNG]

How do you envision this affecting someone with a large installation currently utilizing Field Day if they want to upgrade to MT5 and use subgroups, for example? Are you saying you'd only have subgroups in the new plugin, which would not be backward compatible with Field Day in regard to template markup and database structure? So if someone needed subgroups, they would have to convert everything to the new plugin?

I'm not necessarily against this, I just want to fully understand what you're planning.

[padawan]

My idea is to provide a migration path, either through a command-line script or from the plugin itself. But you should be able to run both plugins alongside and the new one would never change the existing FD data.

To the (existential) question whether to continue on that fork or create a new plugin from scratch, I lean on the later option. May be I'm wrong but it feels better IMO. I need to write things down, this doesn't seem like the best venue for a discussion ;-).

[CNG]

Haha, OK, well that sounds good to me!