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!
Some of the new things added this week are supported by the new ProcessWire panels introduced in 3.0.15. To support them we created a little Javascript panels library. To get things started, I think it's best to demonstrate what they look like, and then we'll get into the details.
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.
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).
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:
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.
If you have multi-language support installed, you also optionally can choose what language you want to view the page in:
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.
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.
Hope that you all have a great weekend and hope to see you at the ProcessWire Weekly. Big congrats and thanks to Teppo who last week published the 100th issue!
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 we have the beginnings of the ProcessWire 3.x API documentation ready and published. This post goes more in depth about how it's powered and what's left to do. More
“We were really happy to build our new portfolio website on ProcessWire! We wanted something that gave us plenty of control on the back-end, without any bloat on the front end - just a nice, easy to access API for all our content that left us free to design and build however we liked.” —Castus, web design agency in Sheffield, UK
Tom
- 9 years ago
- 150
★★★★★AMAZING!!! Great Update Ryan!
Reply
Ryan
David, thanks glad you like it. Regarding ProDrafts it actually has exactly that feature already (side-by-side panel live preview). In fact, it's what I use when writing these posts. :)
Reply
Adrian
This panels are great, something that for sure it will be really appreciated by most !
Thank you for this hard work you are doing week after week !
Reply
Stefan
Seems like config dom.w3c_touch_events.enabled in Firefox was once 1 per default and they changed it to 0 because some sites had problems. Somehow my browser still had it at value 1.
The quick-tree isn't inserted to the breadcrumb (default theme) or top navigation (reno) when on a touch device.
Reply
Zahari M
- 9 years ago
- 30
★★★★★Simply awesome stuff Ryan!
I'm glad you support both admin themes. They are both different. One looks nicer but the other one's somehow more efficient to work with, at least for me ;)
Reply
David Karich
- 9 years ago
- 20
★★★★★Thank you Ryan. The panel is very useful. Very cool would be an extension as ProDrafts. A live preview next to each other.
Reply
Stefan
I've updated from 3.0.14 to 3.0.15 but I can't see the sitemap icon in front of the breadcrumbs.
Reply
Jason
I didn't know about this: $config->pageEdit['viewNew']
Does it work in 2.7? Where is it documented? Will it work with the view link in the page tree as well?
All view links in the admin should default to opening in a new window, IMO.
Thanks!
Jason
Reply
Stefan
No I get it! Quick-tree is only available in Google Chrome. I'm using Firefox.
Well, that's bad. :-(
Reply