FieldtypeFlex – Structured content with native ProcessWire Inputfields

[interrobang]

Hi everyone,

I'd like to introduce FieldtypeFlex, a new ProcessWire fieldtype I've been working on. It's now available as a 0.4.0 pre-release, and I'd be interested in feedback from the community.

The idea is to define and manage structured content within a single ProcessWire field, without having to create separate ProcessWire fields for every property.

FieldtypeFlex uses native ProcessWire Inputfields for editing, so things like TinyMCE, images, Page references, multilingual inputs and conditional fields can be used within the same structure.

Main features

• Code-defined structures: Define properties using PHP, JSON or native Inputfield objects.
• Objects: Group related properties into fixed, nested structures.
• Repeatable Rows: Create typed content blocks that editors can add, duplicate, reorder and hide. Rows can also be nested.
• Native Inputfields: Reuse familiar ProcessWire inputs, settings and validation.
• Files and images: Work with ProcessWire-compatible Pagefile and Pageimage objects, including image resizing and custom file metadata.
• Selectors: Query pages by properties inside Objects and Rows.
• Schema evolution: Unknown properties are preserved during ordinary saves, with tools for renaming and cleaning up obsolete properties.

Flex fields can also be used inside native ProcessWire Repeaters.

A small example

A field definition can look like this:

return [
    'heading' => ['type' => 'text'],
    'blocks' => [
        'type' => 'rows',
        'types' => [
            'text' => [
                'children' => [
                    'body' => ['type' => 'TinyMCE'],
                ],
            ],
            'gallery' => [
                'children' => [
                    'images' => [
                        'type' => 'image',
                        'maxFiles' => 10,
                    ],
                ],
            ],
        ],
    ],
];

The content is then accessible through the regular ProcessWire API:

echo $page->content->heading;

foreach($page->content->blocks as $block) {
    if($block->rowType() === 'text') {
        echo $block->body;
    } elseif($block->rowType() === 'gallery') {
        foreach($block->images as $image) {
            echo $image->size(800, 600)->url;
        }
    }
}

Properties inside Flex fields can also be queried using ProcessWire selectors:

$matches = $pages->find(
    'content.blocks.text.body*=ProcessWire'
);

Editor preview

Watch the short editor demo

Requirements

• ProcessWire 3.0.259+
• PHP 8.1+
• MySQL 8.0+ or MariaDB 10.11+
• InnoDB

The repository includes installation instructions, a quick start, configuration examples and an API reference.

GitHub: phlppschrr/FieldtypeFlex

I'd appreciate any feedback, bug reports or suggestions, particularly from people interested in trying it with different ProcessWire setups.

Thanks for taking a look!

[adrian]

Hey @interrobang - looks cool. I am curious, could you provide some details about the pros and cons of this compared with https://processwire.com/modules/mystique/ and https://processwire.com/blog/posts/custom-fields-module/

At the moment, I am not sure if I would know which is the right solution for a particular setup.

Thanks!

[interrobang]

Thanks! There's definitely quite a bit of overlap.

Mystique and ProFields Custom Fields cover many of the same basics.
FieldtypeFlex adds nested Objects, repeatable Rows (similar to ReapeaterMatrix), File/Image fields and more advanced selectors if you need them. 

ProFields Custom Fields has the advantage of ListerPro integration (not yet tested with FieldtypeFlex) and ProFields support from Ryan. Once repeatable properties and File/Image support are added, I'd probably prefer it over my own module. 

I built FieldtypeFlex mainly because I wanted those features now, while still using native ProcessWire Inputfields. It has a pretty extensive test suite, although it's still a pre-release.

 

[ukyo]

Congratulations @interrobang

I haven't updated the Mystique module in a long time, so it's great that you developed a free alternative module and included file/image support in it. Since not everyone has the Pro modules, this serves as a good alternative. From what I see in its features, your module, FieldtypeFlex, looks like it will be an alternative to FieldtypeMystique and FieldtypeCustom.

In fact, ProcessWire should come with a field like this in the core by default. The experience we gain drives us to build modules based on our needs, and when you look at it, I think modules that can be used across most areas and projects should reside in the core. Perhaps a discussion and a poll should be held for each module on whether it belongs in the core or not. Looking at what we currently have, there are modules in the core that are rarely used and only needed in exceptional cases.
Another structure I consider lacking is the concept of everything being a page in ProcessWire. Additionally, I think it needs an entity layer for data management. Two fundamental entity types—Single and Collection—would provide the infrastructure on the ProcessWire side to handle most tasks for users without needing extra modules. This entity structure could then be used both by modules and by site-specific templates.

Because I didn't want to clutter this forum topic any further regarding the ProcessWire Entity layer, I created another topic.

 

[interrobang]

Thanks @ukyo! I really appreciate your feedback, especially coming from the author of Mystique!

I agree that a fieldtype like this would be a good addition to the ProcessWire core. For now, though, I also enjoy developing FieldtypeFlex independently. It gives me the freedom to experiment and refine things without having to worry too much about backwards compatibility at this stage.

Regarding the entity layer, I haven't personally run into major limitations with ProcessWire's "everything is a Page" approach so far, so I don't really have a strong opinion on that. But WireEntries definitely sounds like an interesting project, and I'm curious to see how it develops!

Thanks again for sharing your thoughts!

[interrobang]

Hi everyone,

A quick update since the 0.4.0 preview. FieldtypeFlex is now at 0.7.0, and the main addition is a simple table editor for things like price lists and product comparisons. You define the columns in the field definition, and editors can add, duplicate, reorder or hide rows. The cells use native ProcessWire inputs, and you can let editors change the column headings and add row labels. 

Here’s the PHP field definition for that price list.

return [
    'prices' => [
        'type' => 'table',
        'label' => 'Service price list',
        'addRowLabel' => 'Add service',
        'columns' => [
            'service' => ['type' => 'text', 'label' => 'Service', 'width' => '15rem'],
            'duration' => ['type' => 'text', 'label' => 'Duration', 'width' => '8rem'],
            'price' => ['type' => 'float', 'label' => 'Price (USD)', 'width' => '8rem'],
            'booking' => [
                'type' => 'select',
                'label' => 'Booking',
                'width' => '10rem',
                'options' => [
                    'open' => 'Available',
                    'request' => 'On request',
                ],
            ],
        ],
    ],
];

Table columns currently only support a subset of ProcessWire’s Inputfields. You can use Text, Email, URL, Integer, Float, plain Textarea, Checkbox, Toggle, Select, Radios, Checkboxes, SelectMultiple, AsmSelect, TextTags and Datetime. For Page references, you can use Select, SelectMultiple, AsmSelect or PageAutocomplete.

There are a few other changes since the preview:

• FieldtypeFlex now supports AdminThemeBridge
• support for language alternate fields such as `image_de`.
• The field settings can generate PHPDoc for your Flex definition, which is handy for IDE autocompletion.
• The tools for renaming and cleaning up stored properties now live in the field’s Actions tab.