Weekly update: Combo now released! 18 Dec 2020

[ryan]

I’ve just released the first version of the ProFields Combo field and it’s now available for download in the ProFields support board download thread! Rather than writing a long post today, I’ve instead focused on writing the Combo field documentation. The documentation page includes a lot that you may already know from previous posts, but it also includes a lot of new details that haven’t yet been posted. Please consider this version to be a development/beta version. It’s the first release and hasn’t had a lot of testing yet, so consider it not yet ready for full production use. Though if you get a chance to test it out, please let me know how it works for you. I appreciate any feedback you have. 

A couple things I haven’t yet tested thoroughly enough yet are exporting/importing of Combo fields or pages using combo fields. I also haven’t done enough testing in FormBuilder yet. So I’d recommend avoiding use of PW’s field or page export/import functions with this, or using in FormBuilder, at least for a few days. By next week I will have tested those things and made any necessary updates. Thanks for reading and have a great weekend!

[Robin S]

Thanks for this great new module @ryan!

The Combo module seems in some ways like an enhanced ProFields Textareas: both modules provide multiple inputfields that look just like real separate fields in Page Edit but are contained in a fieldset and are actually just one field behind the scenes. As you've said, this is great for efficiency because it reduces the total number of fields needed for a project. In some big sites I've worked on the ProFields Textareas module has been fantastic because it's reduced the number of fields I need by 50% or more. The new Combo field looks like it will be even better than Textareas so I'm excited to start using it.

But there is something that holds Textareas and Combo back from being even more useful, and that is the fact that all the subfields have to be rendered together inside a fieldset. In my experience there are many situations when you have fields in template that technically could be catered to by Textareas (and now Combo) but the problem is the layout in Page Edit:

1. The subfields of the Textareas/Combo are not sufficiently related to each other that they should be grouped together inside a labelled fieldset. What I mean is that as a developer you identify fields whose technical requirements make them a good fit for Textareas/Combo, but the fields don't conceptually belong in the same group in the mind of the client/administrator, so you don't want them all grouped together under one parent fieldset label.

2. You have some other separate fields (e.g. Repeater, ProFields Table) that you want to intersperse between the Textareas/Combo subfields.

The consequence of these two problems is that it either isn't practical to use Textareas/Combo in some situations where it has the potential to avoid a lot of extra fields, or you end up creating many more separate Textarea/Combo fields than are necessary or desirable from a technical point of view.

You might remember that I raised this in the Textareas forum, and ended up making a hacky module that rearranged the Textareas subfield inputfields in Page Edit so I could get around the two issues described above. But what I'm dreaming of is having a core or official ProFields solution to this...

What I'm imagining is an enhanced version of the core template editor. If a field is added to a template and the fieldtype reports that it renders multiple subfield inputfields (Textareas and Combo are the only fieldtypes I can think of that do this, but perhaps more fieldtypes will fit the bill in the future) then those subfields become individually sortable in the template editor. So it would be possible to make a layout in Page Edit that went something like...

• title
• combo.text
• repeater
• combo.textarea
• table
• combo.integer
• etc

Here's a screenshot of the interface of my hacky module to show the general idea - although this is actually separate from the template editor and is therefore not nearly as good as it could be. (And before anyone asks, this module is way too buggy and hacky for me to release publicly, hence my request for a solution from Ryan).

I know this wouldn't be a simple thing to implement but I think it would make ProFields Combo and ProFields Textareas hugely more useful. Thanks for considering!

[adrian]

Huge thumbs up from me too @Robin S

[HMCB]

@ryan something I see missing in the Requirements for Combo Fields is a license for ProFields. Or am I mistaken?

[Pete]

+1 for being able to place the fields anywhere in the template with other non-combo fields in between.

And if they don't have to all be loaded all at once into memory or that can be configurable (I think that was something mentioned on last week's update) all the better.

Those two changes would actually enable me to switch from using custom tables for some situations where the number of fields is simply far too large to combo fields.

[Pete]

I guess to back up my thoughts with a scenario might be useful - your example for addresses is simple enough, but I have a scenario where I've got a directory type site where each entry has maybe 40 fields and it's specific to that template for that type of item being listed.

At the moment I'm using 40 different fields and it seems a waste, but some of the fields are repeaters or files and I'd love to switch to combo field as long as I could order the fields logically how I want in the template as Robin has suggested. Otherwise, to echo what's already been said, the only way around it seems to be multiple combo fields with the repeaters/other fields in between which feels a bit hacky.

[Klenkes]

@ryan You should add UIKIT Theme to the list of requirements. As I just discovered, Reno doesn't agree with Combo, unfortunately.

While it can be installed, field creation doesn't work.

[adrian]

I just wanted to add some more thoughts to @Robin S and @Pete's comments. Flexibility is the key thing here. Imagine setting everything up for a template using a combo field, only to discover you need an image (or other unsupported fieldtype) in the middle of the combo's subfields. This is particularly important once the site has content - all of a sudden it becomes a nightmare to fix. This is one of the reasons I haven't ever used the Textareas Profield and I can see being just as wary about using the combo field for the same reason - you just never know how requirements will change over time. Being able to quickly tweak the content types and layouts in templates is why PW is so awesome in the first place.

[ryan]

When I talk about the goal of ProFields being to reduce the number of fields necessary, I don't mean that to stretch into “at all costs”, going beyond what would be logically related in a fieldset or object, or stepping outside the responsibility and purpose of fields. All of the ProFields are focused on reducing field usage for cases where logically grouping them makes sense: visually, semantically, structurally. ProFields are not intended to hack around, change the meaning of, or blur the lines of what’s provided by ProcessWire. ProFields are designed to work with ProcessWire, using its interface and architecture to maximum effect, extending it in the way it’s designed to be extended. 

There’s nothing that a field like Combo (or any other) could do to make its subfields start pretending they are regular fields. So it’s not even a request I can entertain because it’s simply not possible for a Fieldtype to get involved in that. Don’t look for any ProField (or any field) to do this, because that’s well outside what a field can do technically, and outside of its responsibility or control. If you find yourself having this interest for subfields in a particular field tossed around in different locations of the template, take a step back and ask why. Then consider, this is what ProcessWire fields do, it’s what they are for, and they do it without breaking the borders of responsibility or blurring any lines of what they are. There’s nothing wrong with using regular ProcessWire fields for their intended purpose. Neither Combo nor any of the ProFields are meant to replace that.

ProFields answer specific things, they are not intended to replace the template-field relationship, nor could they. Use ProFields where they cross over with a specific need they answer, and skip them when they don't. I understand subfields are cool and popular now, but fields are still where it’s at. Templates are still templates and fields are still fields. A Combo field is also still a field (not a template), and a subfield is still a subfield (not a field). I’d drive myself mad and have an unmaintainable code base if I started mixing up these things or breaking their relationships. 

I’d like to better understand why you would want to do any of this stuff in the first place (versus just using Fields how they are supposed to be used).  Is it because you want them to be stored together behind-the-scenes so that they can be searched as one? Is it because it’s less tables to look at in your DB or less fields to see in your Setup > Fields? Is it because you think it might use less memory/resources that way? Or something else? I think if I understand what the underlying point of this is, that would be helpful. If it turns out that there really is some significant and real benefit in doing this, that can’t be met by using the system as intended, then I’d be interested in looking into it further. But it’s something that would have to be considered in the core and managed by the template (fieldgroup component). That’s because a Field getting involved in the responsibilities and relationships of templates to fields would be bad architecture and a broken system. Whereas, if the core provided an interface where a Field can specify which of its subfields are allowed to be visually “detached” in the page editor, and the template and page editor know of and read that interface, that’s where the architecture could work (no responsibilities broken). 

The Uikit theme is not a requirement of Combo, so if you find Reno isn't working, that's likely just a 1st beta version glitch that I need to work out. I'll get that figured out. 
 

[adrian]

Sorry Ryan if any of our comments came across as criticism of Combo - I do think it has the potential to be very useful and I completely understand why the subfields can't actually be visually  separated. 

What worries me I guess is the stated goal of Profields:

"ProFields are an powerful group of ProcessWire field types (with custom inputs) that enable you to manage more data with fewer fields. This saves you time, reduces overhead, and makes development more efficient and even more fun."

I guess I am wondering why I'd actually want to have fewer fields (how much less overhead is there actually) - in reality I don't re-use fields that often because of the issues of not having a self-documenting name when calling a field via the API. Yes, title, body, images, etc are fine, but after that it ends up seeming contrived to have a name that is both generic enough and yet semantic enough to not be confusing. Obviously text_1, text_2 is not very useful, but anything more specific is sometimes just as confusing if you are going to re-use for different purposes. Yes, it's a balancing act and I don't have any complaints - I make a decision one way or the other and move on. But, we have these Profields (just talking about Textareas and Combo) to do something that perhaps isn't that beneficial in very many cases. In your address example - how much of a performance advantage will it actually have? What if I also need first_name and last_name fields outside of the address combo field - now I start wondering whether I want a combo address field that includes these, or I want an address field that is just location info, with the first/last name fields separate, or do I just go with all separate fields for ultimate flexibility. 

We are spoiled for choices in PW, but sometimes I just wonder if too many choices can lead to confusion. Honestly, if there was no performance advantage to the Combo field approach, I wouldn't ever consider using it because of the reduced flexibility - I don't have any logistical issues with managing lots of regular PW fields - it's very easy and extremely flexible.

Again, I know we are all very appreciative of all the options you have made available - it's incredible really, just perhaps a little overwhelming trying to balance flexibility with the unknown performance advantages / disadvantages.

Finally, I think I mentioned this when you first announced Combo - an example of when I would use it is where I have used a Table field, but restricted it to one row - in this case, I wanted easy SQL querying of scientific metadata that was several fields per page. It will be brilliant for this use cases like this and can't wait to use it for these sorts of things, but I am going to resist the urge to use it for any "normal content" fields.

Thanks again for all your hard work.

[ryan]

Quote

What worries I guess is the stated goal of Profields:

Worries? Combo achieves these these goals perhaps the best of all the ProFields. And all of the ProFields achieve these goals and more, and I stand by that 100%. If we could solve every use case with one field, we'd only need one. But there are several ProFields because each solves a different use case. That's the point. To gain the benefit, you have to use them for what they are designed for.

No field in PW can pursue the use case mentioned earlier because it's outside the scope of what fields can do or are even for. I'm interested in the use case still, but for the core, not for any individual field, where it would be technically impossible. 

Quote

in reality I don't re-use fields that often because of the issues of not having a self-documenting name when calling a field via the API. 

Good strategy, and same here. I don’t often reuse fields unless the name makes sense for it. That’s how it’s supposed to work. It’s the more generic (title, body, images, files, headline, summary, etc.) that make the most sense for that. Though in my case at least, the reusable fields are also the ones most used, since they generally apply to almost all templates. 

Quote

Obviously text_1, text_2 is not very useful, but anything more specific is sometimes just as confusing if you are going to re-use for different purposes. 

Yes, I wouldn’t do that either. Though something like “headline” and “headline2” or “body” and “body2” (or further) might be fine as it’s not uncommon for a template to represent primary and secondary headline/body content, and for that need to be a recurring one on multiple templates.

Quote

But, we have these Profields (just talking about Textareas and Combo) to do something that perhaps isn't that beneficial in very many cases.

Respectfully, I think that’s backwards, and not a correct statement in my opinion. You are of course entitled to your opinion, and no problem, but I would not put my time and effort into building something that “isn’t beneficial in very many cases.” These fieldtypes (and Combo in particular) I think are beneficial for a ton of cases. In the case of Combo, it’ll likely be one of the first modules I install on every site I work on, and have no doubt it’ll be the same for others. Everyone has different needs, but I think easily more than half of all ProcessWire users will find major benefits in Combo. But I don’t claim that ProFields or even ProcessWire will solve every need that every person has ever had either. Though my hope is that ProcessWire is the platform for solving most. And combined with ProFields, even more so. 

Btw, Textareas and Combo are completely different animals, and while they keep getting mentioned together, they really have no relation to one another other than that they are both ProFields. 

Quote

In your address example - how much of a performance advantage will it actually have? 

Relative to using separate fields (first_name, last_name, street, city, state, zip) I think the performance benefit will depend on when and where you are using the content of those fields. If you are using all the info in those fields in a given request, then it will be a definite worthwhile benefit. If you are more often just using the "city", then probably not a benefit. In reality, this particular example is too small for it to matter one way or the other. So I would say for this case it depends on whether you prefer to treat these bits of content as a group or not (in your page editor, in your template placement, and in your code). Likewise, if you are reusing that combination of content (group), it’d be a lot simpler to just add the Combo field to a template rather than all the fields individually. Same goes for whenever you want to change something about it. It adds a lot of development efficiency to work with the combo rather than always all the bits within it. 

Quote

What if I also need first_name and last_name fields outside of the address combo field - now I start wondering whether I want a combo address field that includes these, or I want an address field that is just location info, with the first/last name fields separate, or do I just go with all separate fields for ultimate flexibility. 

Or maybe even a 3rd option: use both. But only you can decide what option best suits your need. They are all good options. 

Quote

We are spoiled for choices in PW, but sometimes I just wonder if too many choices can lead to confusion.

This is a concern I have with what’s being asked for with mixing subfields and fields together. It’s confusing for me at least to start mixing up what these things are. They would definitely need to be well isolated, though I think Robin S.’s screenshot did a good job of that making it clear what was what in terms of the definition stage. I would find it confusing in the page editor though, as the editor would no longer accurately reflect the actual field. Could be an issue, or not, I’m not really sure. Count me is interested, but just not in achieving it with a field like Combo, since it’s not even possible. But it is possible in the core. And it sounds like it may be possible to some extent in a module (per what Robin S. as developed), though I'm not sure exactly how, but am curious. 

Quote

Honestly, if there was no performance advantage to the Combo field approach…

This is not at all true, so I’m assuming this is just a hypothetical “if” for your particular use case. There is indeed a performance advantage, and it can be major. And for most it will be significant. But like with anything in software, it depends on what you are doing and how you are using it. If you are actually using the content as a group (as intended), I think the performance benefit can be major, as the effort of loading multiple fields is now reduced to the effort of loading just one. If you are wanting to use it as a storage container for other unrelated fields that aren’t used as a group, and may be used inconsistently, performance would be better served by regular PW fields, which are already designed for this and are already quite performant.

Quote

…I wouldn't ever consider using it because of the reduced flexibility - I don't have any logistical issues with managing lots of regular PW fields - it's very easy and extremely flexible.

Based on everything you’ve mentioned, I agree that think your particular needs sound like they are best served by PW fields. Combo offers a lot of flexibility, but it was never intended to replace all that you can do with templates and fields. It is itself still a field, after all. 

Quote

…an example of when I would use it is where I have used a Table field, but restricted it to one row - in this case, I wanted easy SQL querying of scientific metadata that was several fields per page. 

Combo would be very useful for this, no doubt.

Quote

…but I am going to resist the urge to use it for any "normal content" fields.

A group of normal content fields is a fine use case for Combo. But if wanting to use it as a storage container for some normal content fields that don’t really go together, I agree that you’d want to resist the urge to use it in that way. 

[adrian]

Thanks Ryan,

My worry about the stated goal of Profields is the desire to reduce the number of required fields - I am not saying that Combo doesn't do an excellent job of this - clearly it does. My concern is why we want to reduce the number of fields - for me, the only reason really is performance. I don't mind giving up simplicity of managing fields for the added flexibility, which is why I don't personally like Textareas. That doesn't mean I don't think Combo isn't awesome - it clearly is - it's just a matter of being careful about when / why you decide to use it. I am really just wanting this discussion to help us all think through the tradeoffs of our decisions now we have this extra tool.

I think the key take away that I am getting is that Combo is something to consider when:

1) Fields always belong together in the editor
2) You will always (or almost always) use them all together when rendering on the frontend
3) You are certain you won't ever want to include non-supported subfields (like images)
4) The Combo field contains enough subfields that the performance (DB query) is significantly greater than going with separate fields

I am sure that the Combo field can provide more performance - I haven't ever actually questioned that - the key thing for me though is making sure I don't choose it in an effort to have more performance, only to find out that later on there are new requirements that mean that I have to move everything to separate fields - I can already see the need for a new action for AdminActions for automatically separating a Combo field into separate fields and moving all the data to those new fields. 

Regarding talking about Textareas and Combo together - I think that's because in a couple of key ways they are very similar:

1) They only appear as one field in the system
2) They only use one DB table
3) They are lumped together in the page editor as what looks like a fieldset
4) They are the two main Profields that are designed to reduce the number of fields in the system

I understand that otherwise they are very different.

Anyway, I do hope this conversation has helped everyone a little and not come across as critical in any way - sorry if I am too brash sometimes - it comes with my Aussie heritage I guess ?

[Robin S]

@ryan, a few things to clarify and add to my earlier post...

My dream/request for ProFields Textareas and ProFields Combo is really about the Page Edit interface. It's only about the modules in that they render multiple inputfields in Page Edit and I'd love to have extra flexibility to arrange those inputfields. The fieldtypes work brilliantly just as they are.

To me, the attractiveness of Textareas and Combo is that they reduce the number of fields that are required for some projects. The only time this matters to me is on large sites that have hundreds of fields (or rather would run into the several hundreds if I don't take measures to be efficient with fields). And although I always plan for efficiency and haven't yet run into performance issues due to excessive fields or templates, there are topics in the forum that indicate it can be problem:

A typical project scenario for me is...

Client describes what they want - often it's a catalogue-type site for scientific data. I can see it's going to involve a ton of fields (or might in the future), so I start planning how I am going to handle them efficiently. Often a lot of the fields in a template will have identical requirements - they're just simple text/textarea/CKEditor fields without any special settings needed. I look at Textareas and read in the description:

Quote

This can help to reduce the quantity of fields necessary in your ProcessWire installation, especially when you have several fields that all have the same requrements. For instance, if you needed 10 textarea fields that each represented some different data, but all had the same input requirements, then you could convert all of those to 1 Textareas field.

Sounds perfect! But when I get into the nitty gritty of the project it turns out that all these similar fields need to be interspersed with image, file, table, repeater fields. Or worse, I see a bunch of fields that are all adjacent and related so a great candidate for Textareas but some time down the line the client wants to stick an image field in the middle of them. Now I have a problem and have to scrap the Textareas field and break it up into multiple fields. I can see the same situation arising when I start using Combo (which seems like it can do everything Textareas does and then some, which is awesome).

The way I see it, the beauty of Textareas and Combo fields is all about the reduction of fields needed for a project. Their appeal to me is not about grouping fields into a smaller set beyond the bigger grouping of "all these fields belong to this template" and I've never needed to add a Textareas field to more than one template. The loading of the field data and the field.subfield API syntax doesn't matter to me one way or the other - it's not a benefit or a problem. But the fieldset grouping in Page Edit is a limitation rather than a feature because it often means having to rule out Textareas/Combo from scenarios where otherwise they could avoid a lot of field overhead.

Right now we have a "Fields" inputfield in Edit Template that is doing two duties:

1. It allows fields to be added and removed from the template/fieldgroup.
2. It determines the order and layout of inputfields that are rendered in the Page Edit form.

These two things are related to an extent but in some ways they are quite different. Bundling them into one interface has worked fine for almost all the fieldtype modules in PW, but when I think about special fieldtypes like Textareas and Combo that can render multiple inputfields it seems like this interface holds them back from going to another level of usefulness.

I don't know what the perfect way to handle it is, but one idea is to separate 1 and 2. So there would be a "Fields" inputfield that simply determines which fields belong to the template. And there would be a "Page Edit layout" inputfield that is all about the layout of inputfields in Page Edit, not concerning itself with which field each inputfield corresponds to. In most cases adding a field to "Fields" adds one inputfield to "Page Edit layout". But for some special fieldtypes (Textareas, Combo, maybe FieldsetGroup, maybe some third-party fieldtype modules in the future) these modules add multiple inputfields to "Page Edit layout" that can be sorted individually. And when the Page Edit form renders it loops over the data from "Page Edit layout" and renders those inputfields accordingly. As far as I know this wouldn't require any changes to how the Page Edit form submission is processed. In my hacky module I am moving inputfields all around the Page Edit interface and it doesn't affect anything else in PW.

I know this wouldn't be a simple change but for big sites I think it could allow Textareas and Combo to cater to more scenarios, be more accommodating to changing project requirements, and thereby save a lot of field overhead.

[adrian]

@Robin S - what about being able to select a subfields like you can with Lister Pro for Page Reference fields etc. Do you think this sort of interface would work to allow for interspersing image etc fields in between Combo subfields effectively? I realize there are some technical issue for Ryan to overcome, but I think this interface might work to allow the arrangement flexibility as we are envisioning.

[Robin S]

2 hours ago, adrian said:

what about being able to select a subfields like you can with Lister Pro for Page Reference fields etc

I hadn't imagined adding the subfields of a Textareas or Combo field individually. I figured if you add the field then you get all the subfields rather than picking and choosing. Or I might be misunderstanding you.

It's just the flexibility of the sort order I'm interested in - some sort of interface that defines the Page Edit form, where I can see the individual subfields and can sort them amongst other inputfields. I think having two AsmSelects would probably be the simplest thing. One that adds/removes fields from the template, but isn't sortable (it doesn't need to be because a field is either in a template or not and doesn't really have a sort position as I understand it). And one that defines the sort order, width, visibility, etc, of inputfields in Page Edit, but doesn't allow inputfields to be added or removed (it would get too confusing - better to allow that to be defined by the fields that belong to the template, and you can always set visibility to hidden to "remove" a particular inputfield if necessary).

[adrian]

7 hours ago, Robin S said:

I hadn't imagined adding the subfields of a Textareas or Combo field individually. I figured if you add the field then you get all the subfields rather than picking and choosing. Or I might be misunderstanding you.

I guess my thought is that there would be an option to automatically select/add them all to the template, but then because they would be listed as separate "fields" in the orderable ASM select, you could intersperse them with other fields as needed. I also don't think it would necessarily be a bad thing to be able to exclude some subfields on some templates, but I don't think this is particularly high on my wishlist.

[ryan]

@Robin S Since it sounds like you came up with a solution in Textareas, how did you do that? How does it work? Since this is page editor presentation thing, I was thinking maybe it rearranges them on the front-end (JS?) or maybe it rearranges the Inputfields before the form render?

[Robin S]

9 minutes ago, ryan said:

Since it sounds like you came up with a solution in Textareas, how did you do that? How does it work? Since this is page editor presentation thing, I was thinking maybe it rearranges them on the front-end (JS?) or maybe it rearranges the Inputfields before the form render?

It rearranges them using JS. I can't remember now but presumably I struck a problem trying to reorder the inputfields using the API before the form renders, because that would be better for sure. I'll PM you the module so you can take a closer look.

[monchu]

On 12/21/2020 at 2:01 AM, adrian said:

But, we have these Profields (just talking about Textareas and Combo) to do something that perhaps isn't that beneficial in very many cases. In your address example - how much of a performance advantage will it actually have? What if I also need first_name and last_name fields outside of the address combo field - now I start wondering whether I want a combo address field that includes these, or I want an address field that is just location info, with the first/last name fields separate, or do I just go with all separate fields for ultimate flexibility. 

I want to share in my use case using FormBuilder, Textareas and Combo. I manage a martial arts association website in Australia. We produce certification for jury and athletes.

I use Textareas field to store the integers and manipulate those values in Hanna Code and use that code in FormBuilder markup field for the quiz certification.

Since we have a lot of user types from students, instructors, martial arts schools etc.; this is where Combo field suit to store all members data separated from their user's profile account.

Doing this way, the user profile data only consists of essential data such as user name, first/last name, email and password etc. Then I can re-use that Combo field in any project as well.

So in my use case, the combination of FormBuilder, Textareas and Combo are beneficial.

[Robin S]

A quick proof-of-concept using the API only...

Before (Combo subfields grouped together inside fieldset):

After (Combo subfields interspersed with other fields):

Hooks:

// Reposition Combo subfield inputfields in Page Edit
$wire->addHookAfter('ProcessPageEdit::buildFormContent', function(HookEvent $event) {
	/** @var InputfieldWrapper $wrapper */
	$wrapper = $event->return;

	// Imagine this is sort order data coming from some config field
	$insert_after = [
		'test_combo_colours' => 'image',
		'test_combo_description' => 'file',
		'test_combo_decimal' => 'test_repeater',
	];

	// Get the Combo subfield inputfields
	$combo = $wrapper->getChildByName('test_combo');
	$combo_inputs = $combo->getInputfields();
	// Reposition them
	foreach($insert_after as $combo_subfield_name => $normal_field_name) {
		$combo_subfield = $combo_inputs->getChildByName($combo_subfield_name);
		$normal_field  = $wrapper->getChildByName($normal_field_name);
		$wrapper->insertAfter($combo_subfield, $normal_field);
	}

	// Cannot just remove the Combo inputfield or else subfield value changes don't get processed
	// So instead a separate hook is used to replace the rendered output of the Combo inputfield
	// $wrapper->remove($combo);

	$event->return = $wrapper;
});

// Don't render anything for the Combo inputfield
$wire->addHookBefore('InputfieldCombo::render', function(HookEvent $event) {
	/** @var InputfieldCombo $inputfield */
	$inputfield = $event->object;
	$field = $inputfield->hasField;
	if($field->name === 'test_combo') {
		$inputfield->wrapAttr('style', 'display:none');
		$event->replace = true;
	};
});

 

[ryan]

@Robin S Great idea, that's a nice proof of concept. That getInputfields() method is only in Combo, so I hadn't even considered using it for that purpose, but looking at the way you've done it, it looks like it actually is possible to do this, and without JS. Nice. I was thinking JS might be the only way since Combo is an Inputfield that renders markup, rather than an InputfieldWrapper that keeps a collection of Inputfields that can be grabbed and manipulated. But using that getInputfields() method seems to get around that limitation, opening up the ability to detach those individual Inputfields via hooks. Does everything seem to work during form processing and such? It looks like the Combo Inputfields might get processed twice on form submit? If so, you could make it conditionally add the buildFormContent() hook only if empty($_POST['id']) or something like that. But since it's a proof of concept, that hardly matters. If you don't mind me experimenting further with your idea here, I will see what I can do to build something like it in. Even just a simple subfield setting in Combo that lets you specify "Insert this subfield [after or before] [field_name] when present in the form" seems like it could add value here without adding too much configuration baggage. 

 

 

[ryan]

I've updated Combo to use @Robin S strategy for moving the subfields around the page editor and posted it in the ProFields download thread as v2. The definition is available for any Combo subfield and it's very simple, but I figure it's something at least to start with.... it's working and ready to use. It does use a datalist-based autocomplete, so you don't necessarily have to remember all your field names. Thanks Robin S. for the idea on how to make it work, it seems to be a clean and reliable way to do it. 

 

[Robin S]

Awesome, thanks @ryan!!

I'm just about to go away on holiday but looking forward to working with Combo when I get back.

I think it would be cool to have a visualisation of the subfield placement in Edit Template, and when subfields are moved in the visualisation it populates that custom placement field in template context behind the scenes. But that's just an icing on the cake thing, and maybe a better fit for a third-party module.

Thanks again for Combo - it's a pretty revolutionary addition to the PW toolbox I reckon. ?

[adrian]

Thanks @Robin S and @ryan - this makes Combo an entirely new beast - so much more powerful and flexible - thank you both for your persistence and openness to making this work.

I do agree with Robin that the way the ordering is configured is not ideal - it could be very time consuming for example if you have a combo field with lots of subfields and you need to insert in images field right in the middle. I do agree with Robin though that it's definitely confusing looking at the order of fields in the template settings now, especially in the scenario where you have custom placed all of the combo's subfields. You have this combo field in the list is a position that really has no relevance anymore.

BTW, I really like the fact that if you use the new Custom Form Placement option for every subfield, it completely removes the label/fieldset container of the combo field which I think is often a key part to giving this the flexibility it needs to be useful in a wider variety of use cases.

[ryan]

Quote

I think it would be cool to have a visualisation of the subfield placement in Edit Template, and when subfields are moved in the visualisation it populates that custom placement field in template context behind the scenes. But that's just an icing on the cake thing, and maybe a better fit for a third-party module.

@Robin S No doubt, that would be nice. But as far as the core goes, that's a pretty major project and involves creating a new interface method for all Fieldtype modules. It could be months, and I'm not sure we'll ever get into that or not, or whether 3rd party, etc. Whereas, this was something simple that could be added today, right now, that will at least make the option available. If it sees a lot of use, I'm sure we'll keep expanding the options. But as it is right now, Combo is the only field that can do this (thanks to your contribution), so I think it probably makes sense that it's also the place where you specify it, at least for the moment. It's not perfect, but very often pursuing perfection means either never starting, or never finishing. ? 

Quote

You have this combo field in the list is a position that really has no relevance anymore.

@adrian Actually the list position is still relevant, it just becomes relative to any other fields that have been moved to the same field. Or if the field being moved-to is present in one template and not another where the Combo field is used, then the list position is also still relevant when it displays in the Combo field. 

Let's say you specified the same "body" field for all of the subfields in the Combo (to insert after). It would move all those fields after the "body" field in the page editor, and they would retain the drag/drop order you have put them in. The end result would look the same as the Combo field, but without the wrapper/fieldset. I had to play around a bit to get this working, but it is in the version I posted, so wanted to mention that the list position still matters, especially if moving multiple subfields to the same location.