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!

The latest additions/improvements of the module [v0.5.0]: Template file structure Stubs are now namespaced into subfolders per DataTable (column_templates/<table>/<slug>.column.php) instead of a flat directory. TemplateGenerator::getTemplateFilePath() and createTemplateFile() updated to build and create these subdirectories automatically. Legacy-stub upgrade loadColumnTemplates() now checks each stub for a return function(...) signature. If missing, it archives the old stub (prefixing its filename with _) before regenerating a new closure-based stub. Page-property handling Unified list of core properties driven by getStandardPropertyLabels() (including status). All Page-property stubs now use return …; inside closures and map bitmask flags (status) to human-readable labels. Lets look a little closer at the switch to closures for the column templates and an export/import feature. We planned this from the beginning and now switched over to a slightly different approach for the tiny template files used to display the data in your columns. The mechanism of those templates remains the same, but the performance gain is huge. Especially when dealing with lots of columns and rows: OLD: echo htmlspecialchars((string)$value); NEW: return function($value, $config = []) { return htmlspecialchars($value); }; Anyone who tried to create a DataTable gets column templates automatically created. They support the most common field types in ProcessWire and format the output initially in a simple but (hopefully) useful way. If you then tailor the output exactly to your needs, sometimes it would be handy to just save those micro templates for further use. Well, we are just developing export/import features for that purpose: Just export your global and dataTable settings as JSON and your column templates as ZIP and reuse it, manipulate them, share them 😉 and then use for migrating or easy duplication of tables. Here are some screenshots showing its (yet rather ugly) interface in action. We assume you want to port existing dataTables to another processWire site using the same data structure. Well start with a fresh install of the module We upload our exported JSON file, that contains data like this: { "moduleConfig": { "checkboxYesLabel": "Yes", "checkboxNoLabel": "No", ... }, "dataTables": [ { "name": "orders", "title": "Orders", "data_template": "rockcommerce_order", "data_selector": "", "columns": [ "rockcommerce_paymentid", "status=rockcommerce_paymentstatus", "rockcommerce_paymentdate", "order=meta", "rockcommerce_net", "total=rockcommerce_net" ... After importing we immiatly see the result of the import displayed as DataTable with, at the moment, default fieldtype templates as column templates: But at the bottom of each DataTable there is more: SO in the next step we import our prior fine-tuned column templates and immediately get a much better result: Under the hood the "old" default column templates that were created after importing the JSON config are not deleted, the get prefixed with an underscore in case you already made some adjustments before importing other column templates. Of course one can also manually copy column template files from one install to another but we found it more practical to let the module handle this. Especially when building new sites or testing, be aware that an uninstall of the module always wipes out the entire column_templates directory. So you better export before uninstalling! We are still working on the interface because it hurts my designer sensibilities to look at the UI of the import/export section. 😉 What do you think? What could be further improvements? Cheers to all of you and have a productive week!

@bernhard As its an ongoing project visualizing real customer data, I am not able to show any real Screenshots, but in a nutshell we are making heavy use of the meta data objects in RockCommerce and manipulate and aggregate data from there to show backend users useful insights. Still a lot room for improvement, but I come to that later on... @Torsten Baldes You can do anything you like inside the column templates, but for what you mentioned there are better tools out there I believe: Maybe Ryans ListerPro Module or Bernhards RockGrid Module. We aimed the module more on data visualization than manipulation. But the use cases are endless. For example a colleague of mine quickly created a DataTable with product data for assisting newsletter authors with useful page links, images and copy texts. Exactly the data he needed in a sortable table overview with modal windows that show complete data if needed.

That looks like maybe your config.php has something encoded in line 1 that's invisible?

I'm personally very excited about this update. There are some great changes here. Thanks team! One default I would propose for easier reading on bright displays is to walk back the text contrast at least 10% from black (#1a1a1a or rgba(0, 0, 0, 0.9)) and white (#e6e6e6 or rgba(255, 255, 255, 0.9)) on --text-color. Even 20% is well within the WCAG AAA contrast guidelines. Test it and see what you think. Your eyes will thank me when you're scanning a long dropdown list. Sure, it's 10-20% less bold sauce, but the Reverse-Mullet Rule should apply to such public vs private interface priorities: Party in the Front, Business in the Back. 😉

Hi Yes, please. If you get the error again, it's because the module didn't install correctly last time and so wasn't uninstalled properly. To fix: Delete or rename the folder in site/modules to .LoginPassKey and reload the page to get you back into the admin area Go to Modules and Refresh You should get a warning LoginPassKey and ProcessLoginPassKey exist in the database but the files could not be found For each, click the Edit link and check the box to remove the entries from the modules database table Places to look for leftover bits in the admin area: - /pages/LoginPassKey API - delete this page - /setup/templates - delete the lpk-api template - /admin/access/passkeys - delete this page - empty the trash to ensure they're gone for good You should now have a clean site to reinstall. PS: you can use this process to clean up any modules that failed to uninstall correctly.

As someone already mentioned, there are accessibility issues. I miss focus indicators on inputs. The blue main color lacks contrast, so I'm using #2374e2 instead of #2380e6. Also, muted color seem to have a low contrast in the page list.

You're right @monollonom, it doesn't seem to cache per render per call which would be the most useful case! Looking at the usage in TemplateFile class, it seems the options passed to render() get passed on to $cache->renderFile(), where we can pass on the name paremeter to specify a unique cache name. Updated the example! I had a very simple case where I was delegating the rendering of list items to another file and I was very surprised how slow everything turned, ProfilerPro was very usefull figuring this out. It wasn't even a big list, just like 40-50 items. I kept debugging what was inside the include file until finally figuring out it was the render() call that killed performance.