We are getting very close to our next master version of ProcessWire 3.x. This week work continued on covering issue reports, but we also added a few items from our feature requests repository as well. This post contains a brief summary of what went into the core this week. More
ProcessWire 3.0.87 core updates
Happy New Year! For our final dev branch version of 2017, we've added a couple new features that I think you'll find useful. For starters, we've added drag-and-drop (and paste) image upload support to our richtext editor (CKEditor), which is really handy. We've got all the details and a short screencast here as well.
Drag-and-drop (and paste) image uploads in CKEditor
ProcessWire 3.0.87 upgrades the CKEditor version from 4.7.3 to 4.8.0. One of the nice things about CKEditor 4.8.0 is that it now comes standard with the image upload plugin. Given that, I thought it was a good time for us to add support for this feature to ProcessWire too. So that's what you'll see in this version, which I think is best demonstrated by a short video:
As you can see, you can either drag and drop an image into the editor, or you can copy and paste an image (or part of an image) into the editor. When you do that, we've setup CKEditor to trigger an event to an available ProcessWire images field in your editor. The images field receives the uploaded image, and then it loads into CKEditor. If your images field is configured to resize an image ahead of time (client side or server side) that will continue to work as well.
Now ProcessWire has always supported images in CKEditor, but you had to drag them into your images field, not your CKEditor field. So there were more steps, and the new process is a lot simpler and more intiuitive for those inserting images in CKEditor. The paste image feature is something ProcessWire has not had support for before. You can paste images directly into CKEditor now, but not directly into an images field. However, here's a useful tip: If you wanted to paste images into an images field, you would simply paste them into CKEditor, and they'd automatically be in your images field too (you could just delete the images in CKEditor if you didn't want them there).
By the way, you can also drag in multiple images at the same time and it works just as well! Worth noting is that this new image upload feature requires you actually have an images field present in your page editor, so that the image has somewhere to go. If you don't, then the upload is disabled. We're probably going to continue building out this feature a bit more, such as adding the ability for you to specify a different page where images should upload to. Once that's supported, it won't be necessary to have an images field on your page.
If you want control over what image field(s) this feature uploads to, you can configure that in your CKEditor settings (Setup > Fields > your-field > Input (tab) > CKEditor settings > Images fields that may be used for dragged in (or pasted in) images. Or if you want to complete disable the feature, you can do that from the same place. By default, the feature is enabled when images fields (that support more than one 1 image) are present on the page being edited.
As a side note, when using this new image upload feature in CKEditor, I also think it's useful to enable these two options in your CKEditor field settings (under Details tab > Markup/HTML > HTML Options):
- Fix broken images (remove img tags that would result in a 404, or re-create images when possible).
- Update image alt attributes (replace blank alt attributes with image description).
This ensures that when you delete or replace an image directly in your images field, or update the description, the changes should also reflect back to the image in your CKEditor field as well.
New field/template context settings
As many of you know, you can modify some settings for a field, within the context of a particular template. But lets review that again, just in case you aren't sure what I'm talking about. Let's say you've got a "title" field that you want to be labeled as "Boat Name" when used on your "boat" template (rather than "Title" everywhere else). When editing the template in the admin (first tab), you see a list of fields on that template. When you click one of them, like "title", it opens a modal where you can edit the field settings, within the context of that template. This is how you'd make the title field have the label "Boat Name", only when used with your "boat" template.
There are several other common field settings that can be configured per-template in the same way. But for the most part, custom field settings (that aren't common to all fields) are not configurable by context, unless the module author has specifically indicated fields for this purpose. (Module authors note: you can do this by providing a getConfigAllowContext method in your Fieldtype or Inputfield modules).
There have been requests on GitHub to support more field/template context settings, like this one from @Toutouwai. So we've added something to answer that request. However, because we think this might be more of an "advanced" feature, we've isolated it to PW's advanced mode, at least until it's had more broad use and testing. If you want to test it out, add
$config->advanced = true; to your /site/config.php file, and this will enable advanced mode.
Once advanced mode is enabled, you'll see a new tab labeled "Overrides" appear whenever you are editing a field (Setup > Fields > any-field). The contents of it will depend on what Fieldtype and Inputfield modules are used by the field. Here's what it looks like for a Files field:
As you can see in the screenshot above, these are the custom settings for a Files field. If you were editing a different type of field, then the settings here would be very different. Any checked settings become configurable on a per-template basis. The settings are prefixed with "Details" or "Input" to indicate what tab they appear on. (Details are specific to the Fieldtype, and Input is specific to the Inputfield, if it matters).
In most cases, it's probably safe to use this feature. But be careful, because most is not all. There will be cases where it might be problematic or it might not work at all. That's why we've isolated it to Advanced mode, because you are essentially overriding what is technically supported by the module. As a result, this is something you should probably work with only on development sites, or at least test changes on development sites before production sites. Advanced mode tweaks like this are kind of like rooting your phone to give you more control, so if a particular override does not work or causes problems, no need to submit an issue report, just assume that particular setting will not work as an override.
That's all for this week. Next week we'll be getting into our 2018 roadmap. I hope that you all have a Happy New Year! Stop by the ProcessWire Weekly for the latest PW news, modules, site of the week, and more. See you in 2018!