Kiwi Chris

Sounds like a new module coming. RockEstimator. 😁

What options are there to autosave individual page fields both in normal pages and repeaters? I see there's a page Auto Save in pro dev tools, but I'm not sure if this is what I need? There's also a commercial module by Kongondo - dynamic selects, but that requires creating a new field of type dynamic select, rather than existing fields, and I'm not sure whether it allows autocomplete rather than dropdowns, so it's not ideal. Mainly my use case is to handle dependent page fields, where one page field depends on the value of another one. I'm aware of the ability to create selectors that refer to other fields on a page, but this doesn't work as required in all scenarios. I know the API allows saving individual fields and can do so silently if necessary. Having the ability to specify individual page fields that should autosave via ajax when they're updated would be extremely helpful. Where this would be particularly useful would be with page Autocomplete input fields, as I've worked out how to hook input to pass the calling page to the hook, for custom selectors, but this only works with current values already saved to the page, so being able to combine this with the ability to autosave specified page fields would help with complex dependencies. For some fields this functionality might be unnecessary or undesirable, so being able to configure it on a per field with per template override as with other field properties would be ideal. Has anyone implemented anything like this, or does the pro page Autosave module do this?

As someone who writes about as much C# as PHP, ? to indicate nullable parameters is familiar, although if they'd put the ? after the parameter type, it would have meant not having to remember a different position depending on language. At least we don't have to put another upside down question mark at the end of the parameter, for probably the majority of us who don't have Spanish keyboards. 🙂

Thanks, that seemed to be the issue. I had included other criteria that I overrode in the hook. For the record, this seemed to do the trick: id!=page.id, template=stockItem One of the annoyances with findReady is it doesn't give you the page that called it, but including id!=page.id is pretty broad and covers anything other than the calling page, which isn't usually going to reference itself. With this selector, I can pretty much do everything I could otherwise with getSelectablePages, so I can filter on any page criteria without needing to include them in the selector string. I was trying to have some parameters both in the selector string and override them.

Not sure whether it's a bug, an inherent limitation of hooking findReady, or that I need to hook some other code as well, but I've found that while hooking findReady can allow me to modify the list of selectable pages for page Autocomplete inputfield for page fields without problem, on save, the data is not saved, and editing the page or reloading always comes up with blank data. This is a scenario where I've provided a selector string in the input tab of the admin UI to configure the field, and then use the findReady hook to read data from this string and modify it to return the correct page list. Not sure if anyone else has experienced this, or come up with a solution?

Welcome to the 50s. And nice to know that @Robin S is so prolific. I sometimes get asked by clients what happens if I have a collision with a proverbial bus, and it's a really good selling point to be able to say there's another Kiwi (what we New Zealanders call ourselves after our national bird - not a fruit) who's a major contributor to the system I use for most of my sites, and who's also developed some quite high profile national sites with it. I suppose I should get a move on and write some modules, but I guess it's testimony to the ProcessWire ecosystem that I haven't needed to as yet (well I have, but they're for specific client business processes, so not something I can release publicly.) Speaking of broadening horizons and geography, even though Robin is on the same island as me, we're at opposite ends, and he's at least a 12 hour drive away. I know I shocked my mother-in-law when she came here, because her idea of an island was that there'd be sea all around, and I took her on a trip that involved very full days with 3 or 4 days without ever seeing the coast.

Thanks for this. It probably shouldn't be too hard to adapt Ryan's InputfiledFormBuilderRecaptcha to use Cloudflare as well. I just read an article today stating that bots can now defeat pretty much all of those visual captchas that ask to identify what squares contain a given object, so this is quite timely.

I've been having a bit of a struggle converting a page reference field from Select to Autocomplete, as with Select, it's possible to hook getSelectablePages, and the actual page the inputfield is on is available to the hook, but with autocomplete, you have to hook findReady, and the page the field is on is not passed to the hook, only the name of the field, which then looks up the selector string from the field definition. None of the hook arguments include the calling page, however $event->argument(0) gives the selector string, and in the field definition it is possible to include some page fields in the selector string in the field definition. eg: The problem is, typically these will affect the pages returned, but I realised that if I added at the START of the selector string in the field definition id!=page.id that will have no influence on the pages returned, as I'm not likely to want a circular reference with a page referring to itself in a page reference field, but this will provide the actual calling page id that requested the page autocomplete. Since the selector string is just a comma delimited list, it's easy enough to convert this to an array, and if I have id!=page.id as the FIRST selector parameter it's easy to get it like so: $selector = $event->arguments(0); $selectors = explode(',', $selector); $pageSelector = explode('=', $selectors[0]); $page = wire('pages')->get($pageSelector[1]); Now that I have the actual page that the autocomplete is on, I can do things beyond what is possible with the selector string in the field definition. In my case I wanted to do this: $owner = $page->parent('template=client'); //Get ancestor page with given template and retrieve a field value from it to use in selector I can then rewrite the selector string as desired. I suppose in theory it would be possible to not use the selector string in the field definition as a selector string at all, but rather as a way of passing parameters to the hook, and then just build your own selector string in the hook. I hope this helps others who've struggled with figuring out where ProcessPageSearch::findReady is being called from. It won't necessarily work for all situations but should work when called from page autocomplete. Edit: I discovered that ProcessWire adds other selectors after the last selector in the selector string in the field definition, so it's really important that id!=page.id is the FIRST parameter in the selector string in the field defintion, unless you like searching arrays. If you make it first, you just need to explode the search string, get the first array element, explode that again, and you've got the page id.

What I'm trying to do is restrict a list for a page reference to pages with template of moveStockItem, that are pulled in from an external API, so I don't have control over the fields in that template, as they just replicate what's in the external API. In that template productVintage is a numeric field, but that's fine, as no one ever edits it manually. That's why I need to use a selector that matches productVintage = item.vintage.title, because in the repeater, users do need to select a vintage, and providing a page reference field helps restrict them to a sensible range. Hooking ProcessPageSearch::findReady seems like an option, but it does seem to be quite messy. With a select list it's easy to hook InputfieldPage::getSelectablePages and that works ok, but switching to autocomplete for the page reference field makes things harder. with autocomplete, I've found using a selector string rather than a hook works fine if the dependency and the dependent fields are on a normal page rather than a repeater, however if both the dependent field and its dependency are in the repeater, that's where things get messy. In the example I'm trying to get working, this part: clientCode%=page.createdUser.clientCode does work, so I seem to be able to reference a field from the page with the repeater field in it ok. I double checked by adding an additional section to the selector to check that page.id refers to the id of the page the repeater field is on, and not the repeater itself, and it does refer to the parent page, not the repeater. I've done some further checking, and although in the thread I linked to previously Ryan says that item should refer to fields in the repeater, in this case it is returning the page the repeater is on. I'm not sure if this is a bug, or an inherent limitation of using find for the autocomplete option?

I've found this thread: Apparently I need to use item. rather than page. to refer to a field within the repeater field. Looks like the inline documentation needs some improvement. Still haven't got it working, but think I'm heading in the right direction. The problem I'm getting is in Tracey Debugger, I can see that the selector query is not getting any value for either page.vintage.title or item.vintage.title, it's just blank.

Does this work with autocomplete? The examples look like they're using a standard select list. I can already do this via a hook in ready.php, but I've specifically been asked to provide autocomplete rather than select lists, and the code that works for select lists does not work with InputfieldPageAutocomplete.

I'm trying to get a page reference field inside a repeater working with autocomplete with dependencies on other repeater fields. I'm using the Selector String option to configure page autocomplete. Currently I have: template=moveStockItem, productVintage=page.vintage.title, sort=page.vintage.title, clientCode%=page.createdUser.clientCode page.vintage.title returns nothing, as it's a field on the repeater, not a field on the page the repeater is in.

I have a scenario where I have a need to store text in a field that may be reused subsequently, but sometimes may be just a one off. I could use a page reference field with InputfieldPageAutocomplete, configured to allow adding new items on the fly, but there are likely to be times that the text input will never be used again for another record. I guess I'd call it InputfieldTextAutocomplete, and it would work pretty much like InputfieldPageAutocomplete, however rather than storing a page reference, it would store text from a specified field in the lookup page OR input custom text to the text field. Has anyone already made a module with this functionality? I've had a browse through the module directory, and can't see anything, but I'm guessing it's functionality that might be quite handy. A specific usage scenario: Record visitor names to a site. Some people may only ever visit a site once. Others are regular visitors and need to complete a form each time they visit. To save time, regular visitors should be able to start typing their details and have the system autocomplete, but for one off cases, someone shouldn't need to create a related record. I can also see a version of this being useful for Form Builder, where people can start typing and pick a list option, or type something not already in the list. @ryan any thoughts?

@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. ?

This approach to defining fields looks not unlike what Bernhard has done with Rock Migrations, although admittedly, in his case they're not subfields. I haven't checked to see if the Combo fieldtype is compatible with Rock Migrations, but if it is then that might be another way of achieving this, with the bonus that Rock Migrations lets you have it both ways; you can define your fields in code or via the ProcessWire admin UI. If Combo isn't currently compatible with Rock Migrations, it would be worth ensuring that it is. I think there's this overlap because I'm not sure if @bernhard uses ProFields, and I'm not sure that @ryan uses Rock Migrations as you each have different workflows, but in this case it might be worth checking out each other's efforts. A couple of options I can think of: Talk to Bernhard about including Rock Migrations in the core. Pros - it's always there. Cons. It's always there, and for simpler sites where people are happy to use admin UI may be unnecessary. Build an empty site profile just with Rock Migrations installed. That way when someone needs to start a new project with this functionality they can get it straight away when they set up a new instance of ProcessWire. Pros - There when you need it, not when you don't. Cons - if you've already set up your site profile and realise you need it can't go back and reinstall profile (but still really easy to install the module from the directory).

I think this might not be too hard to implement. Currently there's just \site\templates, but if there were something like site\[theme]\templates, then it would be possible to have multiple versions of templates. This could be potentially useful during development to test out a new theme while retaining the existing one, and if it were linked to roles so it's possible to specify what theme a given role uses, it would make it easy to provide completely different looks for different users. It could allow A/B testing with users to determine design preferences. This would also be useful in a multisite scenario if different sites use common backend templates, but use a different theme to present on the frontend.

Something that I might find useful would be database abstraction so that it's possible to use more than one database engine. mySQL/MariaDB works fine in the majority of cases, but there are times where licensing or functionality means that an alternative database engine would be preferable. The two that I have an interest in are PostgreSQL and Microsoft SQL Server with each of these having scenarios where I find them a better fit than mySQL/MariaDB. Although not something that would result in a new version, improved documentation is another big one. Lots of great features have been added to ProcessWire over the years, but some of them lurk here in forum posts, or PW Weekly, rather than having everything in the main documentation site. Same applies for ProFields. It would be nice to have all documentation in one place.

@adrian I've checked and yes it seems to be to do with the settings tab. Sorry, didn't think to check that. Looks like it's a core issue.

I seem to have found a bug in this module. When installed, clicking save on a locked page saves changes, but when not installed, an alert 'This page is locked for edits' displays as expected.

Umbraco: https://our.umbraco.com/ I've actually used it in the past for someone who was on Microsoft stack. It's C# ASP.Net based so different tech stack to ProcessWire, but I found it not too different in many respects, and it didn't take me long to get my head around how to make it work. Like ProcessWire it doesn't make any assumptions about how you want to structure your data or format output, and has a good permissions system built in. It also has pretty good documentation. Where I find ProcessWire easier, is with regard to updates and installing new modules. Also Umbraco Forms is way more expensive than FormBuilder. Umbraco does have an integrated editor for modifying code for templates and partials inline, so although an editor or IDE is preferable, you don't have to have one to set up an Umbraco site. I don't know how the two compare performance wise. ASP.Net Core is meant to be pretty fast. I actually do quite a bit of ASP.Net work, especially now it's cross platform and I can host on Linux, although mostly I don't use a CMS at all, as it's pretty quick to build CRUD database access and authentication with built-in libraries, and with HTMX I can easily build a fast admin UI without having to mess around with frontend frameworks.

I don't have a link, but some bullet points of things I like about it. Clear separation between data and presentation layers (but doesn't force you into a SPA or operate as a headless CMS although you can do that with it if you want). Excellent permissions management system at both template and individual field level. Simple object model - everything is a 'page' with 'fields' - (similar to Drupal's nodes, but without the baggage). Great admin UI for no code creation of pretty much any kind of structured data. Actively developed third party migrations module (RockMigrations) that lets you mix and match visual and code based development of object definitions. Excellent third-party debugging tool, TracyDebugger Easy to learn API (I managed to understand the basics of it within half an hour - Drupal and WordPress by comparison, I was still scratching my head after quite a few hours.) Secure Fast Things people might not like about ProcessWire: You're unlikely to be able to build a website with one-click install. There are some site profiles that may suit some scenarios, but the whole point of ProcessWire is that it doesn't second guess you and force its opinions on you. ProcessWire's only area where it is somewhat opinionated is how it stores and structures data at the SQL level. Currently it only supports mySQL/MariaDB, and normally each field has its own table in the database, although ProFields modules Table, and Combo allow more traditional database table structures. It's also relatively easy to build custom fieldtype modules with their own database schemas. Version/source control: If you don't use a third party module like RockMigrations, syncing data changes between development and production with a team of developers might be complicated. (Actual output templates are no problem)

@MarkE yes that would be handy. I assumed a module would be necessary, just wasn't quite sure what to hook into.

Sounds like a useful module. Could this help with a related issue to locks I've had in that in ListerPro (or other places), I've wanted to have locked pages, but allow users to duplicate them? Imagine a scenario where someone has repeat orders and wants to make new orders that are very similar to previous ones with a few changes, so they should be able to duplicate an existing order, but not change it. I'm fine with changing the lock status via api on creation of the duplicate, but I've struggled with enabling the icon to click to allow copying a locked page.

That's weird, site loaded fast for me with cache cleared (ie under a second). I have had some periodic issues with warnings about high server load that I haven't been able to identify yet. It might be another site that's causing performance issues and slowing the server down temporarily. There are only a handful on the server, and most are tiny, but thanks for the heads up. I'll see if I can get to the bottom of it.

I did something similar to this with a website for a photography club. In this case the equivalent of your projects would be competition entries. I wrote a custom dashboard module for this and hooked into ready.php to prevent display of the normal page tree for normal admin users, used AdminRestrictBranch, and ListerPro from a link in the dashboard module, so users could list, edit, and create just pages that belonged to them.