Getting closer to the ProcessWire 3.x stable release, version 3.0.14 focuses largely on updates and optimizations specific to recent GitHub issue reports. We also have optimizations and in-depth coverage of PW's file compiler, some new options for required fields, along with a review of some best practices when working with fields. More
This week's version of ProcessWire adds several new panels that provide simpler and more direct access to the page tree, page view and debug tools. New page view options also include multi-language selection and configuration support. And if that's not enough, we've also got install-time utf8mb4 support and more!
First, here are panels in the default admin theme. This demonstrates the page list "quick tree", the debug panel, and new page view options.
Next we've got panels in the Reno admin theme. This demonstrates basically the same thing, but also shows how the new page view options work when in a multi-language environment.
New “quick tree” page list panel
For awhile some of us have been wanting a page tree that we could get to from anywhere in the admin, without leaving the current page. Specifically, a page tree in the sidebar. But I personally didn't want a sidebar taking up my screen real estate, nor did I want the overhead of rendering a page tree on every request. So the drawbacks always seemed to outweigh the benefits.
This week we added such a page tree that's always available on any admin page, it doesn't take up any screen real estate when not "open", and it doesn't consume any rendering overhead unless opened.
To use it in the default admin theme, click the new site-map icon at the beginning of the breadcrumb trail. The page tree will open in a left-side panel.
To use it in the Reno admin theme, click the new site-map icon that appears in the masthead. The page tree will open in a right-side panel (though we may switch it to left-side if folks prefer it).
New page view options
The "View" link that you see in the page editor has always been very simple, letting you just view the current page, in the current window, in the current language. More recently we added a $config->pageEdit['viewNew'] option that let you specify you wanted the View link to always open in a new window/tab, but that option was too easy to miss, and still relatively limited in utility. This week we added a new dropdown menu to the existing "View" link that greatly expands the options available:
- View in panel
- View in modal popup
- View in new window/tab
- Exit and view (default)
In addition, the default behavior of the existing View link is now configurable in the ProcessPageEdit module settings. So if you want the existing View link to always open the page in a new panel, modal window, or new window/tab, you can now configure it to do so.
Multi-language view options too
If you have multi-language support installed, you also optionally can choose what language you want to view the page in:
New debug tools panel
Shortly after pushing the panel updates to the devns branch, LostKobrakai replied that it might be nice to have the debug tools in a panel as well. So you'll see that update in place too.
We've also added another shortcut to the debug tools, so that you don't have to scroll all the way to the bottom of the page if you don't want to. When debug mode is enabled in the default admin theme, you'll see the debug action/icon lead the breadcrumb trail. In the Reno admin theme, the debug action/icon appears in the masthead instead. Click the debug action/icon, and the debug tools load in a panel.
Support for utf8mb4 and InnoDB
The ProcessWire 3.x installer now gives you specific options for selecting the utf8mb4 charset (as an alternative to utf8), and InnoDB engine (as an alternative to MyISAM).
While we've technically supported InnoDB for quite awhile (and the core has always used it for some tables) the option was very much hidden. Now the database charset and engine options are much more obvious at install time.
Below we'll cover some of the considerations and benefits with regard to these options.
The only reason ProcessWire doesn't default to InnoDB is because PW makes significant use of fulltext indexes, and InnoDB didn't support them until MySQL 5.6.4. Most of the web servers I come across don't actively support it yet. However, if your web server does support it, you might consider using it on a future ProcessWire installation. Just make sure that both your development and production environments support it before choosing the option.
While there are many benefits to InnoDB relative to MyISAM, it is admittedly rare in the ProcessWire world that we experience the relative drawbacks of MyISAM. But you'll likely notice real benefits from using InnoDB if working with a high traffic site that needs to perform a lot of saving of pages (whether automated, or from a team of people making edits at once). You might also see significant benefits on sites that need to do regular automated imports of data that update a lot of pages. Why? InnoDB doesn't need to lock the entire table in the way MyISAM does to perform such operations, so there's real potential for improved performance in these installations. For this reason, ProcessWire has always used InnoDB on certain tables (like those for user sessions). But now you can specify that ProcessWire should use InnoDB for all tables.
Be careful with the InnoDB selection because it could be a real problem if your development server is running MySQL 5.6.4 or newer, while your production server isn't. In such a case, the production server wouldn't be able to import the development server database. Also note that not a lot of exclusively InnoDB ProcessWire installations are out there at present, but that is likely to change in the future now that the option is more obvious.
To use this charset, you'll need MySQL 5.5.3 or newer. When in use, it enables ProcessWire to store 4-byte characters rather than just 3-byte characters as in utf8.
Why would you need utf8mb4 relative to utf8? Most probably don't, but there's been demand for it specific to some languages as utf8mb4 greatly expands the number of characters that can be represented. Outside of language needs, it's what would enable you to use emoji in ProcessWire, for instance.
Because utf8mb4 uses more bytes per character, it places new limits on the length of indexes used by ProcessWire. ProcessWire has several 255-character index lengths, and the maximum allowed by utf8mb4 are 250 (250x4=1000). For this reason, we've updated all of our core Fieldtypes to use no more than 250 length indexes in order to support utf8mb4. However, it's possible that 3rd party modules might be using index lengths that aren't compatible with utf8mb4, so this is something to keep in mind.
Like with the InnoDB selection, before using this option, you'll need to make sure that your MySQL versions are new enough between your development and production servers. Though since the requirements are for MySQL 5.5.3 or newer, chances are most will be okay here. However, because not many are currently using utf8mb4 support in ProcessWire, you should still consider it experimental until PW3 is the current stable release.