Template Field Widths

[breezer]

You were exactly right. It turned out to be the LoginRegister css putting the kabosh on me.

Again thanks for a great module, works perfectly.

[dotnetic]

First of all, thank you for this great module. Simplifies the whole process a lot.

Now please add Drag 'n' Drop of the fields and support for adding new fields to the template.

Also add field edit links to open the field editor in a popup/pane.

Switching between the field name and the field title would also be nice. And if you could display what fieldtype each field has.

And voilà we have a new and better template manager ?

Hey, I am allowed to have dreams.

[tpr]

You can use this to resize via mouse (using jQuery UI Resizable which seems to be present in the PW admin). I haven't checked fieldsets, I've updated the code, it's working fine with fieldsets too.

Spoiler

$(".tfw-item").resizable({
    containment: ".InputfieldContent",
    handles: "e",
    resize: function(event, ui) {
      var percentage = Math.ceil(ui.size.width / ui.element.parent().outerWidth() * 100);
      percentage = Math.min(Math.max(parseInt(percentage), 1), 100);
      ui.element.children("label").find("input").val(percentage);
      ui.element[0].style.width = percentage + "%";
    }
});

// CSS 

.tfw-item .ui-resizable-e {
    position: absolute;
    cursor: e-resize;
    width: 10px;
    right: 5px;
    top: 50%;
    height: 40px;
    transform: translateY(-50%);
    border-right: 1px solid #354b60;
    opacity: 0.5;
}

.tfw-item .ui-resizable-e:hover {
    opacity: 1;
}

.tfw-item .ui-resizable-handle.ui-resizable-e::after {
    content: "";
    position: absolute;
    top: 7px;
    right: 3px;
    height: 26px;
    width: 1px;
    background: #354b60;
}

.tfw-item:hover,
.tfw-item.ui-resizable-resizing {
    background: #e5ecf6;
}

.tfw-item {
    padding: 3px 14px 8px 10px;
    max-width: 100%;
    transition: none !important;
}

[Robin S]

12 hours ago, jmartsch said:

Switching between the field name and the field title would also be nice.

v0.1.6 has a new config option to choose Name or Label as the primary identifier for fields. Whichever isn't chosen becomes the title attribute shown on hover.

Thanks @tpr - in v0.1.6 I added your drag resizing code mostly unchanged. It's not something I think I'll use myself but very cool nonetheless.

[tpr]

Thanks Robin - have you checked the drag resize with tabs? I didn't have time to check that scenario.

[Robin S]

1 minute ago, tpr said:

have you checked the drag resize with tabs?

You mean fields inside a FieldsetTab? If so then yes, it works well.

[tpr]

Yes, I just checked and I see that they are also under a tab (I thought it's configurable).

[tpr]

Perhaps a minor bug: if I select "Label" as the primary identifier then no text is shown for the field. Imho the module should display the primary identifier, and if not available, the name (as that's always available).

Plus it would be better to put the "title" tag on the main div (.tfw-item) so it would be always available. This introduces another issue: hovering on an input the tooltip still shows but you can disable it by adding an empty title tag to the input (at least it works for Chrome).

[Robin S]

32 minutes ago, tpr said:

Perhaps a minor bug: if I select "Label" as the primary identifier then no text is shown for the field. Imho the module should display the primary identifier, and if not available, the name (as that's always available).

Thanks, I always forget about this possibility because in my default site profile I automatically derive field labels from names.

Spoiler

$this->addHookBefore('ProcessField::executeSave', $this, 'autoFieldLabel');

/**
 * Derive field label from field name
 *
 * @param HookEvent $event
 */
protected function autoFieldLabel(HookEvent $event) {
	$post = $this->wire()->input->post;
	// Only for "Add New Field" and only if label is empty
	if(!$this->wire()->input->get->id && !$post->field_label) {
		$post->field_label = ucfirst(str_replace('_', ' ', $post->name));
	}
	// Add hook if field is being cloned
	if($post->clone_field) {
		$this->wire()->addHookBefore('Fields::save', $this, 'autoCloneFieldLabel');
	}
}

/**
 * Derive field label from field name after clone
 *
 * @param HookEvent $event
 */
protected function autoCloneFieldLabel(HookEvent $event) {
	$field = $event->arguments(0);
	if($field->name === $this->wire()->input->post->clone_field) {
		$field->label = ucfirst(str_replace('_', ' ', $field->name));
	}
}

 

Fixed in v0.1.7.

 

40 minutes ago, tpr said:

Plus it would be better to put the "title" tag on the main div (.tfw-item) so it would be always available.

It's actually deliberate the way it is. Title tooltips can be a distracting irritant when you don't have an intention to see them. I wanted there to be some intentionality required for them to appear, so you need to hover the field identifier (which is block level so it's pretty easy to mouse to) rather than having tooltips popping up whenever your mouse is anywhere inside "Field widths".

[tpr]

Thanks for the fix.

Actually the block level field identifier was what made me think that the tooltip was intended to be triggered on the whole block. As it is now on the far right side there is no indication where the tooltip will be triggered when you move the mouse. Perhaps it would be better to restrict it to the identifer text only, or prepending an info icon. Anyway, no biggie.

I created a PR to disallow less then 10% field widths, because PW doesn't allow that:

Quote

The percentage width of this field's container (10%-100%). If placed next to other fields with reduced widths, it will create floated columns.

TFWs allowed setting lower percentages and those values were kept. However, such fields were defaulting to 100%, just like the field's width sliders on the edit field page.

[Robin S]

40 minutes ago, tpr said:

Perhaps it would be better to restrict it to the identifer text only, or prepending an info icon.

I think I'll leave it for now unless I hear from others who are finding it confusing.

41 minutes ago, tpr said:

I created a PR to disallow less then 10% field widths, because PW doesn't allow that

I didn't know PW had that restriction. Thanks, have merged in v0.1.8.

[matjazp]

When I try to edit a template that gets its fields from another template, I get an error:

Argument 2 passed to ProcessWire\InputfieldWrapper::insertAfter() must be an instance of ProcessWire\Inputfield, null given, called in C:\inetpub\wwwroot\site\modules\TemplateFieldWidths\TemplateFieldWidths.module on line 152

Possible fix:

if($fg_fields) $form->insertAfter($f, $fg_fields);

 

[Robin S]

Thanks @matjazp, fixed in v0.1.9.

[Robin S]

v0.1.10 released.

Now that new core ways of setting field widths in template context have been introduced it seems that users are sometimes setting a field width using a core input and then saving the Edit Template form. Although it's not necessary to save the Edit Template form after adjusting a field width using a core input (those settings are AJAX-saved), it's not unlikely that users will do this and in these circumstances the old width stored in the Template Field Widths inputfield was overwriting the new width.

So from v0.1.10 onward the widths entered into the Template Field Widths inputfield are only saved if Edit Template is saved with the Template Field Widths inputfield in a open state. And it's recommended to use the default "Collapsed" config option for Template Field Widths if you think you might also use core inputs for setting field widths.

[You People]

Hello @Robin S

I've been using this little treasure for all my forms and I simply love it. Had recently a need for a project and would like to check with you, if it would be possible somehow to obtain the field width in a template?

e.g. field = myfield, width = 20% (set by the module slider)

$fieldWidth = $page->myfield.width;
if ($fieldWidth > 40) {
	...Code...
}

Checking up the module code but can't figure it out yet... Any help would be greatly appreciated.

[adrian]

@Motion Expert - this value is not stored by this module, but rather by PW in general.

You can get the width of a field in the content of a particular fieldgroup (basically the same as a template) like this:

In my example, I have the width of the first_name field set to 50% for the user template/fieldgroup.

[Robin S]

28 minutes ago, Motion Expert said:

would like to check with you, if it would be possible somehow to obtain the field width in a template?

Besides @adrian's suggestion, here is another way:

$width = $page->fields->getField('myfield', true)->columnWidth;

 

[adrian]

2 minutes ago, Robin S said:

Besides @adrian's suggestion, here is another way:

$width = $page->fields->getField('myfield', true)->columnWidth;

Much cleaner - I always forget about that option for some reason!

[adrian]

Actually, even this works:

$page->getField('first_name')->columnWidth

 

[You People]

Wow. Thanks a lot gents.

The idea that got in my head is to try to create sort of a visual builder (a simple version) with the ability to resize the widths. Have not yet tested it, but if I define a few fields (header, main, sidebar, footer etc.) and add them to a template, using the field width I can actually repurpose its values hence dynamically set width for the frontend as well ?

 

[Robin S]

v0.2.0 of the module is released, which is a fairly major update that brings support for Repeater, FieldsetPage and Repeater Matrix fields. Using the "Field widths" field you can quickly set the width of inputfields within a Repeater/FieldsetPage field or within each Repeater Matrix type.

Repeater:

Repeater Matrix:

[Klenkes]

Thank you again for this great module. It's a huge time saver. No website of mine without it!

V 0.2.0 seems to work fine!

[Robin S]

In the newly released v0.3.0 you can also quickly toggle the "required" state of fields in a template, Repeater, etc, by clicking the asterisk icon next to the field label.

[Tintifax]

Great module! Thx!
Just a question: dragging the bars is not updating the percentage in the number field for me. ?

[Robin S]

@Tintifax, thanks for reporting this. I made some markup changes in v0.3.0 and needed to update the resizing JS to account for this. Should be fixed in v0.3.1.