Roadmap for Grav 2

[rhukster]

We thought that perhaps a GitHub issue would be the best place to solicit the communities ideas and thoughts for features and improvements for the next major release of Grav.

We have some preliminary ideas that I'll outline here, and i'll keep this list updated as we get feedback and ideas from you guys.

1. Collections and Objects

   This is a new system for handling collections and objects that will allow us to perform advanced collection handling as well as complex queries of collections and objects. We intend this to be available in Grav 2 as the go-forward approach, while still keeping the current collection/object system for backwards-compatibility.

2. Caching (PSR-16)

   We are going to rework the caching system using the new PSR-16 approach to provide a more unified and yet more flexible caching system. This will allow us to use our existing caching system, or even mix multiple systems with differing levels of caching as needed.

3. Plugins & Events

   Improvements to the plugins and their events to ensure plugins are only loaded when called.

4. Pages

   We plan on revamping the Page object to refactor and simplify it to improve performance. We also plan on creating a base class that can be used to develop new and specific page types.

5. Content Blocks

   A new mechanism for creating nested HTML blocks with varying levels of caching in different parts of the page. This will allow sophisticated page caching by having items that need to be refreshed more often have a shorter life cache, than those that rarely change.

6. Widgets

   A new simple system to allow reusable logic, rendering, and configuration. This is more akin to a WordPress widget or a Joomla module. These can be rendered at runtime or dynamically via Ajax.

7. Flex Integration

   Integration of some base classes, similar to the FlexDirectory plugin, that allow the easy creation of new plugins with complex CRUD (Create / Remove / Update / Delete) functionality to be used with the Admin plugin.

8. Large Site Support

   Grav is really great at small and medium sized sites, but for large sites with many thousands of pages, it's a case of diminishing returns. We want to utilize some of the collection, caching, and page improvements to provide mechanisms for Grav to handle these larger sites.

9. PHP 8.0 Requirement (UPDATED)

   Grav 2 will require PHP 8.0 (or later) to ensure maximum performance, security, and stability.

NOTE: We are striving to ensure Grav 2 will be 100% compatible with Grav 1.x. If there is anything that is just not going to be compatible, we will come up with a mechanism for migration, or an interim compatibility plugin/configuration option etc.

While we want to keep the list of features and functionality focused to ensure that this release is realized in a timely fashion, we would love to hear your thoughts about the current plans. Also if you have any specific features that you would love to see in Grav 2, please leave a comment below so we can track it.

Thanks!

[jgonyea]

How will backwards compatibility of Grav 1plugins/ themes be handled in Grav 2? Wordpress tries pretty hard to be backwards compatible across major versions, while Drupal typically requires a rewrite of a plugin.

I can see benefits to both approaches.

[ricardo118]

I would possibly also attempt to add some more functionality to themes. Currently some functions do not work in themes that work in plugins. It would be nice to have this.

Moreover maybe having Admin be less of a plugin and more of a part of the system (ie loaded before plugins and then able to be customised via themes or plugins)

[apfrod]

For me the power of grav is the admin blueprints - I'd love to see more focus on reusable and composable blueprints that have stronger bindings to the templates. Maybe even directly derived from template variables.

[MujibAzizi]

Happy to see this!

Something I would like to see added is the support to manage plugins (and its dependencies) directly via composer.

Internally we currently have a small set-up which already sets Grav as a dependency and downloads our custom plugins and its dependencies correctly. However, with the current set-up of Grav and our set-up you're not able to download specific versions of plugins provided by the Grav Repository.

We are working on a Grav Packagist experiment which kind of looks like https://github.com/outlandishideas/wpackagist. But native support (starting 2.0) would be even better.

Related to #1200 and #32

[mahagr]

@jgonyea My idea is to have compatibility mode which can be turned on and off -- mostly to allow developers to test their code with strict 2.0 mode. I want all 1.x code to work on upgraded site, but at the same time, I would like to prevent feature creep -- we need to be able to remove old functionality later on.

@ricardo118 Please give some examples of things you would like to see to work.

@apfrod Many of the planned items from above are to improve how admin deals with the content.

@MujibAzizi This is something I've been looking into, too. I want a more centralized way to handle vendor libraries, though composer is quite slow to run (times out) from the web interface and there are other issues, too.

[andrewscofield]

I think it'd be great to see a unified way for plugins/themes to handle ajax/json requests. Not sure if that is what the Flex Integration is since I'm talking about front end things mostly. I've done it myself a couple different ways and have seen other plugins do it in a few different ways.

For example, it would be great if you had a simple newsletter signup or search on a page. But it could also be used to power a React/Vue/Polymer/JS module or entire site if you wanted. Not that this can't be done now, but built in and unified functions and helping with security too would be awesome.

[mahagr]

Oops, clicked on the wrong button. CRUD (Flex Directory integration) is really not the same thing as AJAX, but it is kind of part of the whole picture. Most of the items listed in the first post are related to creating easier and unified interfaces to the content.

[w00fz]

What @apotropaic is describing really is some RESTful/GraphQL API which I agree is something we should also start considering as we approach the items in the list.

It's definitely under our radar though! Especially for allowing other languages/applications to integrate. It does need to be addressed more carefully because it will be a wide-spread and built-in integration touching several Grav's APIs. It will need to be consistent, secure and expandable.

[sphism]

That's funny, I just wrote up an idea that's been buzzing around my head for a while, it'll get lost in slack so I'll add it here.

---

Hey folks, I've not been around here in a while. Did anything happen about the advanced editor? I've been thinking for a while that Grav would be so sweet if there was a desktop app that ran the site for a client on their local machine, then synced their changes via git. It would be great UX and it's pretty straightforward since there's no database to worry about. I think it would be a killer feature that other CMS's would find hard to match... tablet and phone apps too.

[hexplor]

Holly molly looking so much for Large Site Support.
Besides would love further improvements into admin blueprints ie. more compact list fields collection. It became really cluttered when using nested arrays.

P.S. You guys are great.