Leaderboard

Just throwing what I am used to work with: monitoring: uptimeflare as status page, customizable and it work with cloudflare workers (not self-hosted as is, but can be done with cf wrangler). goaccess for a deep and nice views of web logs. really, this is a must have. prometheus for all sort of metrics and creating charts for visualization (I dont use it but a self made metric server for the same purpose. but with a plugin for goaccess). pulseway: (commercial) for notifications via custom app (api is available), mail, mobile push based on pulseway's agent features, goaccess / uptimeflare / "prometheus" or whatever. Vesta control panel: for easy web-hosting management (to be used only on a vpn - dev recently resumed and v2 is on the pipe). umami: for web analytics. OpenVPN: can't live without it, For you and/or clients. Deployed in a minute and it's a matter of seconds of adding/revoking clients. I must add here that custom gui can customized easily. Fossil: an advanced but simple SCM Invoice Ninja is really cool because of their desktop and mobile apps, despite the UI which could be improved a lot. it's a matter of tast for sure. I knew it from Firewire here inthe forum. Just a note about files and synching (de-google): since two years or so, I only deploy Synology NAS with synology drives among others tools available from it. No more files lost, management is easy for self or clients infra, and is highly configurable.

I'd like to hear what software you self-host and that act as an alternative for a cloud-based offering. It doesn't have to be FOSS, commercial is OK too. Some of my go-to ones, beyond ProcessWire and LAMP, are: Uptime Kuma: an uptime monitor (recently discovered this and it's earned a spot on my 'tools' server) https://github.com/louislam/uptime-kuma Postal: open-source mail delivery platform (recently discovered this as well; acts as an alternative to Mailgun, Sendgrid). https://docs.postalserver.io/ Invoice Ninja: I already have my own custom project/bookkeeping/invoices system that I built and maintain with PW, but I'd probably use this if I didn't go that route https://www.invoiceninja.org/ RocketShipIt: self hosted shipping API (has a cloud option as well; commercial but very good pricing; alternative to EasyPost and similar services) https://www.rocketship.it/

I agree that the Sendy interface is a bit cluttered, but the application itself works very reliably. I'm using it in production for some time now. It is regularly updated and updates are easy to deploy. It is cheap (pay once, no subscription) and has no restrictions concerning the number of clients, subscribers, lists, emails, sender domains... Sending through Amazon is not only cheap (no subscription needed), but also very reliable. No more complaints about newsletters in the spam folder (unlike Mailgun, Sendgrid...). It has a basic API -- it is easy to to integrate with PW. You can let your users build their newsletter with ProcessWire and then send the HTML code via API to Sendy, creating a new campaign. In Sendy, you can handle the selection of mailing lists and all campaign related settings. The most important data from Amazon is directly available in Sendy: number of mails sent, opened, bounced. Hard-bounced Emails are automatically blocked in Sendy, that helps a lot maintaining a good reputation with Amazon. Your users will never have to login to the confusing Amazon SES interface to understand what happens. Except for a few obfuscated files (license check, etc.), the Sendy source is accessible and can be modified, if necessary.

Here is the updated install.php file for you guys to test out if you want: processwire/install.php at fix/installer-warnings-session · poljpocket/processwire (github.com)

I made some progress. With debug mode enabled, I tried to just go with what the error messages were saying. Seemingly, headers are being sent before the last ini_set calls were made. So I restructured the install.php a bit and moved the PW initialization in step 5 of the installer in front of the install-head.php include: No more warnings even with debug mode on. @ryan I think this might be worty of a PR? Would you like one?

A couple others I forgot to mention originally: Matomo: website analytics (alternative to Google Analytics) https://matomo.org/ Syncthing: file syncing tool (alternative to Dropbox, Google Drive); it's not strictly a tool to help build websites like all the others I mentioned, but it's become a vital tool in helping me de-google https://syncthing.net/

I've used dokuwiki for documentation stuff. But now switched to BookStack as @szabesz. We already have met in its github too) Redmine for project management. Zulip to chat with distributed team. For now I have not installed it (use free SAAS for now), but it is possible. HestiaCP for dev and staging environments.

BookStack: MIT-licensed, easy-to-use, yet feature-rich documentation system with built-in diagrams.net integration. I use it to document everything. https://www.bookstackapp.com/ Kodi TV: Completely free home theater app running from our QNAP NAS. We only watch our own collection; online services are a big no-way in this area... https://kodi.tv/

Webmin + Virtualmin: for web hosting management (I was a plesk user until I found webmin). Analytics: GoatCounter: No tracking analytics for simple (and usually personal) websites. Plausible: Self hosted non Google analytics.

As I mentioned, this happens to me every time. Well, I thought about how I'm installing PW usually: To start a new project and what do always enable for in-development projects? I enable debug mode. So, I am still testing around a bit, but using my docker image (https://hub.docker.com/r/poljpocket/processwire) the errors only are output if I enable debug mode, leaving debug mode disabled I get no warnings.

I haven't used it yet but it would be for both transactional emails and mass emails (newsletters). In the context of ProcessWire: transactional emails being Form Builder email notifications, forgot password requests, new user notifications, etc. mass emails being those sent by ProMailer

Gitea. I’m using it on Windows and it’s literally a a single executable that you swap for updates. Run it as a service with a Sqlite file next to it, done. Straight bussin, as I believe they say. https://about.gitea.com Also, I made my own little Pocket/ReadItLater thing using ProcessWire when Pocket started to get incredibly annoying a couple of years ago. It’s not presemtable, but I use it every day, lol.

Mh, an investment company gobbling up open source projects. Yeah, that's never a good sign. I think we need an RTE that's governed by the OSI or something.

Yes, please.

Success. ?

Good catch! I never thought about that, but yes, I always enable that upon first installation too, and disable it as needed. Another good catch because, honestly, I never really look at the host's customizations. If I want something different, I used to have to compile and configure PHP myself, so I aim not to have to do that. That said, PHP's output buffering functions (ex: ob_start()) are usually used when dealing with session handling, and I just presumed Ryan was using them. Perhaps not. I'll have to try @poljpocket's install.php file and see, quickly, if it fixes things (easier than searching the entirety of the codebase for ob_start calls and if/how they're used!).

Before PHP 8 you could put anything into the count() function and it would return 1 if it wasn’t null. The code in line 241 in includes/_head.php depends on this old behaviour, so you’ll have to rewrite it. Since there only ever seems to be a single image or none at all, you can probably just remove count() entirely: if ($page->eyecatcher) { … } There may be more instances of similar things in the codebase as PHP 8 deprecated several things. Shouldn’t be too hard to fix, though.

Thank you - of course this was a silly mistake, but not the main one. The most important mistake was no connection to the database: At the old system database name is 'processwire' and database user is 'processwire', at the new installation database name is 'processdb' and database user is 'processuser' by default. Last week I made a database dump from the 'processwire' database and imported this dump into the new 'processdb' database (with new user). Today I added a new database with the old name and user, imported the same dump and copied the old site/config.sys with the old database configuration but new server names into the new site folder: Now it looks like the database connection is working, as I can login in the PW web interface, where I find the complete Page Tree, users and so on. But there is still an Fatal Error maybe due to different php-versions and/or database-versions?: Old server: PHP 7.4.33 (cli) (built: Jun 5 2024 05:05:14) ( NTS ) + mysql Ver 15.1 Distrib 5.5.68-MariaDB, for Linux (x86_64) using readline 5.1 (PHP 7.4.33 is the newest version which can be installed in centos 7) New server: PHP 8.1.2-1ubuntu2.18 (cli) (built: Jun 14 2024 15:52:55) (NTS) + mysql Ver 15.1 Distrib 10.6.18-MariaDB, for debian-linux-gnu (x86_64) using EditLine wrapper I also tried out the new site/config.php with old database configuration and corrected prepend- and append-variables, but the result was worse. Attached are screenshots of the homepage with errors and the line where the Fatal Error occured - I have no idea how to fix it.

I don’t pretend to have a good understanding of this stuff, but does the PW installer perhaps rely on output buffering to modify headers after starting the response body? Do the errors go away when you set this to 4096? Edit: I see this is exactly what the AI said. ignore me

Very true. IP block lists, mail limits and all that stuff is probably something I don't want to deal with on my own, but I'll probably experiment with it on a personal sites just to get an understanding.

Hi @jeremie Then try this: <?php $items = $pages->find("template=artist")->reverse(); https://processwire.com/api/ref/wire-array/reverse/ Gideon

This looks interesting, but I'm wondering... Are you using this to send mass e-mails? Or just mails for form submissions or signup notifications and such?

For the production server, I SSH'd in and used wget from the PW download/core URL of the zip file. I then unzip'd, and rm'd the zip file. `mv` the files from the processwire-dev (including the dot-files) so that everything was in root, and then ran the installer. The access rights of the files look ok: 775 for folder, 664 for files (600 for session files). The session folder is writeable.

Until today I didn't know how burnt CPU cooling paste smells. ? I had enough fun for now with importing those datasets, time for the frontend shenanigans.

What was described in the tweet sounds somewhat similar to what I did with Transferware Collectors Club, which I built over the course of 2021 and with HTMX (before it was 1.0). Check out the video I linked to in the post here (it's not a public site):

I was able to speak with someone at TinyMCE on a Zoom call this week and we had a good meeting. They are going to make it possible for us to continue using TinyMCE 7.x+ in the core, even though it is using a GPL license, while we use the MPL 2.x license. They will make a custom license available for ProcessWire and I hope to have the details of that potentially next week. We’ll have to review the conditions and everything to make all is good, but it sounds like it will very likely solve the issue for us. I’m really happy about this and look forward to working with TinyMCE 7.x They also expressed interest in us potentially collaborating on a separate module that would make some of the commercial and advanced TinyMCE features available to ProcessWire users that wanted them via a paid service, like a Pro module. This option hasn't been available to us before, so I thought it sounded interesting. I'll definitely be communicating with them more about that to see what's possible. That’s all I know so far, but will keep you up-to-date as I learn more.

This week I received some client specifications for project that indicated it was going to need a lot of fields, and fields within fields. There are a lot of tools for this kind of stuff in ProFields, but none that I thought would make this particular project "easy" per se. The closest fit was the Combo field, but with 40-50 or so subfields/columns within each of the "groups", it was still going to be kind of a pain to put together. Not to mention, just a lot of fields and subfields to manage. To add more challenge to it, there was another group of 30 or so fields that needed to be repeatable over any number of times (in a repeater field). I wasn't looking forward to building out all these fields. That scale of fields/subfields is at the point where I don't really want to build and manage it interactively. Instead, I want to just edit it in a code editor or IDE, if such a thing is possible. With any large set of fields, there's often a lot of redundant fields where maybe only the name changes, so I wanted to be able to just copy and paste my way through these dozens of fields. That would save me a lot of time, relative to creating and configuring them interactively in the admin. Rather than spending a bunch of time trying to answer the specifications with existing field types, I ended up building a new Fieldtype and Inputfield to handle the task. Right now it's called the "Custom" field (for lack of a better term). But the term kind of fits because it's a field that has no structure on its own and instead is defined completely by a custom JSON file that you place on your file system. (It will also accept a PHP file that returns a PHP array or InputfieldWrapper). Below is an example of defining a custom field named "contact" with JSON. The array keys are the field names. The "type" can be the name of any Inputfield module (minus the "Inputfield" prefix). And the rest of the properties are whatever settings are supported by the chosen Inputfield module, or Inputfield properties in general. /site/templates/custom-fields/contact.json { "first_name": { "type": "text", "label": "First name", "required": true, "columnWidth": 50 }, "last_name": { "type": "text", "label": "Last name", "required": true, "columnWidth": 50 }, "email": { "type": "email", "label": "Email", "placeholder": "person@company.com", "required": true }, "colors": { "type": "checkboxes", "label": "What are your favorite colors?", "options": { "r": "Red", "g": "Green", "b": "Blue" } }, "address": { "type": "fieldset", "label": "Address", "children": { "address_street": { "type": "text", "label": "Street" }, "address_city": { "type": "text", "label": "City", "columnWidth": 50 }, "address_state": { "type": "text", "label": "State/province", "columnWidth": 25 }, "address_zip": { "type": "text", "label": "Zip/post code", "columnWidth": 25 } } } } The result in the page editor looks like this: The actual value from the API is a WireData object populated with the names mentioned in the JSON definition above. If my Custom field is named "contact", I can output the email name like this: echo $page->contact->email; Or if I want to output everything in a loop: foreach($page->contact as $key => $value) { echo "<li>$key: $value</li>"; } After defining a couple large fields with JSON, I decided that using PHP would sometimes be preferable because I could inject some logic into it, such as loading a list of 200+ selectable countries from another file, or putting reusable groups of fieldsets in a variable to reduce duplication. The other benefits of a PHP array were that I could make the field labels __('translatable'); and PHP isn't quite as strict as JSON about extra commas. So the module will accept either JSON or PHP array. Here's the equivalent PHP to the above JSON: /site/templates/custom-fields/contact.php return [ 'first_name' => [ 'type' => 'text', 'label' => 'First name', 'required' => true, 'columnWidth' => 50 ], 'last_name' => [ 'type' => 'text', 'label' => 'Last name', 'required' => true, 'columnWidth' => 50 ], 'email' => [ 'type' => 'email', 'label' => 'Email address', 'placeholder' => 'person@company.com' ], 'colors' => [ 'type' => 'checkboxes', 'label' => 'Colors', 'description' => 'Select your favorite colors', 'options' => [ 'r' => 'Red', 'g' => 'Green', 'b' => 'Blue' ], ], 'address' => [ 'type' => 'fieldset', 'label' => 'Mailing address', 'children' => [ 'address_street' => [ 'type' => 'text', 'label' => 'Street' ], 'address_city' => [ 'type' => 'text', 'label' => 'City', 'columnWidth' => 50 ], 'address_state' => [ 'type' => 'text', 'label' => 'State/province', 'columnWidth' => 25 ], 'address_zip' => [ 'type' => 'text', 'label' => 'Zip/post code', 'columnWidth' => 25 ] ] ] ]; The downside of configuring fields this way is that you kind of have to know the names of each Inputfield's configuration properties to take full advantage of all its features. Interactively, they are all shown to you, which makes things easier, and we don't have that here. There is yet another alternative though. If you define the fields like you would in a module configuration, your IDE (like PhpStorm) will be able to provide type hinting specific to each Inputfield type. I think I still prefer to use JSON or a PHP array, and consult the docs on the settings; but just to demonstrate, you can also have your custom field file return a PHP InputfieldWrapper like this: $form = new InputfieldWrapper(); $f = $form->InputfieldText; $f->name = 'first_name'; $f->label = 'First name'; $f->required = true; $f->columnWidth = 50; $form->add($f); $f = $form->InputfieldText; $f->name = 'last_name'; $f->label = 'Last name'; $f->required = true; $f->columnWidth = 50; $form->add($f); $f = $form->InputfieldEmail; $f->name = 'email'; $f->label = 'Email address'; $f->required = true; $f->placeholder = 'person@company.com'; $form->add($f); // ... and so on Now that this new Fieldtype/Inputfield is developed, I was able to answer the clients specs for lots of fields in a manner of minutes. Here's just some of it (thumbnails): There's more I'd like to do with this Fieldtype/Inputfield combination before releasing it, but since I've found it quite handy (and actually fun) to build fields this way, I wanted to let you know I was working on it and hope to have it ready to share soon, hopefully this month. Thanks for reading and have a great weekend!

Since it looks like there is a some crossover with Mystique, and it also looks like that module is active and supported, I'll release this module in ProFields instead. That way it's not competing with Mystique, which looks to already be a great module. I'll focus on making Custom fields have some features that maybe aren't available in Mystique, like ability to query from pages.find and perhaps supporting some more types, etc. Plus, the new module fits right in with the purpose of ProFields and a good alternative to Combo where each have a little bit different benefits to solve similar needs.

@Jonathan Lahijani Sort of, but it's not just that. I'll go into the details once I've got the storage part fully built out. It supports any Inputfield type that can be used independently of a Fieldtype. Meaning, the same types that could be used in a module configuration or a FormBuilder form, etc. It can be used IN repeater fields (tested and working), and likely in file/image custom fields as well (though not yet tested). But you wouldn't be able to use repeaters or files/images as subfields within the custom field. Files/images will likely be possible in a later version though, as what's possible in Combo will also be possible here. Yes, if you use the .php definition option (rather than the JSON definition option) then there are $page and $field variables in scope to your .php definition file. @MrSnoozles Searching yes. Can be used in repeaters (yes), but can't have repeaters used as subfield/column types within it. @poljpocket Yes. While I've not fully developed the selectors part of it yet, the plan is that it will support selectors with subfields for searching from $pages->find(), etc. @wbmnfktr The API side of this should work like most other Fieldtypes with subfields, so I think it should be relatively simple for importing and may not need any special considerations there, but I've not tried using it with a module like ImportPagesCSV yet.

Obviously I haven’t used this myself I feel like there is some confusion in this thread regarding the storage model? My understanding is that the data in the database looks the same as any other field, ie. each field has its own table with subfields being individual columns. AFAIK that’s how Profields Combo works, which this has been compared to. That would alleviate @poljpocket’s concern about selectors. One would simply use the usual dot syntax. As with all dynamic db schemas the issue then becomes migrating data inbetween schema changes. „Stock“ ProcessWire helps you here by only allowing safe changes through the UI and/or showing warnings if data loss may occur. Such safeguards are presumably absent here, but I guess you’re supposed to know what you’re doing when dealing with code anyway.

As others have mentioned, this is quite similar to the Mystique field which I'm a fan of and has the feel of how custom fields work in WordPress (more "on the fly"). I use Mystique for my matrix-based page builder block options which is a great fit. Will consider switching to this since it will be first-party and more integrated. Does it store the saved input data in json as well? I'm guessing this doesn't work with repeaters or images, correct?

@BrendonKoz Looks like Mystique defines fields (subfields?) in a very similar way, in that it is also using the Inputfields settings/API (as an array) to define them. Though looks like the use of the "type" property might be something different, since it is mapping to a constant in the module rather than the name of an Inputfield. Maybe those constants still map to Inputfield names. Mystique looks good, perhaps I could have just used Mystique to solve the client's request! Though admittedly I have a lot of fun building Fieldtypes and Inputfields, and I'm guessing there will be just as many differences as similarities, but glad to see there are more options. @Kiwi Chris The syntax I'm using is just the Inputfields API. Looks like the Mystique field above also uses the same API as well. Nice that there is some consistency between these different use cases. That's good to know. Though in this case it was also that I needed a hierarchy of fieldsets which Combo doesn't support. Plus wanted something a little more lightweight, because there were so many fields and the client just needs the ability to store them and not so much to query them. I don't know if Combo is compatible with the migrations module or not, but always good to know about the options. I usually do prefer to manage stuff in the admin, but this is a case where it just seemed like it was not going to be fun.

@ryan What I was thinking looking at your syntax, is that it looks a lot like Rock Migrations syntax. If Combo pretty much does what you need but is too slow defining through the UI with a lot of subfields, if Rock Migrations fully supports Combo, then it would be very easy to define combo fields in code like you've done. Although Rock Migrations is primarily about migrations, it takes a definition in code of the state of fields and templates that looks a lot like what you've illustrated, that's easy to move between dev and live environments, so it's absolutely possible to use it to define fields, and you can be selective about it. If there are fields or templates you want to maintain the traditional way via the UI, then don't include them in the migration definition files. It's not all or nothing. On the other hand, because it works with fieldtypes, if you start out doing things via code, then decide you want to make some tweaks via the admin UI, that's possible, as it displays all the code for a field definition, that you can copy and paste back into the migration file, so it can work both ways. I'm not sure if it needs some tweaks for your use case scenario, but I think if Combo does what you need but is too cumbersome to define via the UI with a lot of subfields, then as long as it works with Rock Migrations, then it would probably be an existing way to achieve something very similar. As always with ProcessWire there is often more than one way to achieve the same outcome. ?

Ok, now I get it and that's what I was thinking about how it would work. @Kiwi Chris is right. There is some overlap here. At least it looks quite similar, yet RockMigration goes a different route and creates real fields, templates, and relationships between them aka adds to fields to templates. @BrendonKoz , I never thought about using Mystique that way and create such a big set of fields with it. Learned new things today. Again.

Seemingly quite similar to @ukyo's solution via Mystique. I have a local SQLite database that is a mirror of an external vendor's data for our event calendar (I use an API to sync their external with our local so that I can more easily integrate items into our website rather than constantly referring to their API). By parsing available data in the SQLite database (and making it available via a local REST URL) to determine options in the field, I can then use the chosen values as a filter to then query/display matching records in the SQLite database. This particular field was explicitly allowed as a RepeaterMatrix Fieldtype, and then added, in my case. My Mystique template: /site/templates/configs/Mystique.calendar.php <?php namespace ProcessWire; /** * Resource: Dynamic Calendar settings field */ return function ($page = null, $field = null, $value = null) { // Get the data to feed possible selection values $audiences = json_decode(@file_get_contents(input()->httpHostUrl() . '/calendar/audiences.php?activeMerge=1'), true); $categories = json_decode(@file_get_contents(input()->httpHostUrl() . '/calendar/categories.php?activeMerge=1'), true); $fields = [ 'event_type' => [ 'label' => __('Event Type'), 'type' => 'InputfieldCheckboxes', 'options' => [ 'events' => 'Library Events', 'meetings' => 'Public Meetings' ], 'required' => true, 'columnWidth' => 33 ], 'limit_days' => [ 'label' => __('Upcoming Days to Check'), 'type' => Mystique::INTEGER, 'min' => 1, 'max' => 60, 'defaultValue' => 1, 'initValue' => 1, 'inputType' => 'number', 'required' => true, 'columnWidth' => 34 ], 'limit_events' => [ 'label' => __('Maximum Events to Display'), 'type' => Mystique::INTEGER, 'min' => 0, 'defaultValue' => 0, 'initValue' => 0, 'inputType' => 'number', 'required' => true, 'columnWidth' => 33, 'notes' => __('Per event type. Leave at 0 for no limit.') ], 'not_found_msg' => [ 'label' => __('Message if No Matches Found'), 'description' => __('This will be displayed if no events match the given criteria. Leave blank for no message.'), 'type' => Mystique::TEXT, 'columnWidth' => 100, 'notes' => __('HTML cannot be used here. Markdown is allowed.') ], 'private' => [ 'label' => __('Include Private (Calendar) Library Events'), 'type' => Mystique::CHECKBOX, 'value' => false, 'showIf' => [ 'event_type' => '=events' ], 'columnWidth' => 33, 'notes' => __('This is not recommended.') ], 'output_style' => [ 'label' => __('Output Styling'), 'description' => __('Choose the presentation style for any events that will be displayed.'), 'type' => 'InputfieldRadios', 'options' => [ 'list' => 'A Simple Bulleted List', 'grid' => 'A Grid-Like Display' ], 'showIf' => [ 'event_type' => '=events' ], 'columnWidth' => 33 ], 'show_images' => [ 'label' => __('Display associated event images?'), 'type' => Mystique::CHECKBOX, 'showIf' => [ 'output_style' => '=grid' ], 'columnWidth' => 34, 'notes' => __('Images are always taken directly from the calendar and cannot be properly optimized.') ], 'fieldset' => [ 'label' => __('Filters for Library Events'), 'type' => Mystique::FIELDSET, 'collapsed' => true, 'showIf' => [ 'event_type' => '=events' ], 'children' => [ 'audiences' => [ 'label' => __('Audiences'), 'description' => __('Only show:'), 'type' => 'InputfieldCheckboxes', 'options' => $audiences, 'defaultValue' => '', 'columnWidth' => 20, 'notes' => __('Leave blank to show all.') ], 'categories' => [ 'label' => __('Categories'), 'description' => __('Only show:'), 'type' => 'InputfieldCheckboxes', 'options' => $categories, 'defaultValue' => '', 'optionColumns' => 3, 'columnWidth' => 80, 'notes' => __('Leave blank to show all.') ] ] ] ]; return [ 'name' => 'calendar_events', 'title' => 'Calendar of Events', 'fields' => $fields ]; }; Which then renders: I could've looped the field generation instead of the values generation, similarly to what Ryan did above, but that wasn't my use case here. Regardless of solution, it's a very handy way to generate fields, options, and values.

@wbmnfktr Each "custom" field is just one "real" field in the admin, with any number of subfields within it. The subfields are not themselves ProcessWire fields. Instead, the subfields are similar to subfields/columns in Combo fields. If using the JSON configuration, you can technically edit it in the admin (Setup > Fields) if you want to, rather than maintaining a file. But I figure most probably won't be editing JSON from their browser. You can however configure other settings related to the custom field in Setup > Fields > your_custom_field, such as usual ones (label, description, icon, etc.), plus others like entity encoding when output formatting is on, whether the subfields should have an outer wrapping fieldset (same as the hideWrap setting in Combo), and more. @Kiwi Chris I am not that familiar with Rock Migrations, but I'm thinking we might be talking about different things as this is a Fieldtype and Inputfield, not a module related to migrations. It doesn't create any new fields or anything like that, but it lets you define the structure of subfields within a "custom" field.

This week a need came up in a client project. The client's team wanted to be able to navigate to their tours (pages) in the admin page-list by different criteria (operator, brand, boat, etc.). You can do this in Lister already (filtering by page references), but the client was looking for some predefined navigation paths in the main page list, as they thought this would be a helpful and time saving optimization, as they spend a lot of time in ProcessWire. They don't always know the exact tour at first, so starting from an operator, brand or boat helps them get to where they want to go more quickly. Once implemented, I thought it was actually quite useful for a lot of situations so decided to develop it into a module on my own time, and that's now available for download in the modules directory. I've published a new blog post that describes it more and covers all the details— https://processwire.com/blog/posts/page-list-custom-children-module/

This is incredibly useful and could not come at a better time!

Haven't played with it yet, but I already love it - and I would pay for it when it solves the issues I face in a project right now, to be honest. A recipe collection with only 200 recipes in 20 categories/cuisines/styles is already hard to manage. I have ProLister but THIS here... is a real game changer. Update: It works as I imagined. Those Kategorien (categories) now list all those recipes (from Low Carb Rezepte) that were assigned by a page reference field. It's great/awesome/I love it! Update 2: One disadvantage of using this module is that you are reminded of how bad your data structure really is. And that even sideprojects should be build with a bit of thinking. I could cry (for joy). ?? What a total chaos. Every line and therefore template and fields to exactly the same.

This week I was wrapping up the client project I mentioned last week (just launched today here), but did get some updates added to the core as well. Primarily the addition of some smaller feature requests. One of the features added is a README.md and CHANGELOG.md viewer to each module's configuration/info screen. When a module has one of those files in it, it is now viewable from within the admin. You'll see the links them at the bottom of the "Module information" section of any module's config/info screen in the admin. Other requested features added were: Support for OPTIONS, CONNECT and TRACE methods in WireHttp. And, A new hookable method in ImageSizerEngineIMagick added via a PR from Robin S. Support for <hr> elements has been added in InputfieldSelect and InputfieldSelectMultiple. It was news to me, but apparently <hr> (horizontal rule) elements are now supported by browsers between <option> tags in <select> elements, rendering a nice separator between options when you want them. So our Select inputfields now support that. To add a horizontal rule/separator, just add an option with 3 or more dashes/hyphens. Programmatically you would do a call like this when you are between options where you want the <hr> to appear: $inputfield->addOption('---'); Or, if specifying options as text (as you would with Options fields, or several other Fieldtypes), you would just enter a line with 3 or more dashes on it, and nothing else. So if we had an select where you could select a color, and we wanted to separate RGB from the other colors, we could do this on its configuration screen: R=Red G=Green B=Blue --- O=Orange P=Pink C=Cyan Thanks for reading and have a great weekend!

Thanks @ryan - this is fantastic update. My initial testing shows that OR selectors are now working for the WireCache $expire selector (https://github.com/processwire/processwire-issues/issues/1828) which really opens up the ability for some huge performance benefits. Thanks again!

Ah, it seems that this module by @Robin S already solves this very issue (and some others)!

thanks but that doesn't seem to help either, neither clearing cache nor the hard refresh.