ryan

This latest version on the dev branch includes a few additions, optimizations and fixes. I'm only in the office for a brief time today, so I'll plan to cover these in more detail hopefully in next week's blog post (along with next week's updates), but here's a preview. There's a lot of improvements to the "Overrides" tab that you see when editing a field (Setup > Fields > Edit). These are the field settings in the contexts of different templates. In 3.0.144, you now get a list of all field settings that you want to allow to be customized per-template. In previous versions, you only saw this option if you were in $config->advanced mode. It's still a YMMV setting, so appropriate disclaimers have been added to the field. But since it's been there for more than a year and there have not been any reports of issues (that I'm aware of yet), I thought it didn't need to be limited to advanced mode anymore. The table that shows you what overrides are in place is now improved as well. You can now click any override setting to open a modal window to see/edit them as needed (previously they were just non-clickable text labels). This is the same window that you get when clicking a field in the Template editor. Though unlike the Template editor, it takes you directly to the setting you clicked on and highlights it. After saving or closing the window, it updates the table for any changes you made. In addition to this, the overrides table now shows a Diff rather than separate Old and New values for modified settings, which better clarifies what was changed. (That Diff comes by way of a new method added in the WireTextTools class). Version 3.0.144 also adds a new Inputfields Javascript API. More methods are likely to be added to it, but you can see what's available in this first version in the comments for this file (inputfields.js). The purpose of this Inputfields JS API is to make it simpler to manipulate Inputfields from the JS side, as well as solve some needs that I've had in the core and modules; which presumably some other developers may have had as well. It takes a lot of stuff that previously required knowing which classes and attributes to manipulate and simplifies them to simpler methods calls from the new Inputfields JS API variable. It also abstracts away some admin-theme specific stuff so that you can use the same API to perform certain manipulations regardless of admin theme. I'm still working out some details and likely have some issues to fix and additional functions to add, so I'll save examples and more description for next week. Though the updates mentioned for the "Overrides" tab do use a little bit from this API. This version also contains a couple of fixes per GitHub issue reports, and that'll continue into next week's version as well. More updates next week. Until then, thanks for reading and have a great weekend!

This version on the dev branch contains 26 commits (relative to 3.0.142) and is focused primarily in resolving reported issues, and we managed to cover 18 of them in this version. Thanks for the reports and help in our GitHub issues repo. This version represents about 2 weeks of work, and ProcessWire Weekly #284 has good coverage of those that occurred last week. More details about this week's updates can be also be found in the dev branch commit log. There are also some other minor additions and improvements in 3.0.143 as well. My favorite are the improvements to our logs system. It now collapses identical log entries that occur near each other. That means a single recurring log entry (like an error message) won't repeat indefinitely in the log and take up a lot of space. Now it just adds a counter to one log entry and updates the timestamp, rather than duplicating the entire log entry... Much more efficient. When you view a log in Setup > Logs, it identifies these collapsed log entries for you. In addition, the output in the "errors" and "exceptions" logs now have improved readability, isolating error messages and filenames from stack traces. Lastly, the ajax navigation in Setup > Logs now shows logs in newest-to-oldest (modification date) rather than alphabetical, which I find a lot more useful. The log at the top of the list is always the one most recently updated. For core updates in coming weeks, I'm primarily focused on preparing the current dev branch to merge to the master branch, as it's been awhile since the last merge and the master branch is itching for a new version. Most of you reading this already run on the dev branch, but there are many out there that also stick to the master branch, and with all the new stuff on the dev branch, I'd like to get our master up-to-date with this as well. Thanks for reading, have a great weekend!

@Klenkes @eelkenet @Jens Martsch - dotnetic Thanks, I was able to duplicate and fix the issues mentioned above. Please let me know if you observe any other issues.

@Jens Martsch - dotnetic Heh, no problem, that happens here regularly too. :) Let's get back to your first video—I'm trying to figure out how to duplicate this one. I think you could be on to something here because many Fieldtype methods require a Page object, and there is no Page object associated with each image. As a result, we use a fake Page without an ID, and I'm guessing this is the source of the error you are seeing, but I can't figure out how to duplicate the scenario here. Here's what I've done to attempt to duplicate: I've started with a new instance of the "Regular" site profile, added a field-images template, and added fields to it. Logged in as superuser, I edited the /about/ page, uploaded an image to the image fields, and populated all my custom fields with text, and saved. I created a new role named "editor" and checked the box so that it has page-edit permission to "home" (which inherits through the tree). The user doesn't have any other permissions. I created a new user with this role, logged in with it, and edited the /about/ page and clicked to open the images field. I can see all the field text, and modify and save it as well, and changes are retained. So I'm not sure what to try next in terms of duplicating the issue, so I'll ask a few questions; Do you have any field-level access control involved here on your images field, or on any of the fields defined on your field-images template? Did you enable access control on your field-images template? (it should be disabled) Do you have any modules installed that add access control hooks or modify the way access control works? Do you have any optional core permissions installed? (like page-edit-created, page-publish, page-edit-images)? Any other factors you can think of? Thanks!

@Jens Martsch - dotnetic Thanks for the videos. Let's focus on your 2nd example first, because I see things in first one that I don't recognize, and it looks like there is access control at the field level too, so lots of factors—let's come back to that one. In your 2nd example (blank installation) you haven't yet uploaded an image into the field, so it doesn't look to me like it should be showing any fields yet. But you are circling something with your mouse, so I'm not sure I understand. But you shouldn't see any of your custom fields if you haven't yet uploaded any files/images yet, so can you try that example again or let me know if I misunderstood? (no need to record it to a video, just wanted to make sure I wasn't missing something).

ProcessWire 3.0.142 has a lot of updates but the biggest is the addition of custom fields support for file and image fields. In this post, we take a closer look and also outline all of the new features in the just-released FormBuilder v40— https://processwire.com/blog/posts/pw-3.0.142/

Last week I worked primarily on GitHub issues, and did some of that this week as well. Likely I'll be doing a lot of this in October. Thank you for all of your reports. While there's already a lot of commits on the dev branch, I'm going to wait till next week to bump the version, as I've got some stuff in progress that I want to get committed first (more on that below). Next week I'm releasing version 40 of FormBuilder that supports paginated forms, as well as forms within forms (not to mention some other minor additions). Basically, all the stuff that was covered in this video from a few weeks ago, plus a little more. I actually think it's ready right now, but as is often the case, I started writing instructions for using the new features today and thought of a couple minor tweaks that would be helpful along the way. So I'm going to apply those early next week, finish the instructions, test it all out again, and then release it... likely mid-week next week. For the ProcessWire core, one feature people have been asking for for quite awhile is the ability to specify custom fields with file and image fields. I've been working on that here quite a bit this week, and have the initial test cases working quite nicely! Unlike the Description and Tags fields that come as built-in options with file and image fields, the new option instead uses a subset of ProcessWire's Fieldtype and Inputfield modules to support this (note: it does not use pages like repeaters do). This gives you more flexibility in defining what you want and how you want it to look. Though there are some limitations of what kinds of fields you can use here, but I think you will like what it offers and how it works. For those that just need a description and/or tags, then of course those features will remain as they are. But for those that need something more for file/image fields, you are going to have a whole lot of new options in 3.0.142. Unless I run into any roadblocks in finishing development of this part, I'll have it ready by this time next week along with a blog post that outlines it in more detail.

Actually I'm still working on minor details, but I'll have it posted by 5pm EST.

This week’s dev branch version brings you improvements to ProcessWire’s $input->cookie API variable, plus it adds the ability to modify system URLs and paths at runtime. This post also includes some examples to demonstrate just how useful this can be— https://processwire.com/blog/posts/pw-3.0.141/

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/