Leaderboard

ProcessWire 3.0.193 resolves 6 issues, makes improvements to the template and module editors, adds new hooks, adds improvements the $pages->find() findRaw method, and more. We covered some of these updates in last week's post, so we'll focus on what's new this week. First off we have a new advanced mode feature that lets you edit the raw configuration data for a module. This can be useful for various reasons, especially for module developers. If you have $config->advanced = true; in your /site/config.php file, you'll see a new option on your module information screen that enables you to directly edit the raw JSON configuration data for the module. There's also an option that lets you view the raw JSON module information data. Unlike the configuration data, this isn't editable. That's because it comes from the module directly (overtime you do a Modules > Refresh) or is generated at runtime, so there's little point in editing it here. In my case, I've found these new tools helpful for clearing out old and/or irrelevant configuration data during module development. In some cases, having the ability to edit this data may help to identify or fix issues that previously would have been difficult to do without using the API. If there's interest, I may move this into a dedicated (non-core) module that also lets you directly edit field and template configuration data too. But for now the feature is in the core, but just requires advanced mode before it appears. A few new hooks were added this week: Fieldgroups::fieldRemoved($fieldgroup, $field) Called after a field has been removed from a fieldgroup/template. Fieldgroups::fieldAdded($fieldgroup, $field) Called after a new field has been added to a fieldgroup/template. Fieldgroups::renameReady($template, $oldName, $newName) Called before a fieldgroup is about to be renamed. Fieldgroups::renamed($template, $oldName, $newName) Called after a fieldgroup has been renamed. Templates::renameReady($template, $oldName, $newName) Called before a template is about to be renamed. Templates::renamed($template, $oldName, $newName) Called after a template has been renamed. Fields::renameReady($field, $oldName, $newName) Called before a field is about to be renamed. Fields::renamed($field, $oldName, $newName) Called after a field has been renamed. These accompany the existing addReady(), added(), deleteReady(), deleted(), cloneReady(), cloned(), saveReady() and saved() hooks available for fields, templates and fieldgroups. Last week a couple people asked about versioning and migration of stuff in PW (like fields, templates, modules, etc.) and if there were any plans to provide additional tools for that. For the projects I work on at least, this part of the development process consumes so little time that it doesn't warrant developing more stuff for it. But I understand others might find it useful, so for those that would, I'd rather keep the core lean and instead leave that to tools/modules built by experts like Bernhard and others around here. I think it's important that whoever develops and maintains such features also be the same one(s) that would use them. But if any kind of core updates would be helpful to developers looking to implement more features here, I'm on board. Whether that means adding more hooks to specific events (see above as examples), maintaining field/template/module data in files in addition to the current DB tables, or anything else that helps such modules, this is all possible and likely simple for us to support in the core. So just let me know what I can do to help. While not full-featured migration tools, we do have useful field, template and page export/import tools in the core already, and those will of course continue to be maintained and improved, and may be expanded to include modules too. Thanks for reading and have a great weekend!

Okay guys I have worked all day on this https://github.com/adamxp12/ProcessWire-TfaWebAuthn A total rewrite essentially moving over to WebAuthn. I Invite anyone to test this out I will publish it to the modules site probably tomorrow as long as no one has any major bugs I have missed in my testing. @Pete You can add a physical security key in addition to Windows Hello. but you can only setup one instance of Windows Hello/Apple Touch ID at a time because of that ProcessWire Tfa limitation but NFC keys will work on iPhone now where they did not before so a YubiKey with NFC will work virtually everywhere. I would assume if you enrolled your Android phone via USB it will work on-device too in the browser but I do not have an Android device to test that.

@Pete WebAuthn is the W3C standard whereas U2F was a google thing. When I made this module in 2019 WebAuthn was a fairly new thing The module does already support multiple keys the issue is once you save the users TFA settings they become locked so cant go in and remove a single key or add another you have to deactivate it and re-add all the keys. The might be a way around this. It does make sense from the POV of the TFA class being for one time codes as you would not edit it you would just deactivate it. The U2F was a great challenge with that constraint. With WebAuthn I might have to disable non cross platform methods like WIndows Hello because it would be impossible to setup multiple devices once you hit save on the first device. But at least it will work as it did before once U2F is removed from Chrome. I could keep that enabled but it would mean only the first device you setup will have that on device option. any other device would have to use a a physical security key. Granted I am far from a ProcessWire expert so maybe the solution is obvious?

Would you mind telling us a bit more about your workflow in regards to projects and their migration? This would be super interesting.

Hey, @Adam, thank you!

Thanks for looking at this Adam. I just got a colleague who uses Apple for everything to test and it allowed tapping her Apple watch to login and Face ID. She's got another device to try later with fingerprint but it does sound like it does all devices which is nice, and gives plenty of options, so seems like where things are going in the future. If there are changes required to the base TFA class to help in any way let me know and I can ask Ryan ? Sometimes things won't be hookable that it would be helpful to be hookable etc. I think with WebAuthn It would be more useful if the base class allowed for more keys to be stored per module right, so then per-website I could set it to allow login via facial recognition and fingerprint on the same app - that sort of thing - rather than just allowing one key per module which I think is how it works now? Also happy to help/test in any way I can on this one. As I say for me it's not a huge thing the current module stopping working as I have alternatives, but WebAuthn has me a little excited as it seems like a more natural way to allow people to login.

Chrome. The worlds worst browser as always. Making web developers lifes a pain lol Moving to Webauthn is a possibility. but the is few PHP libraries for it and one of them claims to be "simple" and the example is over 350 lines of code. So I might not get it done by Febuary ? its a big task and essentially makes this a full plugin rewrite

@bernhard Thanks you very much, it works for new pages, for old i update status1021, status1022 fields to "1" directly to db and translation appears. ?

@Krlos I agree with @bernhard - more detail is required on your constraints to really advise. However we've built a number of data-driven sites using PW in this way and I would say putting all pages of a specific type under one parent is my preferred approach vs nesting in multiple sub-folders. It's also more like a regular database table). You can then just use selectors to filter the output and it makes more sense if you have entities that might apply to multiple parents. E.g. a staff member that works at multiple locations. For those maintaining the site/data you can make it easy on them by configuring the 'family' tab for each template. So for instance, only a 'hotel' can be added as a child of 'hotels'. When an editor wants to add a new hotel they can't then accidentally use the wrong template, or put it in the wrong place. Finding an existing hotel to edit is as simple as tapping the name into the default PW search box.

@Pete Glad it works for you. I must say in my testing I am loving the Windows Hello addition too. This is mostly a stopgap solution though as I think a proper native WebAuthn setup in the core that allows you to manage each credential after its setup would be better but for now this is a solid upgrade path for people who used my old U2F module and need it to work after Febuary and dont want to give up hardware keys

Perfect - works on live. This is so good ? I had my phone plugged into my computer, so added Windows Hello (face recognition/pin) then added my Pixel phone and I can login with my fingerprint on that and face on my laptop. Absolutely awesome - love it! I'll point it out to Ryan but so far it works great!

My previous web programmer isn't doing it anymore and I have some new pages I must add and some updates. I have grant funding that must be used quickly and I found someone to help me, but they have a couple of questions and I don't know how to answer them. I tried looking for a programmer through the processwire directory, but nobody would respond. Any help would be greatly appreciated. Thank you in advance!!!! I tried embedding youtube and machform code into the Source section of the editor. It literally wipes it out (which takes me back to good old FrontPage days), is there any work around for that? I have been given access to the CMS editor but I assume there is a higher up level where templates are and styles are called, is that correct? A sort of follow on to #2, if we wanted to add Accordion functionality, if we add JavaScript to the head area and the code in the source editor would that work?

I'll admit to not having looked at the PW auth modules in terms of code at all. I might ping Ryan and see what he thinks. Can't hurt to have more brains on the case and his is bigger than mine ? I think for all my logins, since I use a laptop, I would use Windows Hello... though actually then if I want to check something on my mobile without grabbing my laptop I can't can I? ? I see the problem now. Perhaps multiple instances of the same module somehow and it lets you choose on the login page? Otherwise as you say it just uses the one you set it up with by default.

@Pete That is the library I am looking at indeed. Bit of a head scratcher right now but I am making a bit of progress in getting it working. Currently got it prompting for the keys/windows hello but not figured out the verification/login form side of things. I hope to have a new version of this module before they remove U2F in chrome. U2F will still be in Chrome until June but will be disabled so food for thought just in case I cant get this working by February Will be great once its working but its a lot more involved than plain U2F was and if you thought my U2F implementation was a huge stretch of the TFA class in ProcessWire, Well WebAuthn will push it to its limits.

@kongondo can you remind me on Monday and I'll get a forum set up? Not sure if we should call it Padloper Pre-Sales or something and have a pinned topic at the top saying for paid support to request access to the other forum or something like that?

That is just amazing news! Created a github issue about this enhancement so we can track it.

@guy You could try this: if($this->wire()->process == 'ProcessPageEdit') { // save from page editor } If you want to capture other types of page editors, like ListerPro, User Profile, etc. you could do this: if(wireInstanceOf($this->wire()->process, 'WirePageEditor')) { // save from any page editing process }

Finally an authority that stands up and no longer follows main stream and established behavior. Trying not to be a sheep doesn't get much support or likes Matomo is not like it used to be anymore https://matomo.org/pricing/ My 5cts for an alternative, I use bbclone a lot as it gives just enough in most cases https://www.bbclone.de/features.php

This week we have ProcessWire 3.0.192 on the dev branch. This is about 20 commits ahead of the previous version and contains 11 issue fixes and 5 pull requests, along with various other updates. PR code contributors in this version including Daun, MrSnoozles, Radon8472, BernhardBaumrock and Tyde. Thanks! For more details see the dev branch commit log. In addition to core updates, in recent weeks I've also been working on a new module similar to the PageAutosave (developed for the admin) except that it is for front-end forms. It works with any front-end form (whether home brewed or from something like FormBuilder) and remembers the entered form values every time a field is changed. If the user doesn't submit the form, they get an email with a link to finish filling out the form after a configurable period of time. This is especially nice for order and reservation forms. Accompanying the module is a separate Process module that lets you view all the forms in progress in the admin. Each form entry has its own unique URL, making them easy for users to return to, from any device. Once the user submits the form, the data gets removed from the pending submissions database. This is something I've been meaning to develop for awhile, and with the admin PageAutosave module still fresh on my mind, I thought now was a good time to do it. Thanks for reading, Happy New Year and have a great weekend!

I'd be curious how the other tools with file based config manage changes over time. My biggest problem with file based config (over file based migration) is that it'll only give you the current state you want things to be in, but no indication of which state the system is coming from and how to actually make data already in the system(db) be migrated to the new expected state. I'm not aware of declarative systems being able to handle that, which to me severly limits usefulness. It might be great in the beginning of a project, where you can scrap existing data, but won't work at all once old data needs to be maintained going forward.

Thank you for summing this topic up in a new thread. I had the same intention but couldn't spare the time. I am all for version control of fields and templates. @bernhard's RockMigration Module already does a great job here. And since he introduced the prototype recorder I am very excited that we will soon have something to work with and build upon. This should really be part of the PW core or available as optional core module. Would be great if @ryan put this on the roadmap for 2022.

@Violet I wonder if you missed the well explained solution of gingebaker here in this thread: Isn't the PaginatedArray class just what you are looking for?

This week we have some improvements to the $pages->findRaw() method. Most of these are based on requested improvements in either GitHub (like #427) or the forums: Support for selecting parent properties/fields in the return value, i.e. $pages->findRaw("selector", "parent.title"); // Example 1 $pages->findRaw("selector", [ 'title', 'parent.title', 'parent.parent.title' ]); // Example 2 Support for selecting page 'meta' data in the return value, i.e. $pages->findRaw("selector", "meta"); // example 1 $pages->findRaw("selector", [ "meta.foo", "meta.bar" ]); // example 2 Support for selecting "references" in the return value. References are other pages that reference the found page(s) via Page reference fields, just like the $page->references() method. $pages->findRaw("selector", "references"); // example 1 $pages->findRaw("selector", [ 'references.title', 'references.url' ]); // example 2 If you want the references to be indexed by field name, just include "references.field" in the requested fields: $pages->findRaw("selector", [ 'references.field', 'references.title', 'references.url' ]); Support for selecting title and/or value from options (FieldtypeOptions) fields, i.e. $pages->findRaw("selector", [ 'my_options_field.*' ]); // example 1 $pages->findRaw("selector", [ 'my_options_field.title', 'my_options_field.value' ]); // example 2 Support for a new "flat" option that flattens multidimensional arrays in return value. This is best explained by an example. Let's say we did this: $pages->findRaw("categories.count>0, limit=1", "title, categories.title" ); And it returns an array similar to this for every matching page: [ 'title' => '2-factor authentication coming to ProcessWire', 'categories' => [ 1035 => [ 'title' => 'Security' ], 1288 => [ 'title' => 'Users' ] ] ] Now let's try the flat option: $pages->findRaw("categories.count>0, limit=1", "title, categories.title", [ 'flat' => true ]); (side note: you might already know this, but fields and options can also be bundled in the selector like this below, which is identical to the above): $pages->findRaw("categories.count>0, fields=title|categories.title, flat=1"); It flattens any multi-dimensional arrays in the return value to be indexed in the same way that you requested them in the $fields argument: [ 'title' => '2-factor authentication coming to ProcessWire', 'categories.title' => [ 1035 => 'Security', 1288 => 'Users' ] ] In addition to these updates for the $pages->findRaw() method, this week there have also been updates to the $sanitizer->float() method and InputfieldFloat module. Now both support numbers with E notation such as 1E-2, 10E-14, -1.253E-5, etc. There are also some new values for the getString option on the float sanitizer. I don't work with this kind of stuff very often, so thanks to @MetaTunes on GitHub for helping to figure it out. Lastly, the ProcessTemplate module also went through a refactoring with some minor improvements this week. Thanks for reading, have a great weekend!

Good catch - thanks for noticing that - I'm not on it this morning apparently :) Well @Ivan Gretsky - at least using $config->paths->data should work for you. I'll still keep an eye on that $maxItems setting and implement when available and see if it handles that other situation.

Well that's two different dumps... one is dumping the array and one is dumping an object that has an array inside the data property! d($config->paths); d($config->paths->data); Personally I think that behaviour is good ?

Hi @Malinda. Welcome to the forums and ProcessWire. We have a jobs board here, in case you need it in future: https://processwire.com/talk/forum/22-jobs/ Yes. That is to be expected. For YouTube, you have three options at least: 1. Tell CKEditor to stop stripping your iframe, as explained here: 2. Use Hanna Code. An example can be found here: There are simple Hanna Code examples but I cannot find them at the moment. 3. Use one of the available Video embed modules: https://processwire.com/search/?q=video&t=Modules You would need to be a superuser (the higher up level [highest in fact]) to be able to access ProcessWire templates. However, the files that go with the templates (template files) and styles are stored in your directory/folders where your ProcessWire installation files are stored (on your webhost / server). Access to them is usually via FTP or a CPanel-like dashboard. The template files will be under /site/templates/. The location of styles is a matter of choice for your developer but the usual locations are /site/templates/styles/ or /site/templates/css/ or similar. By head area I assume you mean the <head></head> of a template file or an auto-appended file like _main.php (/site/templates/_main.php). The JavaScript would be picked up, yes. However, the code does not (shouldn't even, I would argue) go into CKEditor. It would be stripped out anyway by CKEditor. I am not sure what you mean by code in this case as well. Usually, that code would go into your /site/templates/scripts/main.js or /site/templates/js/main.js. The main.js is usually a custom file created/amended by your developer so it could be named something else, even scripts.js. I hope this helps. It would be helpful to know the what version of ProcessWire you are using. All the best ?.

With Formbuilder you can save your submitted data either as entries or normal pages. You may then query those entries or pages and output them as you see fit. Thoroughly sanitized I don't see why this wouldn't work. Depends on your Processwire skills. But I am sure there are people in the forum with more experience in that matter.

Did a quick test:

Hi @Krlos that's not an easy question and depends a lot on the use case. What are the circumstances that make the decision hard? I can't give any advice without any knowledge about the situation... Tricky? For whom? For the developer? For the person managing content? Counter question: Wouldn't it be tricky to reorganize hundreds of pages once a single thing in your project setup changes? See https://github.com/processwire/processwire-issues/issues/1459 for a recent issue... Unlimited possibilities using a hook ? I'm often using http://tabulator.info/ for displaying data and I have a module for that, so for me this is no issue. But you can also use ListerPro or the regular page finder I guess. If you don't have those tools it might be easier to stick with the page tree... But having business logic in the page tree is - in my experience - not a good idea for projects that need to scale in some extent, might change in the future or have have custom logic and calculations (for example I've built a survey tool where answers have been pages and the parent defined where the answers belonged to. That sounded great and easy on first glance, but the longer the project went and the more feature/change requests the client came up with, the more i regretted the decision and I think it would have been a lot easier to save all those answers under one parent and add a page field to save a reference to the related survey). But your setup looks like you want to show the items to website visitors under an existing urls, so probably having them where users can visit them makes sense (site.com/lodging/hotels/hotel-a)

@gornycreative - if I understand correctly, this should work. $searchEngine->addHookAfter('Renderer::renderTabLabel', function($event) use($types) { $event->return = $event->return . 's'; }); I was modifying the tabs a little more via a $types associative array, which you can see here. Just for fun I also included the hook I used to add images to the results. In the end I actually stopped using the built in tabs feature because even though it's really awesome, it doesn't work with multiple operators like: *=~= so I built up the tabs manually and now I can even change the operator if the user has wrapped something in double quotes to make it an exact match.

Nope ?. This is all handcrafted using Vue JS + TailwindCSS + custom JS + some drag and drop library. I sometimes use vanilla JS for drag and drop but didn't this time. I have never used grapejs. You are wrong in your assumption ?..., at least in the context of what I am developing here. We are managing content; we are just not using "traditional ProcessWire inputfield interfaces". The app runs in __render() method of the inputfield. Saving is via ajax but that can be changed to form submissions with page reload if one wanted to (not that I would want to do that myself). All my responses below are with respect to this Page Builder. Wrong again. Jessica White's data actually lives in the database. Still wrong. Jessica's marital (or any other of her attributes) status lives in the database. It is retrievable via the API and editable in the app GUI...all the CRUD goodies. You update it once and it is reflected everywhere that data is used, both live as you are editing and once you save your edits. That's what is happening in this builder as well. You can choose anything. Literally, anything from the system. It's just a matter of requesting it via the API and getting back a response from the server ?. It's not shown in my demo but you can even do Page Reference fields. All data requests by the App request are vetted on the ProcessWire side (permissions, validation, sanitising, etc). Neither have I but it looks like your brief experience with it wasn't great? Maybe it was a misconception? A quick Google search tells me grapejs can work with a database backend. We can and we do....? Examples include Padloper 2, this Page Builder and other Vue JS apps I have built (unreleased). By smart content I assume you mean data stored in the database, be it in ProcessWire fields or custom tables. All the data you see in the demo of this Page Builder are stored in ProcessWire tables (Fieldtypes). You can access this data using the API and carry out any CRUD task using the usual ProcessWire API.