We started the Grav 1.7.0 Beta Program way back in June of this year, and we have now released 9 more betas along with accompanying Admin plugin releases. Today, I'm excited to announce we have achieved the Release Candidate stage with the release of Grav 1.7.0-rc.1, Admin Plugin 1.10.0-rc.1, and Flex Objects 1.0.0-rc.1.

What started off as a Trilby client-funded set of functionality, has morphed into a full-blown release with a bunch of features and functionality that is edging us steadily closer to our Grav 2.0 goals.

A quick summary of the new features and improvements available in Grav 1.7:

Pages

• All new, experimental Flex-Pages support (discussed in more detail below)

Multi-language Support

• New per-language fallback options
• Various improvements to language logic

Themes

• Added a new built-in {% cache %} Twig tag to cache chunks of twig templates for increased performance
• Added some new Twig functions array_diff(), template_from_string()

General

• Updated Symfony components to 4.3
• Various core code cleanup to fix many phpstan errors
• New built-in Symfony-based web-server: bin/grav server for easier local development
• Improvements to Scheduler functionality
• New optional Clockwork PHP Debugger that runs in your browser's dev tools
• Return of Twig profiling support in Clockwork debugger
• Ability to hide sensitive variables in the debugger
• New function to sanitize SVG images
• Twig 2.x compatibility to ease migration in Grav 2.0
• Improved the capabilities of the bin/grav yamllinter CLI command to find issues easier
• YAML linter now supports multi-languages

Admin Plugin

• Many performance improvements so the admin is now faster than ever!
• New Ajax-powered and column-based page parent/move form field that is easier to navigate and works better with larger sites
• Basic user management for Flex Users (experimental)
• Much improved multi-language support for pages
• New onAdminMenu() event to provide better support for custom navigation
• New onAdminLogFiles() event to easily add custom log files
• Ability to configure the display of 3rd party widgets on the dashboard
• Improved button color and placement for pages and modals
• Modals dialogs are now stackable
• Better support for array field inside list field
• Ability to auto-sanitize SVGs for page media and file fields

Flex Pages

By far, the main feature of Grav 1.7 is the initial availability of Flex Pages. Flex Pages is basically a full implementation of the existing Pages functionality built on top of our new Flex Objects architecture. We released an experimental version of Flex Users that was able to replace standard Users in Grav to provide more power and flexibility. That initial experimental release was a starting point, and we have continued to improve and bug-fix Flex Users in this release, but we have also put a huge amount of effort into developing the new Flex Pages support.

A Quick History

When we first created Grav, each major object type stood alone. For example Pages are at the very heart of Grav and are the most complex part of the system as they have to contend with the majority of logic that is required to build and configure flexible web sites. But there are other key objects in Grav, such as Users, Configuration, Plugins, Themes, and many more. The problem we started facing is how to easily extend these core classes to add functionality when needed. Also there was not an easy way to render these objects differently in the admin. We had built some standard UI for the admin plugin, but we really needed a better way to bundle logic code, yaml configuration, and twig templating for presentation in such a way that was highly configurable, backwards compatible, with high-performance, all without being overly complicated. Not a simple task!

An initial prototype was developed and released in 2017 as Flex-Directory. It was a first attempt to provide a way to create custom objects with YAML blueprints, and also provide a CRUD (Create/Remove/Update/Delete) admin interface that fully supported the objects and any custom fields or modifications you made. This worked pretty well, but it did not address the need for custom code in objects, nor was it as flexible as it needed to be. The decision was made to create a new plugin called Flex Objects that did everything the old Flex-Directory did, but provided much more under the covers and has become the basis for our new Flex architecture.

Flex Pages

Fast-forward to 2019 and have been quietly working on Flex-Objects plugin for over a year and have been implementing custom flex-based solutions for various Trilby clients. These have mostly been for custom object types, but we steadily added functionality and features, but still don't have a full Grav Pages feature parity. Another Trilby client reached out to us regarding a performance cliff they had reached with the existing pages implementation due to the amount of content they had, and a better solution was required that would provide the performance headroom and capabilities they will need in the future. Flex-Objects sounded like the perfect solution for this problem, but there was a lot of work left to provide full support of things such as multi-language, page-events, and other advanced functionality.

This client agreed to sponsor the development of much of what is being released as Flex Pages. The initial focus was on the admin side of things as that is where the performance degradation was most noticeable. We built Flex Pages to use the existing Grav Page structure and features so it was as simple as an enabling a toggle in the Flex Objects plugin configuration to allow the admin to render the existing pages with the new Flex Objects architecture along with a new column-based page listing view. The page editing views were rebuilt to use Flex but remain visually consistent with the existing pages.

The listing view also contains a new context menu that contains useful information without requiring the user to visit the page details. The plan is to make this extensible so plugins can hook in and add new sections or tabs to provide quick-access to frequently needed data or actions.

Traditionally we recommended less than 1000 pages for Grav sites. That's not a hard limit, and does depend on plugins you use, and logic you may have in Twig etc. Some people have run Grav up to 10,000 pages with extensive caching and other performance optimizations. With Flex Pages we have tested Grav sites with over 50,000 pages! The admin was essentially non-functional with this amount of content in Grav 1.6, but in 1.7 and with Flex Pages it was totally usable.

Also, it's perfectly a legitimate option to use Flex Pages in the admin to get the UI and performance benefits there, but still use regular Grav Pages on the frontend to ensure 100% compatibility for end-users. This is possible because under the covers, both Flex Pages and current Grav Pages, work on the same data, the existing content stored in folders with markdown files. This is actually highly customizable, and you can now actually configure how content is stored (even in databases or via APIs if you required), but the default is and will remain the current folder/markdown file combination you are familiar with in Grav.

The Flex Objects plugin is required to provide the Flex Pages and Flex Users functionality in the admin. However, you can use Flex Pages and Flex Users on the front-end of your site with only the Grav 1.7 core (NOTE: User plugin is required for Flex Users)

The Future

With the release of Grav 1.7.0-rc.1, the admin side of Flex Pages is quite solid and highly optimized. We have been testing it with select clients for some time, and there has also been some solid testing performed by the Grav community. We have focused on the admin-side primarily, but we have also got the front-end (the side your users see) working and functional but it's not 100% optimized for performance yet. Right now, Flex Pages is definitely faster on the front-end for large amounts of content, but small amounts are better served with existing Grav Pages logic. We hope to improve this over the next couple of RC releases, and ideally exceed existing performance for all site sizes. There may also be some minor plugin compatibility issues with front-end Flex Pages, but they should be minimal, and very simple to address.

We plan on adding more features to the admin side however. First is the implementation of Filters and Search in the new Flex Page listing view. This is currently in development but was not ready for the RC.1 release.

Second, we have plans to add admin-level ACL control to Flex Pages via a new CRUDP (Create/Read/Update/Delete/Publish) permission system. This will allow you to control which specific users and groups have access to manage any specific page and their children, enabling the development of rich and complex content architectures. We hope to get in this feature into the 1.7.0 final release, but it might slip to a dot release (e.g. 1.7.1) if we can't complete it with the functionality we want in time.