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.

Hi everyone, I've been experimenting with a CSS customization that brings the default AdminThemeBridge theme closer to the visual style of the Konkat theme. I also wanted the interface to feel calmer and make complex Page Edit screens easier to scan, especially when content is nested in FieldtypeFlex, Repeater or Repeater Matrix fields. The customization gives inputs, field groups and repeatable rows distinct but subtle visual roles, with consistent typography, fewer borders and quieter surfaces. Tree guides make nested structures easier to follow, and focusing a field highlights only the path to that field. The example uses nested FieldtypeFlex rows. It follows Bridge's configured primary colour and light/dark modes. The main settings are CSS custom properties at the top of one stylesheet. A small JavaScript fallback handles the tree geometry in browsers without CSS Anchor Positioning support (Safari). The attached package uses the existing theme hooks and requires no changes to ProcessWire, Bridge or field modules. It's an early prototype; I'd be interested in feedback, especially on the nested editing experience and whether parts of this approach would fit Bridge itself. bridge-custom.zip

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!

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.

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!

😲 I have no idea how context7's “related skills” are created. The complete setup, including the markdown conversion, is in the other repo https://github.com/phlppschrr/processwire-knowledge-base. The Python code for this is mostly vibe-coded with codex 5.2, and partly with gemini 3 pro. I have to admit that I haven't looked at the resulting Python code, but at least on my computer it works reliably. The repo indexed by context7 currently only contains the Markdown version of the ProcessWire API documentation as Markdown. As long as Ryan hasn't built prompt injecting into his phpdocs, it should be safe. I don't know yet how to best use the repository. I would appreciate input on how to write the skill to make the content usable for an LLM without bloating the context window. Probably the way via context7 is more promising than searching the local md files with grep. By the way, I've also started using gemini to break down the blog articles into individual, uniformly structured snippets with frontmatter metadata. I can imagine that this would be quite good for context7. However, it hasn't been committed yet. Unfortunately, I have to get back to customer work now... Example of a generated snippet:

Done. https://context7.com/phlppschrr/processwire-api-docs

Generates a .phpstorm.meta.php file for ProcessWire autocompletion in PhpStorm. Features Autocomplete wire container keys for wire('...') and Wire::wire('...') Autocomplete module names for Modules::get() and Modules::install() Autocomplete field names for Fields::get() Autocomplete template names for Templates::get() Autocomplete unique page names for Pages::get() Autocomplete hookable methods for Wire::addHook*() Autocomplete page status constants/strings for Page::status(), addStatus(), removeStatus(), hasStatus() Autocomplete field flags for Field::addFlag(), removeFlag(), hasFlag() Autocomplete template cache-expire constants for Template::cacheExpire() Autocomplete Inputfield collapsed constants for Inputfield::collapsed() Autocomplete sort flags for WireArray::sort()/sortFlags()/unique() and PageArray::sort()/sortFlags()/unique() Optional: Field type autocompletion per Page class (when enabled in module config) Usage Default path: site/assets/.phpstorm.meta.php (configurable in module settings). The file regenerates automatically when fields, templates, or modules change (debounced). You can manually regenerate from the module settings screen. Optional: enable "Generate page-class field metadata" in module settings for field type hints per Page class. This is intentionally basic. For richer field stubs, use AutoTemplateStubs. Examples Modules $tracy = $modules->get('TracyDebugger'); // Autocomplete + correct class type for navigation and code insight Wire Container $page = wire('page'); $pages = $this->wire('pages'); $cache = wire('cache'); // Autocomplete for keys like page/pages/cache/etc. Fields $body = $fields->get('body'); // Autocomplete field names, fewer typos Templates $tpl = $templates->get('basic-page'); // Autocomplete template names Pages $home = $pages->get('/'); // Maps to the page class when page classes are enabled Page Status $page->status(Page::statusHidden); $page->addStatus('draft'); $page->removeStatus(Page::statusUnpublished); $page->hasStatus('locked'); Field Flags $field->addFlag(Field::flagAutojoin); $field->removeFlag(Field::flagAccess); $field->hasFlag(Field::flagGlobal); Template Cache Expire $template->cacheExpire(Template::cacheExpireParents); Inputfield Collapsed $inputfield->collapsed(Inputfield::collapsedYesAjax); Sort Flags $items->sort('title', SORT_NATURAL | SORT_FLAG_CASE); $items->sortFlags(SORT_NATURAL); $items->unique(SORT_STRING); Page-Class Field Metadata (Optional) $home = $pages->get('/'); // $home is HomePage (page class) // Field types are inferred from the template fieldgroup // e.g. $home->hero_image -> Pageimage or Pageimages depending on field settings Hooks $wire->addHookAfter('Pages::save', function($event) { // Autocomplete hookable methods while typing the hook string }); Notes Hook scanning reads ProcessWire core, modules, and admin templates to build the hook list. If page classes are enabled, page names map to their page class; otherwise they map to Page. Improvement suggestions and PRs are welcome. https://github.com/phlppschrr/ProcessWirePhpStormMeta

Do you know if we can create our own repo that only contains the Markdown APIDocs and use it for content7, or does it have to be the official repo?

https://github.com/phlppschrr/processwire-knowledge-base

@gebeer I have started developing a ‘processwire-knowledge-base’ skill. To do this, I converted all blog articles and tutorials from the website as well as the API docs into Markdown. However, I haven't tested the skill yet. I think it still needs some fine-tuning. It's still a private repo at the moment, but if you're interested in taking a look, I'm happy to make it public.

@BitPoet Have you had time to look at the PR yet? Is there anything that needs to be adjusted? Has anyone else tested this version besides me? I haven't noticed any problems so far.

Hi all, I just opened two PRs for AutoTemplateStubs. First one adds/extends ProFields stubs (Table, Textareas, Multiplier, RepeaterMatrix, Custom) + some refactoring The second PR adds an optional PHPDoc injection into custom Page classes. It only edits a clearly marked region (//region AutoTemplateStubs ... //endregion). If the marker is missing, nothing is changed. If the class doesn’t exist yet, it creates an empty class with the marker. So it’s opt‑in and hopefully safe. Happy to adjust if needed.

In line with this topic, I recently expanded AutoTemplateStubs to include ProFields Stubs. There should be stubs for FieldtypeTable, FieldtypeTextareas, FieldtypeCustom and RepeaterMatrix (including stubs for all types). I haven't created a PR yet because I wanted to test it myself first, but since it fits so well with the blog post, if anyone would like to help with testing: https://github.com/phlppschrr/AutoTemplateStubs

I think the docs are generated with a custom module: https://processwire.com/blog/posts/processwire-3.0.41-and-a-look-at-api-explorer/