ryan

@adrian It's definitely possible, and maybe we'll add the option for that. For this first version though it loads all the data in the field in the same way that other PW fields do. But you are right that it would likely be relatively simple to have it load them dynamically.

Last week’s post was about the new ProFields Combo field and it seemed like there was a lot of interest. Thank you for that, it really got me motivated to finish it and release it sooner rather than later. I am very excited about the Combo field and worked on it most of this week, hoping that I may be able to have the Beta version ready for release in the ProFields board by this time next week. This is a little more break than I like to take from the core, but the focused development time means it gets done a lot sooner, and likewise in a stable release state a lot sooner. Since I don’t have core updates to walk through this week, I thought I’d focus on some Q&A about the Combo fields. Below are questions that were asked either here in the forums or in the blog post. Please feel free to reply with any other questions that come up too. There are definitely cases where this type of arrangement Combo provides would provide some nice performance gains. And there are other cases where they might reduce it. Consider that fields on a page in ProcessWire are dynamically loaded when you access them. So when you access anything from a Combo field, all of the data in the Combo field loads at once (1 query). So if you’ve got 10 fields in a Combo field, and you are going to be using much of that data in the request, then you’ve just made some nice performance gains, at least relative to having those 10 fields split into dedicated/separate ProcessWire fields. On the other hand, perhaps you are rendering a list of pages, and you only need one or two fields of data from the Combo field. In that case, it’s less efficient than regular ProcessWire fields because you’ve loaded a bunch of data in memory that isn’t going to get used. So I would say Combo fields are great for data that you use when rendering a full Page, but not as great for cases where you are rendering lists or summaries of pages (where you might not be using much of that data). In the blog post I mentioned that Combo fields store data in individual DB columns, but also keep a separate index so that all of the combo data can be searched together. If that’s what you are referring to, I would say the primary downside of this storage method is that it takes up more space. It adds convenience and efficiency for searching, but at the cost of consuming more disk space [in the database]. This is something that may be beneficial to some and less so to others, and it may end up being an optional thing too. The index is similar to a JSON encoded version of all the fields. But it’s something that I think is worthwhile for another reason: backups. Like the Table field, the Combo field maintains a unique DB schema consistent with your selection of fields. Every time you save a Field, it checks the schema and determines whether to add columns, drop columns, or modify existing columns (and likewise for indexes). The JSON encoded version of the data is immune from data loss as a result of schema changes, so I see it as potentially useful as a way to backtrack, should it ever be needed. As for your question about other fields in ProcessWire, Combo stores it exactly the same way as other fields, with the only difference being that it keeps a separate combined index of data; and is able to because the core Fieldtype architecture enables it to do so. Why not use the same duplication approach with other fields? I can't think of any core fields where this type of storage duplication would be beneficial in the way that it is with Combo. Outside of the core, the approach might be worthwhile in ProFields Table though. Yes! Combo fields work in Repeater and RepeaterMatrix fields. Since Combo fields are not a repeatable type, they play nicely with repeatable types. They might look similar but they are also completely different. A page fieldset (FieldtypeFieldsetPage) is technically a single repeater item, but presented in a non-repeatable way. It’s a convenient way to make a group of fields that you could reuse across any number of templates. And in that respect it’s quite similar to Combo, at least in appearance. But that appearance is where the similarities end. Fields in a FieldsetPage are still individual ProcessWire fields defined on a template, and the Fieldset itself is an independent Page (an individual repeater item behind the scenes). So if you’ve got a FieldsetPage with 10 fields in it, then it’s still consuming the resources of 10 ProcessWire fields, plus 1-2 additional pages for structure. The goal of ProFields is to reduce the number of fields necessary to answer a particular need, and that is not the goal of FieldsetPage. If a Combo field can answer your need, it can do so a lot more efficiently than a FieldsetPage can. On the flip side, since FieldsetPage uses regular ProcessWire fields, it can support more types than Combo can. Nevertheless, once Combo is available, I would most often choose it over a FieldsetPage except in cases where I needed a type of field that only FieldsetPage could support. Yes, any field within a Combo field can be queried individually in selectors using the field.subfield syntax. For example: $pages->find(“combo.first_name=Ralph”); It’s just like querying a Page reference field on pages in ProcessWire. So far, my experience is that it can do all of the same things, and supports all of the same operators; whether querying text, numbers, Page references, selectable options, etc. There are technical differences behind the scenes though. All the data in a Combo field for a page is represented by a row in a database table, so matching some types of values (like multi-Page references) has to use indexes rather than lookup tables. This is similar to the approach taken in the Table field. Per last week's post, Combo fields can do one thing that other fields in ProcessWire can’t though. Because it keeps an index of combined data, you can perform text matching on all of the subfields in a combo field together, just by omitting the “subfield” from the selector. An example is that $pages->find(“combo~=Ralph”); would find the word “Ralph” in any of the fields in the Combo, rather than just the first_name field. So not only is it easy to do, but it can do that more quickly and efficiently than other fields in PW. Thanks for reading and have a great weekend!

@matjazp @adrian Looks like we've got a glitch there. Not sure what's up yet, but it seems to be in the old modules directory data and may have been there awhile. Matjazp had 2 accounts somehow and tpr/rolandtoth had none. I added rolandtoth as an author and updated the modules pointing to his GitHub account. I deleted the 2nd matjazp account (matjaz-potocnik) and reassigned those modules to the matjazp account. Let me know if I didn't get any of this right. So far it looks like there is the only case of the glitch, I couldn't find any others like it, though please let me know if you do. By the way, module author names were pulled from the info entered when the module is submitted or edited (on the old modules directory site). They are not pulled from the module info on GitHub. On the new site, module author names are created with the account, and assigned to existing modules sharing the same confirmed email address. That's how it knows which modules are yours after you create your account. Some people might have used multiple emails over time, as I think both Teppo and I did, so in those cases I've been assigning some modules manually. Currently for new modules it just supports one "author", since it is now tied to a dedicated account. (Just like with a GitHub account). So when there are multiple authors on a new submitted module then the README is where you'd want to highlight that. It would also be fine to have an organization or company as the author of course, but it would still just be 1 account.

@adrian Thanks, I have fixed it so it'll update the "updated" date when either the version number, or anything in the module info changes.

This week we’ll take a brief look at a powerful new ProFields module for ProcessWire that’s just around the corner—the Combo field: https://processwire.com/blog/posts/about-the-new-processwire-profields-combo-field/

@MSP01 Thanks for the feedback. 1. I couldn't duplicate that, when searching "admin action" it does find ProcessAdminActions for me at least. Though several days have passed so maybe Adrian recently updated something in the module info that makes it match. 2. The class name is the primary headline. But someone else mentioned this too, I will add something else that specifically indicates it. 3. I also can't seem to duplicate this. Those pages should be redirecting to the new modules directory URLs. Maybe it got stuck on that one for one reason or another. I have cleared the caches just in case.

@nbcommunication I'll have to investigate further, maybe it's possible to support down the road. For the moment, compatibility is based on what you specify in the "requires" section of your getModuleInfo() method, or ModuleName.info.json file or ModuleName.info.php file. But since you are wanting to communicate that the module is not compatible with a previous version of itself, I don't think there's an automated way to do that at present. For the short term at least, if you can't update the module to provide a backwards compatible option, then it might be worth maintaining as two separate modules. Or if you only want to maintain the new one, then maybe give the new one a new name and delete the old one, or update the old version README to instruct the user further. That would at least prevent anyone from automatically upgrading the module and finding it doesn't work.

ProcessWire 3.0.169 contains 19 commits relative to 3.0.168, and most are focused on improvements and minor fixes throughout the core. For more details see the dev branch commit log. This week I’ve also been working quite a bit on a new ProFields module that at the moment is called Combo. It contains both Fieldtype and Inputfield modules within it, and I’ll have more to tell you about it soon. But I can say that it fits right in with the purpose of ProFields, which is: greatly reduce the number of fields needed to accomplish a particular need. And it does so in a way that isn’t easily achieved with any other module at present, so I think it’ll be a nice addition. The Inputfield part of it can also be used independently of the Fieldtype, meaning you could use it in FormBuilder forms, etc. I’ve got to keep it short today because of the Thanksgiving holidays here in the US (my wife is off work and kids have no classes today). Thanks for reading and have a great weekend!

@Ivan Gretsky GitHub is a requirement for modules that are automated with regard to automatically pulling version and readme, etc. If someone needs a case where the module can't be managed at GitHub (like a commercial module or other specific case) then I would just ask them to contact me so I can add it manually. I feel it's safest for our users by having downloadable modules provided by GitHub. They have security measures in place that give me a lot more peace of mind than a link to a random ZIP file off on some site none of us know. Without GitHub as a middle man, I think there's a much higher probability of getting something questionable in a ZIP file, whether it's because of a hacked site or any number of other reasons. GitHub also provides great security options for protecting individual accounts, which I think further increases the safety for consumers of ProcessWire modules. The other side of it is that GitHub provides an API that we can read data from in order to ensure our module information is up-to-date and that users don't have to manage that information in more than one place. That API also includes a function to safely convert GitHub-flavored markdown to HTML, which is very useful for the modules directory. Presumably it would be possible to also implement this for other providers (GitLab was mentioned), so if there's significant demand for it then it would be worthwhile. But it took me a long time to implement the GitHub integration as it is, and at present I likely couldn't afford the time investment to implement another different API right now. Down the road I'm open to adding support for more Git providers. For now though I had to work within the bandwidth I could afford to devote to this project. @Mikie The module class name is used throughout, but it's true it doesn't literally say "class name:" anywhere. I think you are right it would help with clarity if it does that somewhere, so I'll plan to add it. As for version compatibility, I'm going through all of the PW 2.x modules and deleting any that aren't 3.x compatible and don't look like they will be. This will take me a little while, but basically the intention with the directory is that you can assume it's 3.x compatible. For more fine grained detail on version compatibility, it's going to read the module info array. It doesn't report that info at present, but this project isn't fully finished yet so it will be reporting more from the module info array in the coming weeks.

There’s a new modules directory on the ProcessWire site now up and running. In this post we’ll cover a few details about what’s changed and what’s new. While last week's post introduced the modules directory, this post (part 2) focuses on newly added features for module authors (just pushed live today)— https://processwire.com/blog/posts/new-processwire-modules-directory/

@adrian The modules directory does not distribute Pro modules or track their version numbers. Though I am planning to have it track version numbers for Pro modules, but that'll be added on once the rest of it is finished. Pro modules will continue to be distributed through the dedicated support boards since IP.Board manages the access for all of it. Maybe someday I can build more in that regard, but I don't have the bandwidth for that currently. The new modules directory makes no changes to the web services portion, which will continue to be provided by modules.processwire.com. I didn't want the changes to interrupt anything, as the web service gets quite a lot of traffic. @Ralf Thanks for the suggestions. I will look into it further. I have found that searching the body for modules introduces a few too much noise into the results, but including the module summary in the search might be a good middle ground. The keywords are of course a good idea too.

This week I’ve been continuing to work on the new ProcessWire modules directory, this time focusing on the front-end editing aspects for module authors. This is the part that deviates the most from the existing modules directory (and makes revolutionary improvements upon it), so none of this is on the production server yet, and it’s going to take a little more time to develop. LoginRegisterPro and FormBuilder are saving a lot of time in the development. LoginRegisterPro handles the account management side, while all module editing forms are powered by FormBuilder. By next week I’m hoping I might be able to launch the new editing features so that module authors can begin to use the system, but we’ll see how it goes. This week there have also been several updates to the core dev branch, including both improvements and issue fixes. By next week I also expect to bump the version to 3.0.169. For more on the modules directory improvements, be sure to also see last week’s post.

@adrian Thanks, pagination fixed. I meant to mention about non PW3 modules above, that I'm going to be removing them from the directory, or at least from the generated lists that it outputs. I don't think there's any need for the directory to maintain PW2 modules anymore, but I wanted to go through them one-by-one just in case there are any that are mislabeled as PW2, or maybe some are still actively developed and work with PW3. But the reason the new modules directory doesn't say anything about PW version is because it was going to be exclusive to PW3 compatible modules going forward.

This week I’ve continued work on the new modules directory and today have launched an updated version of it on the site. This is just an initial version of it, as there’s still plenty to do. But the basics are up and running if you’d like to take a look at https://processwire.com/modules/ The new modules site is using ProcessWire’s multi-instance support to boot a copy of modules.processwire.com and to pull and manipulate data from it. In order to prevent content duplication, I’ve setup most of the pages at modules.processwire.com to redirect to their equivalent versions in processwire.com/modules/. There’s not much new here in terms of data that is being displayed, though it is also different in several ways. For starters, it finally has the look-and-feel of the main site. The modules homepage takes a different approach and lists 3 modules each in these different sections: Recently added modules Recent updated modules Popular modules Modules recently liked by users Modules in the “recently updated modules” section are those that have had recent commits at GitHub. The “popular modules” section randomly selects 3 modules that have a certain threshold of “likes” quantity and date of user activity, combined with being updated within the last 6 months. Or you can view them all (no random selection) at the dedicated popular modules page ... this section will grow as users interact with it. The “modules recently liked by users” section looks for modules that have had the “like” button clicked on recently, and puts them into this bucket. Like the “popular modules” section, this one will grow and increase in relevance once there is more user interaction with the new modules directory. There’s also a new feature on this modules site where you can maintain a “cart” (of sorts) that keeps track of which modules you have liked. In addition, the new modules site estimates how much usage each module has by analyzing request data from the ProcessWire modules web service. This is something the old modules site does not do. It uses this data solely for providing a unique sortable view of modules. Because this data hasn’t been tracked for long, it’ll increase in relevance over time. One area that I want to build out quite a bit more is the module “authors” section. Since the new modules site will be using authenticated login sessions with LoginRegisterPro, we’ll be able to maintain a lot more “profile” info for module authors (full name, bio, photo, website, anything else?) There are a few things still in development, so you won’t see them just yet: Edit module ability (it directs you to the old modules site for that) Add module ability (also directs you to the old modules site) Informational pages (how to install modules, etc.) More to come here, but that’s where it is now. Nothing all that exciting I know, but still an improvement hopefully. If you find anything that isn’t working, or have other feedback or suggestions, please let me know. Thanks for reading and have a great weekend!

We got hit by hurricane/tropical storm Zeta overnight Wednesday and it took down the power lines in our neighborhood, and in many places in Atlanta. We aren’t supposed to get the electricity back till Monday, though I’m hoping they might surprise us and have it back sooner. But I’m basically offline other than my cell phone, charged in the car. I work off a desktop computer (iMac) so not able to do any kind of computer work until the electricity is back. As a result, I don’t have any updates for you this week. Though I was making great progress on the ProcessWire modules directory site up until the storm came through and we lost electricity. For now my job is to keep the flashlights working and find ways to keep what’s left of the food from going bad (since the fridge/freezer is also offline). The same thing happened with hurricane Irma, back in ProcessWire 3.0.75. It took out the power for several days. Though we weren’t in the middle of a covid hotspot back then. The deal is that Atlanta has a lot of big old trees, and all the power lines are above ground. So any time a significant storm rolls through, it knocks down a tree, the tree knocks down a power line, and the power goes out. Atlanta is pretty big, so multiply that by a few hundred trees and power lines (and a pandemic), and much of the city is out for awhile. Even a little storm sometimes knocks out the power for a few hours. That’s just one of the joys of where I live. I’m sorry about that, but since we’re supposed to be back online by Monday, I expect to have good updates for you next week. Thanks for reading and have a great weekend!

ProcessWire 3.0.168 contains 16 commits relative to 3.0.167 and is focused largely on minor issue fixes and improvements, with 8 reported issues fixed and 8 improvements. This week the larger focus was on the ProcessWire modules site. I finally got some serious work done with that this week, and am building good momentum. The front-end of the modules site is being moved into the main ProcessWire site, though the back-end will remain an independent ProcessWire installation. The main ProcessWire site uses multi-instance support to boot the modules site whenever it needs to pull or update data from it. Here's a simplified example: $site = new ProcessWire("/htdocs/modules.processwire.com/"); $items = $site->pages->find("template=module, sort=-created, limit=10"); echo $items->each("<li><a href='/module/{name}/'>{title}</a></li>"); The nice thing is that I’m finding performance to be excellent here, about the same as if I weren’t booting multiple ProcessWire installations. I’m sure there’s some overhead if measured, but it sure isn’t felt. One thing I did learn is that when it comes to pagination, if you want your separately booted site to be aware of the current site’s pagination, you need to tell it the page number. Otherwise the bit of code above will always return the first 10 modules, regardless of pagination number. It seems obvious now, but it took me a minute to realize why. So if pagination is being supported, you'd add this before the $site->pages->find(...) in the example above: $site->input->setPageNum($input->pageNum); For front-end work like this, it's also a good idea to tell your booted site if you want output formatting enabled, so that page titles and such come out entity encoded, for example: $site->pages->setOutputFormatting(true); ...or if you prefer the shorter alias: $site->pages->of(true); One big difference with the new modules directory is on the management side for module authors. This part is powered by LoginRegisterPro so that now you have an account to manage all of your modules within. Further, you have the option of maintaining your module author public profile and protecting your account with PW’s two-factor authentication. That's just for starters. All of this is in the early stages of development, but if the development schedule remains as planned, I’ll be following up with more info over the coming weeks, in addition to the regular core and module updates. Have a great weekend!

@alexmercenary Thanks, glad that you are liking this module (saw your post in the FormBuilder board too). Makes my day actually, thank you. This is a module that I thought was necessary to build before December, when SCA in Europe will apparently be a requirement. I wasn't able to find a way that the existing Stripe Inputfield could be updated to support 3D Secure, at least not in a way that would be reliable with the form workflow. Basically, with 3D Secure, the charge takes place at the time the user inputs the card and an independent popup verifies it. So if the card collection is part of another form (as the Stripe Inputfield is), and someone pays but never submits the form (or submits but never fixes validation errors), you end up with an orphan charge. Stripe's solution to this scenario is that you should issue a refund. I thought that was too much for people to keep track of (charges that are missing a form submission). So thought it was necessary to build this module and include it with FormBuilder, especially for any of those in Europe that might already be using the Stripe Inputfield.

@rick If you needed to back out of the payment screen, I haven't yet found a way to make the browser back button play nicely here. But Stripe provides a back button for this purpose though (see the ProcessWire logo on the left where it has a left arrow and says "Back" when you hover), and this one does enable you to effectively cancel the transaction and return to the form.

This week a second new module for processing Stripe payments has been added to FormBuilder. Unlike our other Stripe Inputfield for FormBuilder, this new one uses Stripe Checkout and supports 3D Secure (SCA) payments. We’ll take a closer look at it in this blog post, plus we’ve got a live demo of it here too— https://processwire.com/blog/posts/stripe-payment-processor-form-builder/

Last week I told you how I was working on a getting a new Stripe payment method working with FormBuilder… and I’m still working on it. That wasn’t exactly the plan. Stripe isn’t quite as easy to work with as it used to be, or maybe Stripe thinks I’m not as easy to work with as before. Either way, I’m learning, and it’s been a good opportunity to expand FormBuilder with its own class for plugin “action” modules. Hopefully some of this work on the Stripe side can apply for other payment methods, or any type of action you’d want to take with a form submission. It’s probably going to take another week or so before this module is ready to release in the FormBuilder board, but it’s going to be built well and accompany a new version of FormBuilder too (that supports these plugin actions by way of PW modules). Having these actions as ProcessWire modules opens up new doors for FormBuilder, and I may even move some of the built-in actions (like saving to Google Sheets) into this type of module, which would be nice for hooks and maintainability. There’s not a lot to report on the core side this week. There are a few commits and improvements, but not yet enough where I’m ready to bump the version to 3.0.168. One small but useful improvement is that handling of selector queries for words with apostrophes has been improved. One of my clients noticed they were having trouble with their site search engine matching terms like “Alpe d’Huez” and “L’estello”, and so our page finding engine has been improved to narrow them down with the fulltext engine and then find the exact matches with regular expression queries. This improvement enhances most of the partial text matching operators. It also solves the issue of there being different kinds of apostrophes (ascii straight vs utf-8 curly), among other things. Overall the core is running running very smoothly on the dev branch, so I’m thinking we may try and do another merge to master before 3.0.170. Thanks for reading and have a great weekend!

This week I’ve been working on updates for ProcessWire 3.0.168 as well as a new Stripe payments module for FormBuilder. In the core, the ProcessPageView module that handles all requests got a pretty significant refactoring. While it was largely focused on optimization, I also just like to go in every few years and rewrite stuff in high traffic modules like this to keep the module fresh, as well as keep my mind fresh on how it all works. I find there’s often room to do something better. The ProcessLogin module also got some upgrades this week that are primarily focused on maintaining the contents of a request URL in the admin between guest and admin user states. Now it can retain most query strings in a request URL after login. There’s still more to do in 3.0.168 so the version bump isn’t being made this week but may be ready next week. So far there are also a couple of GitHub issue resolutions and $sanitizer method improvements as well. On the FormBuilder side, we have the Stripe payments Inputfield, but since that module has been built, Stripe has released new APIs to handle SCA payments (soon required for EU transactions). With these types of payments, as I understand it, a multi-factor type process takes place where the user confirms the transaction with their credit provider. So it changes the payment flow quite a bit… enough that I’ve found the current Stripe payments module can’t really be adapted for it, at least not in a reliable way. That’s because the new API requires that the payment take place interactively before the form is submitted, since the user has to manually confirm it outside the form. So this will inevitably lead to cases where a payment has been charged but the final form isn’t submitted for one reason or another. Maybe it would work most of the time, but it just doesn’t seem like a reliable transaction flow to me. For this reason, I’m building a separate module for FormBuilder that provides a better alternative for the SCA transactions. With this module, the user submits the form, but FormBuilder saves it as a partial/pending form submission. Following form submission, the user goes through the SCA payment process with Stripe. When that completes, Stripe sends a webhook to FormBuilder that converts the form submission from pending to completed, at which point emails are sent, FormBuilder actions executed, etc. So it's Stripe that submits the final form, rather than the user. I’ve got a lot of work still to do here, but since a few people have contacted me looking for SCA support with Stripe payments, I just wanted to keep you up to date and let you know it’s in progress. The existing InputfieldFormBuilderStripe module will of course continue to be developed as well, as most regions outside the EU do not require SCA. Thanks for reading and have a great weekend!

ProcessWire 3.0.167 is the newest version on the dev branch and contains the updates mentioned last week, as well as the following: Improvements and optimizations to several database fulltext index-based text-searching operators (such as *=, ~=, *+=, ~+=) so that they can better match words too short to index, as well as many stopwords. (code changes) New $input->queryStringClean() method is like the existing $input->queryString() method except that it enables you to get a cleaned up version according to rules you specify in an $options argument. I added this method primarily because it’s something I need in the core for some planned updates. But it’s in the public API because I thought it might be useful for some other cases as well. Kind of technical, but some minor improvements to the $sanitizer array methods were made so that they can now support associative arrays with a ‘keySanitizer’ option that lets you specify which sanitizer method to clean up array indexes/keys. The $sanitizer->validateFile() method was rewritten and improved plus new ‘dryrun’ and ‘getArray’ options were added. The core file and image fields have been updated with the ability to require (rather than just utilize) a FileValidatorModule for certain file upload extensions. This was motivated by SVG files being increasingly problematic (or at least my understanding of them) because they can contain the kind of bad stuff that regular markup can (scripts, loading external assets, etc.). But since SVG files are used by many just like the bitmap image formats (JPG, GIF, PNG, etc.) exploits can spread quite easily and unknowingly. I’m not aware of that ever occurring in a ProcessWire site, but it’s one of those things that strikes me as being an inevitable problem for any website (on any software) that has regular SVG uploads. ProcessWire doesn’t allow SVG file uploads by default, but you can manually add “SVG” to your allowed upload extensions for any file/image field… and from what I understand now, a lot of people are doing this—using SVG files not just during development, but as an image format that their clients upload too. The usual protections of having a trusted user admin environment don’t help much here. That’s because what matters is not whether the uploading user is trusted or not, but whether the source of the SVG is trusted. And that’s something we have no control over. It seems apparent the core could provide some extra help and guidance in this area. So ProcessWire now requires you install the FileValidatorSvgSanitizer module if you want to have SVG uploads, OR you can check a box in the file/image field settings to whitelist the extension (acknowledging you understand the risks). Now you could manually add HTML or JS as allowed upload extensions to a files field as well— and if you are rendering the resulting HTML markup or JS directly in the code of your website, then the same risks would be present as with SVG. But the risks seem obvious for doing this with HTML or JS files. Plus, why would someone do that with HTML or JS files unless for some very specific development purpose? I think it’s unlikely any of us are running websites where clients might be downloading HTML or JS files from other sources and uploading them into the website. And even further unlikely that we’d written the site’s code to include the contents of those files among the site's markup. Whereas, this is essentially what happens with SVG files, from what I understand. As I’ve come to learn this week, it’s even quite common to do this (maybe I’m late to the party). Given the above, this week I rebuilt the existing FileValidatorSvgSanitizer module from the ground up, so that it now uses a better/newer SVG sanitization library found by Adrian. I’d suggest installing the module if you are supporting SVG uploads in your site. It seems to do a nice job of cleaning the harmful stuff out of SVG files. I’m not aware of anything it can miss, but I’d still advise some caution with SVG file uploads even if you have the module installed. If you currently allow SVG file uploads but don’t really need them, just remove SVG as an upload option, as that’s still the safest bet. That’s essentially what the current dev branch version does: if you’ve added SVG as an allowed upload extension, it’ll disable it until you decide if you need it; and if you do, then install the sanitizer module or whitelist the extension. I know not everyone is going to like that, but it seems like it’s the right and safe thing to do; as well as a good strategy going forward for any other file formats with similar concerns. When our next master version arrives, it’ll be in the upgrade instructions as well. The core has been updated so that it can support the same means for any other file formats we come across in the future that might be problematic in similar ways. That’s everything I can remember that’s new to 3.0.167. Thanks for reading and have a great weekend!

This week the core version remains at 3.0.166, but 3.0.167 should be ready by next week. The main reason I'm not bumping the version is just because a couple additional updates I want to get in 3.0.167 are started by not yet fully finished. Below is a look at what's been committed to the dev branch this week so far: Added custom Page class support for the Language class by implementing your own LanguagePage class that extends it (i.e. /site/classes/LanguagePage.php). Added a PR from MoritzLost with improvements to the CURL support in the WireHttp class. Added a new method to the Fieldtype interface named getMatchQuerySort() this method lets a Fieldtype module optionally manage the query when a $pages->find() requests a sort by a field/subfield handled by the Fieldtype. The first implementation of the getMatchQuerySort() method was added for FieldtypeOptions, which now lets you sort by option values or titles, despite those values and labels being in a separate table that the rest of ProcessWire doesn’t know about. Added a new getAfterLoginUrl() method to the Process module interface which lets Process modules optionally sanitize and validate request URLs to the module for a non-logged-in user. The resulting URL can be automatically redirected to once the user has logged-in. While the method has been added and implemented in several core Process modules, it is not yet used by the core after login—that will come next week in 3.0.167. Previously the only aspect of an admin URL that could survive login was an “id” integer in the query string. This week there were also several optimizations and improvements made to the PageFinder class and resolutions to 4 issue reports. Thanks for reading, have a great weekend!

@netcarver You'll be glad to know that's exactly what changed with the redirect method in 3.0.166— The optional 2nd argument is now an http status code, enabling you to send any redirect status that you want, so long as it's somewhere in between 300 and 399. So if you wanted to send a 303 "see other" redirect, then you would do it like this: $session->redirect('http://domain.com/path', 303); The method of course also still accepts true or false to mean 301 and 302, and the default is still 301. The new location() method sends only a "Location: url" header without an http status code, which browsers interpret as a temporary redirect.

This week ProcessWire version 3.0.166 is released on the dev branch. In this post we’ll cover all that’s new relative to the previous version, 3.0.165. Plus we’ll check out the latest new versions of ProCache and FormBuilder— https://processwire.com/blog/posts/pw-3.0.166/