ryan

As we continue to work towards the next master version, this week I've been working on fixing reported issues. A new $sanitizer->words() method was also added which reduces a string to contain just words without punctuation and such. It was added in part to work on an issue reported with the tags feature in the field editor, but should be handy for other cases as well. As part of that update, the existing $sanitizer->word() (singular) method was re-written to support the features needed for the new words() plural method. This week I've also been working on a pull request from Bernhard that enables greater customization of AdminThemeUikit by way of custom render files and hooks. I'm bringing in that PR and it has a lot of good ideas that have inspired some related updates to it. I've got a bit more work and testing to do before committing, but that part should be ready early next week, along with more core updates. Thanks for reading and have a good weekend!

The term "hint" is a good here, but it's more than that. The purpose of any site profile (no matter how minimal) is to be a functional starting point. The blank profile is now the only core profile so most people will start with it. The /site/classes/ directory is important and is likely forgotten by all but the most experienced users, if it is not present. I think it belongs in the most minimal starting point. You have to have at least one file in a directory in order for it to remain through git, site profile and installation. Being the blank profile, the class itself is blank, a placeholder, like the directory itself. It exists to explain what the directory is for and the format files must use within it. It's a readme that exemplifies what it describes. Any site profile must be functional and it's worth noting that all site profiles, no matter how minimal, all have a "home" template (and an "admin" template). So a home.php template file and a HomePage.php class file are part of that minimal but functional starting point, even if blank.

ProcessWire 3.0.195 contains a few fixes and optimizations relative to the previous version. While there aren't major additions, if you are running a previous version of the dev branch it's a worthwhile upgrade. Version 3.0.194 added the lazy loading fields, templates and fieldgroups, but there were still a few cases where PW would load them all. This version corrects those few cases. So if you considered 3.0.194 to be a nice upgrade, 3.0.195 is an even better version of it. There are also some useful bug fixes in this version. One notable bug fix (found by Adrian) was that the $pages->findMany() method was lagging due to some changes a couple versions back (limited to dev branch). That's been fixed so now findMany() is fast again. Also a notable addition: the included site profile (site-blank) now includes a /site/classes/ directory with an example HomePage.php file/class that serves as both a placeholder (to ensure the directory exists in Git) as well as an example custom class for the “home” template. I thought this was a good idea because many might not even know about the custom page classes feature without that obvious pointer to the feature. More core updates and additions next week. Thanks for reading and have a great weekend!

@sz-ligatur It depends on the PW version. fopen used to be the default, but it's more and more common for allow_url_fopen to be disabled, so I've switched the default to CURL (when available) on the dev branch. In any case, with CURL, the flag that you set raw data with also makes it use POST, so I'm not sure how you send raw data (other than a file resource) with CURL using PUT, so you probably should make use use fopen for that case. You can force it to use fopen by specifying ['use' => 'fopen'] for the $options argument to WireHttp::send().

This week I've bumped the dev branch version to 3.0.194. Relative to last week, there are a few commits fixing minor issues. Last week we covered some fairly major updates and I've not come across any concerning side effects, so figured it's a good day to bump the version. Next week my kids are out of school for winter break so I'll be around but I don't expect I'll have much in terms of updates to report next week, but definitely will the following week. Thanks and have a great weekend!

@ErikMH Thanks for the additional info. I'm not yet sure what the issue could be, as I also use custom page classes here, but I I think by getting yours working we might find closer where to look. And I think to do that, some additional checks are needed in your code, which I'll try to describe below. The error message you've got appearing (that there is no getTitle method on NullPage) is a valid error message, as it is true that NullPage has no getTitle() method. NullPage is a valid return value from any Page method that can return a Page object. So we know at least that there is a line of code somewhere that is calling a getTitle() method before checking if it has a Page that would have that method. You can check for a NullPage by: if($p instanceof NullPage) { ... } or more commonly you can do: if(!$p->id) { ... }. That works because NullPage objects have an id of 0. In the debug backtrace we can see that home.php line 95 calls IssuePage::getEntry(). And then IssuePage.php line 43 is likely making a call that is returning a NullPage. I would add a NullPage check before calling getEntry() (home.php line 95) and then another on IssuePage line 43. That should prevent the error from occurring, and is something you'd want to have whether you were seeing this error in the first place or not. And by identifying specifically what change seems to fix the issue, that should point us in the direction of what method call might be returning something potentially incorrect (since you indicated it worked in earlier versions but not in the current). Once you identify the culprit, it would be helpful for us to know what that condition is where it's coming across the unexpected NullPage. So let's say $p is the page you are calling something on (like your getTitle), you might do something like this: $title = ''; if($p->id) { if(method_exists($p, 'getTitle')) { $title = $p->getTitle(); } else { bd("Page $p has no getTitle method (called from page $this)"); } } else { bd("Unexpected NullPage received in page $this"); }

@ErikMH The line producing the error you mentioned is making a $parent->getTitle(); call. What is getTitle() ? That's not a PW Page method, so I'm wondering if that's a method you've added in your custom page class? If so, and you called this on the page representing your homepage. The value of $page->parent would correctly be a NullPage, as you are seeing there. So even if we track down an issue causing this particular instance, I'm thinking you'll want to update your code to account for the possibility that a getTitle() method may or may not be present. Maybe this? $parent = $this->parent(); if($parent->id && method_exists($parent, 'getTitle')) { $theHTML = '...'; }

@flydev ?? Thanks, I appreciate that. I will look into this.

@kongondo It could but I would guess your bottleneck is quantity of pages, not fields or templates (?). So unless you literally mean hundreds-of-repeater-fields, for your case I think you'd want to enable the ajax loading features of the repeater (if not already) as that would make a big difference. It was a one-off thing that I used and deleted. Writing in the browser so it may need adjustment, but here's something similar (though a bit simpler than what I used): $fieldtype = $modules->get('FieldtypeText'); $title = $fields->get('title'); for($n = 0; $n < 1000; $n++) { $field = new Field(); $field->type = $fieldtype; $field->name = "test_$n"; $field->label = "Test field $n"; $fields->save($field); $fieldgroup = new Fieldgroup(); $fieldgroup->name = "test-$n"; $fieldgroup->add($title); $fieldgroup->add($field); $fieldgroups->save($fieldgroup); $template = new Template(); $template->name = "test-$n"; $template->label = "Test template $n"; $template->fieldgroup = $fieldgroup; $templates->save($template); } @ErikMH I'm not aware of any recent changes that would affect pages in that manner. But for your code, I would drop the $me = wire($this); there is no $me, there is only $this. ? And rather than referring to $me->parent; refer to $this->parent(); with the parenthesis, so that it is a method call rather than a direct access property. Since you are "inside" of the Page class here, the interface is a little lower level than if you are outside of it. Usually it doesn't matter but in this case of things like "parent" I think it might be safer to method calls rather than properties, because these things are dynamically loaded and so accessing the method ensures that happens.

This week we have some great performance and scalability improvements in the core that enable lazy-loading of fields, templates and fieldgroups, thanks to @thetuningspoon — https://processwire.com/blog/posts/field-and-template-scalability-improvements/

@Denis Schultz FormBuilder already has something like this feature in that it supports partial entries. But this FormAutoSaver does go quite a bit further in that it auto-saves as you type and it emails reminders to the user. FormBuilder auto-saves on paginations instead. Maybe it should be released in the FormBuilder board too. It's kind of a developer tool in that it takes a little code to implement into a form (while FormBuilder does not), so I was thinking ProDevTools was a good fit. But I'll either add a similar capability in FormBuilder or make this module available for FormBuilder users. For FormBuilder, I'll want to figure out how to make it an automatic option you can enable rather than one that you have to insert additional code for.

This week's commits include fixes for 8 reported issues and a couple new $sanitizer methods for entity encoding values in arrays. I mentioned earlier that I'd like to try and get a new master version out early this year and that's still the case. I've been successfully migrating some of the production sites that I work on to the dev branch, and so far, so good. Please let me know how it works for you. We're on track for a new master version hopefully soon. A couple weeks ago I mentioned a module I was working on for automatically saving front-end forms in progress. For the moment, it's it's called FormAutoSaver, but maybe I'll come up with a better name (or not). It emails the person filling out the form with one or two reminders with links to finish it if they leave it before submitting it. The emails are template-file based so fully under your control, and the delay in sending 1-2 reminders is also fully configurable, whether hours or days. This module is essentially finished and now I'm just writing the documentation. I already have it in use on 1 site and it's made a helpful difference, not just in getting people to finish their forms, but also in helping us to analyze where people tend to get stuck and stop filling out the form. It also comes with an admin tool that lets you browse the forms in progress and see where they are at. Whether you want to increase the completion rate of of any particular form(s), or you want to identify bottlenecks, I think you'll find tool helpful. You don't have to design your form for it, as it will work with any existing form. I expect to have this posted into the ProDevTools board as soon as next week. Thanks for reading this short update and have a great weekend!

I use the tools that ProcessWire comes with. I spent a lot of time making them simple and easy to use, and that's what I like to use. Just as an example, let's say that I've got a website and a client wants to add a full featured blog to it. I'll develop it on my local copy of the site and it might involve creating several fields, templates and template files. I'll take a day or two to develop it and when it comes time to migrate the finished work to the live server, that's the fun part, but there's not much to it: Create or export/import the new fields on the live site first, then do the same for the new templates. Copy the new or updated template files (and related CSS/JS assets) into place. Create or export/import the pages needed by the blog, and it's done. A blog is just an example but it's the same as any other update. It's a painless process that always goes quickly and smoothly. This part of it takes maybe 5 to 10 minutes and is one of my favorite parts of the project, like driving a new car and then seeing it for the first time in your driveway. I like to oversee this part of any project and have no need to optimize it further so guess I'm not the target market for add on migration tools. That's correct, it would be fairly straightforward.

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!

@bilioso You don't want the scheme in the httpHosts array, so you just want [ 'localhost', 'mysite.org' ]; or [ 'localhost', 'mysite.org', 'www.mysite.org' ];

@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 }

@adrian Thanks, I've pushed a fix for the IN() issue. For your other question, a blank 'references' array just means that there weren't any. Here's an example of what it looks like when there are some found (abbreviated print_r of the return value): $pages->findRaw("template=category", [ 'references.field', 'references.url', 'references.title' ]); Array ( [1017] => Array ( [references] => Array ( [categories] => Array ( [1061] => Array ( [url] => /pwsite/blog/posts/2-factor-authentication-coming-to-processwire/ [title] => 2-factor authentication coming to ProcessWire ) [1153] => Array ( [url] => /pwsite/blog/posts/processwire-3.0.109-adds-two-factor-authentication/ [title] => ProcessWire 3.0.109 adds two-factor authentication ) ... without "references.field" it looks like this instead: Array ( [1017] => Array ( [references] => Array ( [1061] => Array ( [url] => /pwsite/blog/posts/2-factor-authentication-coming-to-processwire/ [title] => 2-factor authentication coming to ProcessWire ) [1153] => Array ( [url] => /pwsite/blog/posts/processwire-3.0.109-adds-two-factor-authentication/ [title] => ProcessWire 3.0.109 adds two-factor authentication ) ...

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!

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!

Happy New Year! Hope that you all have a great end to 2021 and start of 2022. No major core updates to report this week, just a few minor issue fixing commits, so no version bump today. The dev branch is getting close to 100 commits (and at 7 versions) above the master branch, and with even more improvements/fixes/optimizations than that. So we may try to get a new master/main version out in early 2022, as I'd really like to get more master versions out in 2022 than we did in 2021. Some portion of our audience does not use the dev branch where most of the activity happens, and so it might be nice to share more of that activity on the master/main branch. That's one of many things I'm thinking about as the New Year approaches and am certain 2022 is going to be a great year for ProcessWire and the community. Hope that you have a great weekend and Happy New Year!

Sorry about that, I've pushed a fix for that issue. Thanks.

This week there have been various small core updates and fixes but the biggest change was to the installer in 3.0.191. Last week we removed all but the site-blank profile from the core, cutting in half the size of the core. And because of this, the installer now needed to provide more direction about downloading and installing other site profiles. So it now does that and it also links to a new page that describes all of the past and current site profiles, along with additional details on how to create and install site profiles. Speaking of creating site profiles, the Profile Exporter module was also updated this week. It is now PW 3.x exclusive and is updated to recognize and work with various aspects and $config properties that are specific to 3.x. ProcessWire 3.0.191+ and the Profile Exporter module now support a custom /site/install/finish.php file which is a template file that is called when installation of a new ProcessWire and site profile has finished, but before it has cleaned up the installer. It is a plain PHP file that has access to PW's API and the installer, so it can do pretty much anything you could do from a regular template file or module. I added this because I noticed a few issue reports for the Profile Exporter module were requesting support of one thing or another, and I found that nearly all of them could be added just by having a profile-specific finishing file, for those that want it. So if you want your site profile to perform any other types of customizations on top of what you can already do with a site profile, this is the place to do it. This is where things are at this week but perhaps we'll continue to go further with the installer in supporting more things too in the new year, as there have been several good ideas. Thanks for reading and I hope that you all have a Merry Christmas and/or Happy Holidays!

@cpx3 I pushed another update to the module today and removed the version constant from it, just in case it's affecting something. Try to download a fresh copy to see if that fixes it?

This week ProcessWire has gone on a diet. I've been working on reducing the size of the core by moving all (except site-blank) installation profiles out of the core and into their own repositories. This cuts the size of the core in half, going from 15.5 MB down to 7.5 MB, which is quite a slim down! This means the site-regular, site-default, site-beginner, site-languages, and site-classic now live in their own dedicated repos on ProcessWire’s GitHub. The site-blank one remains, but I've updated it a bit to make the template files more useful for beginners while still keeping it a blank profile. I may do a little more with it and rename it to be site-basic or something, and then have an even more trimmed down site-blank in its own repo as well. I'm not yet sure about that, so will do a little more with it next week also. I also went through each of these site profiles and cleaned up a few things, corrected old and outdated links, and updated a lot of text in readme files and such. I think a lot of the more experienced users would also prefer not having extra profiles included in the core as well. This update came at the request of the community a few months back (I think it was Robin S. that requested it, but not positive). It's not like any of the current site profiles have a lot of bling or marketing value, as they really are more just technical examples and starting points. So I think it's kind of a win/win to trim down the core in this way. Though maybe one day we'll have a site profile that looks good and has good marketing value. But until then I think we gain more by keeping the core size nice and trim. The downside is that there's a little more for new users to figure out (downloading a profile), so in the next week or so I'm planning to update the installer to hopefully lessen that issue and maybe even build in the ability for the installer to download and install site profiles from the modules directory. That comes with its own security considerations, so I'm not yet sure we'll go that far just yet, but it's one of a few options I'm looking at. Thanks for reading and have a great weekend!

@sebr The color codes go in the "Header labels" not the "Item label". It looks like you put the colors in the Item label instead. If you just move it to the Header label, that should fix it.