Hi,
I was looking for a way to make a 3rd party custom fieldtypes full width on the entry publish form like the RTE, grid or textarea appears but at present the deciding factors for field width are very controlled.
Is it possible to allow 3rd party developers to make their fields appear at full width via the field settings?
This is what I tried locally:
--- a/system/ee/EllisLab/ExpressionEngine/Model/Content/Display/FieldDisplay.php
+++ b/system/ee/EllisLab/ExpressionEngine/Model/Content/Display/FieldDisplay.php
@@ -97,7 +97,7 @@ class FieldDisplay {
public function getSetting($item)
{
$settings = $this->field->initField();
- return $settings[$item];
+ return (isset($settings[$item])) ? $settings[$item] : null;
}
}This change lets other code check if a setting exists without errors being thrown if the index does not exist.
--- a/system/ee/views/publish/entry.php
+++ b/system/ee/views/publish/entry.php
@@ -80,6 +80,11 @@
$width = "w-16";
}
+ if ($field->getSetting('field_wide'))
+ {
+ $width = "w-16";
+ }
+
$field_class = 'col-group';
if (end($tab->getFields()) == $field)
{Now the view can check if a field is expecting to be shown at full width.
/**
* {@inheritdoc}
*/
public function save_settings($data)
{
return array(
'field_wide' => true,
);
}The custom fieldtype can now use the save_settings function to force the publish entry view to display the field at full width.
Is this something that could be considered for EE3 to allow 3rd party developers to gain better control over the presentation of their custom fields?
Please let me know what you think.
Thanks.
Best regards, Iain Saxon
Hi Iain, sorry for the delay, we just got to talk about this today. Yes we think you all should have this ability, and your implementation makes sense, I think we’re going to go with that. Will try to get it in today. Thanks for the suggestion AND patch!
Also, we were curious, what kind of fieldtype do you have that needs the wide column? We’re trying to come up with some guidelines to give to developers to say when it’s best to use a wide column, so we want to see what kind of fieldtypes are currently needing it.
Hi Kevin,
Thanks for considering and implementing this feature in the latest developer preview!
I’m in the process of porting a fieldtype that needs to include a grid of content for users to enter so a full width layout is ideal.
Now that I’ve just thought of it, I may see if I can also reuse some of the existing EE3 code to generate a grid that can be wrapped in my fieldtype. Using the shared form views I’ve been able to generate a tabbed module control panel page without writing any presentation code myself. Just send arrays of fields to the correct view templates and send them as the key=>value pairs to the tabs node in the MCP return view.
Ah alright, thanks for the info! And you’re welcome. Glad to hear the shared form view is working out for you. If you need to create a Grid-like input, the CP/GridInput service is available, our own Grid field is based on it and other parts of the CP that need a dynamic set of rows, such as image manipulations on the Upload Directory create/edit form.
Hi Kevin,
This solution does indeed work for most use cases, we are currently using this for Tagger.
But do you have any guidance on how to enable field_wide programatically without resorting to saving the fieldtype settings?
Our current use case: One of our fieldtypes only shows more “content” if you are in a specific member group. And some fieldtypes don’t have any settings.
I could pull it off with javascript but was looking for a non-js/native way.
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.