ryan

No blog post this week because I don’t have anything new or interesting to write about just yet (unless you like to hear about repairing fridges and clothes dryers). But I’ve been focused primarily on completing the FormBuilder updates that I mentioned in last week’s blog post, and it’s looking very good, though I’ve still got a little further to go with it. When it comes to multi-page forms, I’m trying to cover all of the exceptional cases where sessions expire, cookies clear, etc., and want to make sure a form-in-progress continues to work through all these situations. Multi-page forms can be potentially long and people can invest lots of time in them (relative to regular forms), so trying to make it all as resilient as possible. This takes lots of time developing and testing, so that’s what I’ve been doing. I’ll be doing some of that next week too, though also have been planning to dig back into the core issues repo and start working through some of those in preparation for a new master version this Fall. Hope you all have a great weekend!

@dragan Thanks for testing it out. I don't think it's the query string, as the Toggle field doesn't work with query strings or GET var input. I'm guessing more likely is that AoS is applying some kind of customizations or JS events to radio inputs, and these are conflicting with the events that Toggle uses to make radio inputs look like toggle buttons. Why it's only affecting the "Yes" state though is strange, as I'd expect it to affect all the state, but maybe it has something to do with Yes being the first in the list of inputs, or something along those lines.

Glad you found it. Any particular feature in that module that you found is interfering with the toggle field? Maybe it's something I can test with and work around.

@wbmnfktr I haven't worked out all the details of this part yet. But fields in an integrated form are still present when it comes to what actions can do with them. They are just renamed to have the field name that represents the "form" field as a prefix for each field in the integrated form. So anything that maps the fields in a form to something else (like a page or spreadsheet) will likely continue to work the same way that it currently does, but would have the integrated forms "opened" (for lack of a better term) so that their fields can be mapped like the others.

@teppo I'm not sure why that is. Maybe it needs me to add a version tag to it to jog things loose? Anything else you can think of I should test or try from here?

@Robin S Not yet interactively, though it is possible with hooks. Though I do plan to make it part of the "Form" field settings once the field gets more mature. Yes. Existing dependencies in forms you integrate will continue to work, and you can also make fields in the main form be dependent upon fields within an integrated form. The field name for fields in an integrated form is "formName_fieldName" rather than just "fieldName". That's how you can integrate multiple copies of the same form, and still end up with unique field names. So if using dependencies, then you just refer to the "formName_fieldName" in your dependency. For existing dependencies in an integrated form, FormBuilder takes care of converting those for you, so that the dependency works regardless of where else the form is used. Each page is validated independently. It creates a partial entry on the server side (in the DB) and saves it on submit of every pagination. If there are errors on the pagination you submit, it will stay on that pagination until you fix them. Yes. Partial entries also have their own URL (unique query string) that can be bookmarked or returned to if someone doesn't want to complete it all in one setting or their session expires, etc. Yes, but probably not in the first version. Though this is part of the reason why it's setup so that partial entries have their own URL. The page number can be specified in the query string. Any pagination has access to the entire entry server side (should you want to examine anything with hooks), but the front-end/client side only knows about the current pagination. So dependencies across paginations won't work at present. If there's interest in the feature, the plan was to support it by rendering the non-present Inputfields referred to on any pagination's showIf/requiredIf values within the current pagination, but behind a hidden element. In that manner, they are technically present for the pagination's processing and front-end JS, even if not visibly present.

@dragan @matjazp I setup a new toggle field exactly as shown in the screenshot, but can't duplicate the issue. Maybe it's something browser specific or maybe it's getting interference from some other module? Do you see any JS errors? Any other factors you can think of?

This week we’ll take a look at a new version of FormBuilder that's on the way (with a screencast), as well as the latest version of the core: ProcessWire 3.0.140— https://processwire.com/blog/posts/pw-3.0.140-and-formbuilder-v40/

This latest version of ProcessWire on the dev branch adds a new Inputfield module called “Toggle” that is an alternative to the existing Checkbox Inputfield. It also adds a nicer way to make column width adjustments to your fields when editing a template. This post covers all the details with screenshots and a short video: https://processwire.com/blog/posts/pw-3.0.139/

@bernhard Making it hookable should be fine. But I'd like to better understand what you mean about it not working in the admin, and the url and filename methods never getting called? Are you using the core files/images field? Those methods/properties are the ones used for anything asking for the filename or url of a file, whether on the front-end or in the admin. For me at least, it works the same in the admin/page editor as it does on the front-end, just tested again to confirm—editing a page downloads the images, and they appear in the images field in the page editor. So I'm not sure I understand what you mean? Also, hooking setFilename() would make it less on-demand, as it would download any images in the field rather than only those that were specifically requested. Can you think of anything different about your environment that might account for it not working?

Hope you guys are having a great week. I'll keep this week's update short since everything I'm working on is in-progress rather than ready to post. But I can tell you about a few things you'll likely see in next week's post: First is that I've got multi-page/paginated form support just about ready to release in FormBuilder. What this means is that you can take forms (especially long forms) and break them up into multiple paginations. This makes for multi-part forms that are more digestible and easy to use for users. The end of each pagination has "Next" and "Prev" buttons for navigation between them. FormBuilder validates each pagination independently as it is submitted so that any errors are taken care of as the user proceeds rather than all at the end. And these are true paginated forms, rather than a JS manipulation of existing forms. More on this next week. I'm also working here on a new Inputfield module called InputfieldToggle. It's an alternative to the core InputfieldCheckbox and the intention here is to make it a selectable alternative for FieldtypeCheckbox fields. Unlike InputfieldCheckbox, it is presented as two radio buttons for "on" and "off" states. (It's also possible to have a "no selection" state distinct from the "no" state, where supported). It comes predefined with several toggle types (Yes/No, On/Off, True/False, Enabled/Disabled), along with the ability to specify your own (multi-language too of course). Like a checkbox, because it is a toggle, it holds a value of either true (1) or false (0). There is also null for no selection. While this is a relatively simple Inputfield, it answers a common need (at least in my experience) and often can provide a better experience than a standard checkbox, depending on the input need. Not to mention, it's a lot more efficient than using an Options or Page field to accomplish the same thing. In addition to sites and apps running in ProcessWire, I think this particular Inputfield has a lot of potential use in the core and its administrative forms, so I might include it in the core, though not yet certain. I'm already using it quite a bit in forms I'm developing for clients in FormBuilder, where in many cases I find it a better fit than InputfieldCheckbox. Lastly, there are some nice UI enhancements just about ready for manipulating column widths of fields in ProcessWire. It makes it a much simpler and quicker job than it currently is, so I'll have more on that next week too. Have a great weekend!

@iipa Pasting stuff from Word should be no problem ... I think most of our clients likely do this. So you definitely shouldn't get an internal server error from PW at least. Though you might try setting $config->debug=true; in your /site/config.php file (temporarily) and trying again, just in case — that will make it produce a verbose error message. But it's more likely that it is coming from mod_security or some other Apache or PHP module on the server that is monitoring input and halting the request when it comes across something it doesn't like. I don't blame it, as MS word can produce some pretty sketchy looking markup. But between CKEditor and htmlpurifier, PW should be able to clean it up just fine once the server lets it through. But if it's an Apache/PHP module doing this (which seems likely) then nothing you adjust in PW can fix it since the module examines the request before PW even boots, so you'd instead have to disable or configure the Apache module (mod_security, suhosin, or whatever it might be).

ProcessWire added WebP image support this year and many have been adopting it enthusiastically in existing projects. In this post we’ll look at a process used for migrating an existing website to use WebP images. We’ll cover everything from preliminary considerations to implementation and testing, with lots of tips and tricks along the way— https://processwire.com/blog/posts/webp-images-on-an-existing-site/

Just a quick update this week. I’ve got a good post in the works that I thought I’d have ready for today, but didn’t have quite enough time to finish it, so going to save it for next week. Though there's a module that's part of the post, and since it is ready, I've posted it below. We’ll look at ProcessWire 3.0.138 next week as well. I do have a couple of non-core updates to mention this week though. First is that I’ve released a new Textformatter module that converts any image references in your CKEditor/textarea fields to WEBP images on-the-fly as pages are rendered. If you are implementing WEBP on your site, you’ll find that the images placed in rich text fields are the most tricky ones to serve as WEBP, so this module takes care of that task for you. It's in the modules directory or at GitHub: https://github.com/ryancramerdesign/TextformatterWebpImages I’ve also released new development versions of the ListerPro and Export CSV modules, both of which are available to subscribers in the ListerPro support board. Some of the new features are actually built into the core, but currently only utilized by ListerPro. There’s quite a bit of new stuff, so there’s also an ~18 minute screencast that walks you through them, which can also be found in the ListerPro board.

I'm running into this issue on my localhost (MAMP) where it reports PHP’s standard "Fatal Error: Maximum execution time of 120 seconds exceeded" before even 1 second occurs. It does this regularly, but not all the time. But if I'm clicking around pages, I'll see often (maybe 1 out of 7 requests), and it halts the request. The file reference is always somewhere in either ImageSizerEngineIMagick or ImageSizerEngine, though a common place is on the line that instantiates the IMagick instance in the processResize() method: // start image magick $this->im = new \IMagick(); I looked into the ImageSizerEngine::setTimeLimit() method in detail, but there's no problem I can spot in there. I have no idea what the issue could be, but just replying here since @Mikie also ran into it, so it seems to be reproducible. Though it's a weird anomaly that we should never see unless 120 seconds actually passed (but they didn't, not even close). I haven't observed it occurring on any live servers yet, just my localhost environment on PHP 7.2.10. I'm guessing the issue might be PHP version specific or IMagick version specific since it appears to be PHP outputting an error with false information. Posting here in case anyone else has insight on what it might be.

Core version 3.0.137 on the dev branch adds the ability to hook multiple methods at once, in a single call. This post details how it works and provides a useful example of how you might put it to use in your development environment. This version also refactors and improves upon several core classes— https://processwire.com/blog/posts/pw-3.0.137/

ProcessWire 3.0.136 upgrades the version of CKEditor from 4.10.1 to 4.12.1. While that might look like a minor version bump, it’s actually 5 versions ahead and includes quite a lot of new features, changes and fixes. See the CKEditor release notes for more details on all that's been added and changed in the last 5 versions. It was a year or two ago where it seemed like CKEditor was going to be phasing out CKE 4 in favor of CKE 5. But interestingly it now seems like there is a new focus in CKE 4 from the CKEditor folks, so I’m going to have to start watching the version updates more often. Of course, I remain interested in CKE 5 too, but it’s nice to see CKE 4 (my favorite editor for a long time) going so strong and getting new features and attention, which is also a nice benefit for all of us PW users. I’m looking forward to working with some of the new stuff they’ve added in recent versions as well. For instance, the autocomplete feature sounds like it has nice potential for inserting Hanna codes or links to other PW pages, among other things. Also new in 3.0.136 is a new Debug::backtrace() static method in the core. I often use PHP’s debug_backtrace() method when debugging (and it appears in PW’s fatal exceptions), but the reality is it gives me a lot of stuff I just don’t want… all the hook method calls and such that aren’t usually relevant to what I’m trying to find. So the new built in Debug::backtrace() method returns a much simpler array than PHP does, and it also excludes all of the [likely] irrelevant internal hook method calls, and is just generally more focused on what you are likely to need from a backtrace in ProcessWire. It’s very convenient to plug into a ProcessWire $wire->message(Debug::backtrace()), or a Tracy Debugger bd(Debug::backtrace()); or even an echo '<pre>' . print_r(Debug::backtrace(), true); call. Though please consider this new method a work in progress, as it’s just a start at the moment and is likely to get additional updates. At some point, PW’s fatal exceptions will likely use the output from this method as well. Since this is kind of a short post, I’m just posting in the forums rather than creating a new blog post. More core updates on the way next week. Hope you all have a great weekend!

This week I was catching up with client work after traveling last week, but some of that work overlapped with a focus on WireMail modules. As a result, this week I’ve released two new WireMail modules, and also have information in this blog post on how you can configure two existing WireMail modules (WireMailSmtp and WireMailPHPMailer) to use Gmail as the SMTP sender— https://processwire.com/blog/posts/wiremail-modules-and-gmail/

I've been in Minnesota all week for a family reunion and only a few minutes at the computer every day, so I don't have a core update or anything worthwhile to write about this week. But now I'm headed back home so will be back to a regular schedule next week. Hope that you have a great weekend!

Version 3.0.135 of ProcessWire on the dev branch focuses on adding additional layers of security via .htaccess updates, adds clarity to debug mode, and improves upon the installer— https://processwire.com/blog/posts/pw-3.0.135/

I've been working remotely this week and haven't had a good place to sit or very particularly reliable internet, so I've put my attention towards things that I could make progress with in small and inconsistent chunks of time. As a result, it worked well to focus on resolving issue reports this week. In addition to updates mentioned last week, 3.0.134 resolves 18+ issues and contains roughly 25 commits relative to 3.0.133. Since most of the commits since last week are focused on resolving issue reports, I don't have much to write here beyond what's in the commit log, but do want to thank everyone for their reports and hope that you have a great weekend!

This week I've been working on core 3.0.134 but am going to keep the version number at 3.0.133 for another week while I continue with updates there. Commit log. One of the updates already present that I'm finding quite useful is a nice upgrade to InputfieldSelector (like used by Lister and ListerPro) which simplifies the field selection process as there are no longer separate "Field" and "Field…" selections for fields that have subfields, and they are now bundled into one. This reduces the number of selectable fields and likewise speeds up the selecting/filtering process. I'll have more details on that next week, along with other updates. I'm going to be working remotely next week (not vacation) and do not yet know what the internet situation is going to be yet, so on the chance that I don't have good internet access, I may not have an update next week, but hopefully will. Have a great weekend!

ProcessWire 3.0.133 adds a useful new $page->meta() method for a new type of page-specific persistent data storage, adds the ability for users to create their own bookmarks in Lister, and has a handy and time saving update for the asmSelect input type. Read on for all the details, examples and screenshots— https://processwire.com/blog/posts/pw-3.0.133/

This week we’ll take a look at 3 different WEBP image strategies that you can use in ProcessWire 3.0.132+. Then we’ll dive into a major update for the Google Client API module, and finish up by outlining some useful new updates in FormBuilder— https://processwire.com/blog/posts/webp-images-and-more/

This week I’m happy to report we now have WEBP support in ProcessWire thanks to a GitHub pull request from Horst Nogajski. This enables you to have highly optimized image output in PW and I think you’ll really like the difference it makes. Read on for all the details… https://processwire.com/blog/posts/webp-images-in-pw/