Leaderboard

Hey ProcessWire Community, I’m excited to announce a new module currently in beta: ProcessDataTables – designed as a universal “Swiss Army knife” for backend data visualization. Before the development of the ProcessUserDataTable module we developed a sleek module for a client called ProcessDataTable (singular), which featured the same guided, user-friendly install process with select/multiselect configuration fields but the possibility to handle the column display with small PHP templates. It was also designed for using it with a single table. But we saw the need for a truly flexible solution that can handle an unlimited number of tables in the ProcessWire admin. ProcessDataTables (plural) is aimed at more experienced ProcessWire developers who need a rapid, highly configurable, and reusable tool for building complex data overviews and admin dashboards. Unlike the original (still unreleased) single-table module, which focuses on ease of setup, this new version prioritizes scalability, customization, and extensibility. We are currently using it in combination with @bernhards incredible module RockCommerce to display E-Commerce related data for backend users. Why ProcessDataTables? Unlimited custom tables: Quickly define as many tables as you need for any data structure or ProcessWire template. Advanced configuration: Control each table’s columns, data sources, selectors, and field-level output via PHP stubs. Per-field templating: Every column can use its own output template for advanced formatting and presentation. Global module config: Set date/currency/number formatting, labels, and output options from a central settings screen. Built for developers: Configuration is more open and flexible, allowing you to create advanced dashboards and reporting interfaces for any ProcessWire installation. Differences to the (yet unreleased) ProcessDataTable Module The original ProcessDataTable (singular) module was focused on single-table use cases and offered a more beginner-friendly installation process: Guided setup: Selection of templates and fields through select/multiselect inputs in the config screen Quicker onboarding: Suitable for smaller projects or less technical users when only one data table is needed Status ProcessDataTables is currently in beta – feedback, ideas, and bug reports are highly appreciated! Looking for real-world use cases and input from the community to help shape the roadmap. Screenshots & Example Workflow In the README of the module you find example screenshots of the module config, adding tables, and customizing table columns) Get it here: https://processwire.com/modules/process-data-tables/ https://github.com/frameless-at/ProcessDataTables If you have ideas, feature requests, or want to help test or contribute, please reply below or DM me! Looking forward to your feedback and suggestions!

Example: foreach($list_of_cards as $card){ // cache cleared then selector matches $files->render("inc/some-include", $vars , ["cache" => "template=some_template", "name" => "template_cache_{$card->id}"]) } Available since version 3.0.130

I'm looking into it now. By the way, the error '1170 BLOB/TEXT' is puzzling too. The 'credential_id' column is not indexed. The only key in the table is the user_id with a fixed length. Here are the two functions that seem to be the culprits: public function getTableName() : string { return wire('sanitizer')->pageName($this->className()); // could probably be changed to: return $this->className(['lowercase']); } protected function _createTable() { $sql = "DROP TABLE IF EXISTS `" . $this->getTableName() ."`;" . "CREATE TABLE `" . $this->getTableName() . "`(". "id INT(10) NOT NULL AUTO_INCREMENT, " . "user_id INT(10) UNSIGNED NOT NULL, " . "credential_id TEXT NOT NULL UNIQUE, " . "public_key TEXT NOT NULL UNIQUE, " . "created TIMESTAMP NOT NULL default CURRENT_TIMESTAMP, " . "PRIMARY KEY (id), " . "INDEX user_id_index (user_id) " . ") CHARSET=utf8"; $db = $this->getDatabase(); return $db->exec($sql); } One thing to try is to remove 'UNIQUE' from the 'credential_id' and 'public_key' columns. Maybe MYSQL has trouble ensuring BLOB/TEXT fields are unique? Uninstall and reinstall. Please let me know if you spot any obvious mistake. 🙂 Will get back to you asap. The 'UNIQUE' constraint on the 'credential_id' and 'public_key' columns is definitely an issue with later versions of MYSQL. Updated on GitHub.

Solved the issue myself thanks to Tracy Debugger and the handy bd() method. While inspecting the methods using bd($inputfield) I found a property called "hasInputfield" in the $inputfield storing the Page references. So I added the following lines at the end of the code in my initial post to set the notes on the nested inputfield which stores the Page References. if ($field->name === 'hotel') { $nestedInputfield = $inputfield->hasInputfield; $nestedInputfield->notes("$fieldInfo can't be modified."); } The class however needed to be set to the outer inputfield to disable the inputfield to prevent user actions on it.

I'm not sure if this works via the field in the backend, but you could handle it with a hook. https://processwire.com/api/ref/form-builder-processor/email-form/