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.

[sphism]

Large site support

I'd be totally happy with having a database, or something, if it meant Grav could grow to millions of pages.

Is the size limit due to how grav indexes all the yaml data?

Also I'd be totally happy if Grav had 1 page for Blog, with a parameter for the blog id, then Vue (or similar) loaded in the content

[hexplor]

I think database direction is wrong anyways. What makes grav awesome is flat file thingy.

[sphism]

Absolutely, but if a limit of flat file is 1000 or so pages then I'd be happy with having to add [something else] to allow tens of millions of pages.

[something else] would just need to help indexing the content I presume, but i'm not sure what the limitation actually is.

Might be a database, or Redis, or some JSON document store, Elastic, or whatever

[MujibAzizi]

@mahagr So the main issue is using it from the web interface?

I remember Bolt.cm doing it via composer, via a web interface. https://docs.bolt.cm/3.4/extensions/introduction. They are writing a file to their extension directory.

I havent looked into the internals but I think this is to my opinion definitely something to look into.

[paulmassen]

Hi! Glad to see this discussion.
There is two things I would love to see in future versions of Grav or Grav admin.

Menu manager

As for now, most of us use the navigation.html.twig to manage their menus. However, it might be useful to have some page specific menus sometimes. Therefore, I would love to see a menu manager that would allow us to manage multiple menus instead of tweaking navigation.html.twig every time.

Template editor

Another thing I would love is to be able to edit twig files from the admin. I often have to do some small edits on live site, and I would love to be able to do that from the admin. I think OctoberCMS provide this feature, and it could be a great addition to grav too in my opinion.

[boettges]

I really appreciate the large site support, but please do not forget about the fact that larger sites with more content also require a role-based group management system for editors to make sure that certain editors can only edit the parts (site collections) they are allowed to edit.

I would love to see this feature advancing the group-pluging 👍

[tourtools]

I would like to see also:

• better multisite management
• wysiwyg editor integration

[coder4life]

Awesome @rhukster. Thanks for making this issue for feedback. I am going to break my followup responses into two parts. One feedback on ideas already posted. I know @mahagr and I have kicked around a few optimization ideas going forward.

1. Collections and Objects

Better base generic class support for collections and objects are a must. I agree with this effort and makes a lot if sense. When toying with a few plugin initiatives in private projects, I found I was requiring base set of functions to perform on collections. In this sense I was duplicating lower level manipulation code with very minor slight variances. There was a point I would of just put this code in a base library, but I would prefer Grav to have this code by default.

There is a point were manipulation of a collection becomes specialized. For example using the tree to node analogy when manipulating a nested set of nodes to another location within the current document or external referenced document. The complexity of the collection manipulation changes. Rather then duplicate code it would make sense to extend a more primative base class.

This is where extension of base collection classes make sense. 90% of the operation is simple to complex array manipulation. Collections are currently specific to hard coded sets (frontmatter, forms, config). Although good for most cases, there are cases where a more generalized data struct that is not front-matter for example would make sense. An API project I am working on is basically a YAML file with array structures however the data set is a specific type of collection. Also this may introduce a way to store in other formats like a database.

The summary out of this is we need the ability to template and define collection types after extension of base classes. Analogy to this is we need a solid foundation before we build the building with all the rooms.

2. Caching (PSR-15)

Makes sense, and might make it easier for people to adopt Grav from different platforms that might of had similar caching mechanisms. Since the base APIs will be the same this will allow for cleaner code and easier library/framework adoption for specialized platforms

3. Plugins & Events

I found plugins and events to be a bit chaotic at the moment. Hooks are great and always useful. Part of this is cleaning up the documentation for this. For Devtools kit could give recommendations of when an event is fired and what fired it (plugin, template, grav itself, ect.) Events in Grav are powerful, however their organization can be tightened up. Some events could be even merged or specialized (not many but from experience it was hard to track when was the proper time to run something with similar described events). Part of this is tightening up the lifecycle a bit.

4. Pages

Pages are essentially a type of collection. Fixing the collection problems will actually tighten up the issues where Grav is heavily expecting page collections at the moment. Generalizing collections will allow easier manipulating two different storage sources under one umbrella.

@mahagr and I brainstormed some ideas. He gave me a great explanation of some concepts that would simplify page usage in the current public 2.0 test branch. The goal here is to loosen the Grav and Pages relationship a bit. Pages are Gravs identity, but the default library expectations make it hard to adopt different collection types.

5. Content Blocks

Currently Grav renders a full page. Gantry actually solves content block rendering in Twig which allows more dynamic updates to sections of HTML. This is a great idea and could theoretically shave 50-200ms of loading based on the complexity of a page.

6. Widgets

This is not so much of an issue. Plugins fill the void for most my use-case. However it might still make sense to include this as a suggested way to specialize certain content types. Widgets is like a Twitter, Slack User List, or Facebook section. They are self contained parts of a page that relate to the contents of multiple designated Pages but are not specifically required to be on a one specific Page.

Widgets should be portable within Grav Page space for all Pages. Also widgets could adapt to context in Grav they are given. For example a Game developer who has a Developer Blog and a About the Game Blog. Widgets could adopt to the context given by configurations for a specific route.

7. Flex Integration

Programmatically most of us already do this. I do not see this as much of a need, but might be good to simplify the process for manipulation of data sets. It is not as of an important of an issue.

8. Large Site Support

This is definitely a must, also collection support will allow us to store in database formats.

9. PHP 7 Requirement

100% yes. PHP7 does a significant boost for performance, speed, and memory. Many libraries are adopting a PHP 7 future. Also 5.6 is technically going to be heading to its end stage. By the time Grav 2.0 rolls out PHP 5.6 will be under its last legs or officially obsolete.

[rhukster]

@coder4life i agree with pretty much everything you have commented about regarding our initial features list 👍

[ghost]

I’ve been building a lot of Grav sites lately, I love the flexibility and simplicity of the system. After doing a ton of content entry over the past few weeks, being able to edit parameters across groups of pages would be very useful. For example, assigning categories, tags, page templates, prefix enable, etc, or any common blueprint option you realize you forgot to put in after making 20 pages. It happens, and even a simple batch process tool would be handy.

Along the same lines, a way to batch generate yaml / meta files for existing images would be awesome. I’m doing lots of portfolios and galleries right now, and it’s time consuming and repetitive to add individual data files for large numbers of images.

Details like these can be huge time savers and make a big difference in user workflow, especially with larger sites or sites that grow large and change over time.

I love the direction Grav is going with the technical improvements, and the simplicity of workflow and overall operation is greatly appreciated. At the same time, it’s also good to think about how integrators and their clients may be using it. Simple & useful content tools can add a lot of value on the user side.

That’s all I can think of, Grav is pretty awesome. Keep up the good work 😊

[rhukster]

hey @cpfeifer i feel most of your 'bulk' tasks, and also things like setting options across lots of pages are related to an initial setup and configuration. As such there's already a super easy way :) Being flat-file based, you can simply view your entire site in your editor of choice (ST3, Atom, PHPStorm, etc) and simply construct search and replace (even with regex if its complex).

Another option might be if a 3rd party plugin was created to do a similar search and replace type functionality as an admin-compatible plugin, but really feel this is beyond the scope of the core or even plugin admin of Grav.

[ghost]

@rhukster Fair enough. Like I said, I love the simplicity of the core, and I think the balance between core features and plugins is just about perfect for what I need to do. I also understand what I do isn’t necessarily what everyone does.

Thanks for the suggestions, I really hadn’t thought about this much until recently and I’m still wrapping my head around the intricacies of the platform. I figured there was a way but I didn’t see much in the docs relating to this scenario. Maybe I’ll whip something up at some point.

[sphism]

Has anyone here used Concrete5? The front end editor is really nice, you drag n drop blocks into areas, then fill out a little form. One of the block types lets you make rows and columns, where you can place other blocks. It's a really nice editing experience.

[Sogl]

1. Please add file manager! Sometimes it's really faster to copy some folders with rename and header edit than do it through Admin step-by-step creation.

2. Please add an option to use one header configaration to all nested pages/folders. For example, if you want to create WordPress style post url 2017/12/24/my-post, you need to put the same md-file to each year/month/date subfolder.

[DamirPecnik]

Better article editing support like (Gutenberg for Wordpress) as an example would be great. When I deliver a site to End Users most of them are saying it's hard to edit the content of the article, if they want to add some sort of structure to the article like images and blocks of paragraphs. Basically better content editor!

[Heraes-git]

For a more "complete" argumentation against implementation of Gutenberg, here's one point of view :

• Gutenberg is a very cool, from a CMS point of view (easy for non-dev customers).
• But from a HTML generation side, it's a hell to maintain. Not mentioning that HTML generation can conflict with the markdown-twig native relationship in Grav (like TyneMCE do).
• Finally, in Grav there is already a possibility to reach this brick-style level of page creation, with help of the "widget" plugin, and the use of modular pages. Modular pages can be filled with images and displayed with gallery templates, or other type of content and corresponding templates, and widgets can help, based on a special HTML layout, to display sidebars. Of course, the move of the bricks is difficult given that templates are "rigids", and all of this rely on themes and plugins disponibility, but it can be considered as "already there".

In short : it is the matter of developers to offer good themes with good modular templates, and a good updating of the widget plugin, and layouts taking account of this plugin. Also, a maximum of flexibility (like defining the position and size of bricks) in the frontmatter should be a priority in every developer's mind.

That's a kind of message in a bottle, that I'm throwing here. 👍

[onetrev]

Very good points @Romarain and I'm sorry @rhukster I totally regret even mentioning Gutenberg and freaking people out. I totally agree now it's not a good idea for core at all. The "Widget" plugin mentioned my @Romarain actually takes care of lot of modular functionality I think Grav needs.

However, what I think would really be even more effective and enable developers to make good modular themes would be the inclusion of Conditional Fields functionality. Perhaps, that's more appropriate for a goal for Grav 2, or sooner :) ....

[Heraes-git]

@onetrev I've just finished (yesterday) a JS script to allow that ! I wonder if I will propose it for implementation in the project.

[peachp]

just please please please still keep the simplicity in mind! I fell in love with Grav mainly because of how simple / transparent it is. It's great to have all these improvements, especially when it is indeed improving things which already exist (caching for example).

It's probably to late, but I believe things like Widgets, Content blocks etc. are taking Grav in the direction of "jack of all trades, master of none", like WordPress. I think a lot can be already achieved with Page, Modules (modular pages) and partial templates, and that no matter how hard you try, you will not be able to give some "power users" enough tools to properly design a website using a GUI. It will be either too limited, too complex, too slow, produce dirty HTML or negatively impact SEO (or several of these things).

...I mean if you do achieve a good balance between all those things, it would be great. But please be careful not to make it too easy to create such monsters in Grav, like I currently have with WordPress + Avada (Visual Composer) + Shortcode plugins + PHP snippets, because I was too lazy to learn how to build a WordPress theme (I'm glad I didn't, because this made me find Grav).

WordPress = Swiss knife -> can do many things, but none of them really good
Grav = Katana -> you need to learn how to wield it and maybe make your own holster, but then it becomes a solid simple tool to do the job

[bleutzinn]

I agree completely with @peachp
Developers being creative people, not giving in to the temptations of creating yet another piece of functionality may be the hardest thing to do while still maintaining and only improving what already exists.

[rhukster]

We always will keep the core Grav tenants in mind.. Speed, Simplicity, and Flexibility. These are what make Grav, Grav...

[drzraf]

I'd like to mention three aspects where Grav could gain simplicity and features:

1. packages. Use composer (& composer-plugin if really necessary) then drop the thousands of lines of custom code, dozens of bugs and bring-in lot of feature currently lacking.
2. blueprints. The rocket-theme code related to this is really hard to grab. I'm pretty sure the couple of YAML import/load/order functions it provides may be better implemented another (cleaner) way. Yaml functions? Yaml anchors? Extending core parser?
3. forms. It's a very useful component which definitively has some good points (the Twig part for example). But I'm sorry to say it's often not on par with my expectations : Caching, but also forms fields referencing, loading, import, override (and their relation to blueprint's). Many may also want to see a blueprint-generator (aka form builder). Like for composer, better (standard?) alternative implementations YAML-forms may exist that could be considered?

[jrivero]

Grav 2 is abandoned?

[rhukster]

Of course not. We just moved some things that were going to be in 2.x into 1.x.

[CyberSinh]

Hi @rhukster. Do you have any release date to share for the version 2.0? Thanks.

[mahagr]

Grav 1.7 already has many of the changes discussed in this issue, at least in some form, but with backwards compatibility, which will be removed in 2.0. I see 2.0 just as a change to remove old behaviour which we do not want to keep on supporting anymore. Likely it will have more than that, but we do not need 2.0 to implement new functionality.

[sherpadawan]

One suggestion :

• I think It would be nice to save pages' images in a separate data/pages/images/01.mypage subtree directory. It would avoid to add a gitignore rule, and make dev<->prod sync easier. As it is in Drupal, and Wordpress.

[sherpadawan]

Another:
Vue.js integration or any other relevant framework integration (a least a small documentation reciepe).
When one use JS framework one need to access GRAV CMS, page, plugins configurations which should also be filtered for security reason...

[xinity]

any public roadmap available for grav 2.0?

[mahagr]

Most of the features listed above have already been implemented, but we decided to do smaller releases (1.6, 1.7) instead of going directly to 2.0. I have already started playing with 1.8 by updating all the libraries and looking at what fails. It may be later renamed to Grav 2, depending on how we want to tackle the backward compatibility.

[MakePixelsWork]

Maybe I'm late to the party... and this is not for feedback... but....

1. Would it be possible to have a clean structure in Grav 2, where all the contents of the CMS is in its own root folder (for instance a 'grav' folder), so it is separate from the other possibly systems we developers install on our sites? Currently, an install places everything in the root of your site.

2. A .htaccess file that is not re-written by the system, but rather combined with other .htaccess that is already in it? Or... a htaccess section inside the CMS, that allows for the developers own htaccess stuff to add? I do a lot of stuff in htaccess, from some hacks, to safety, error page handling etc, but those keep getting overwritten whenever Grav decides the htaccess needs an update. PS: I raised this issue back in 2019 on the chat servers. Don't know it this have been dealt with since?

3. Number 2 also applies to the robots.txt - which could/should be a combination of the user defined and cms defined settings.

[mahagr]

@MakePixelsWork You likely use the wrong package to update Grav, as the update package doesn't contain htaccess or robots file.

[MakePixelsWork]

@mahagr > I never said anything about an update package. I was talking about the core. The self-hosted Grav Core and Admin has the .htaccess and robots.txt it in its download. I double checked and viewed the download on getgrav.org, v1.7.26.1, for 6 days ago. Both are in the folder. After install they are also there, I assume, since my local version also has them.

[mahagr]

Oh, those are the default files for sure, required to make Grav to work at all. They cannot be removed or majority of the sites would break.

If you need your custom files, you should first copy the files and then override them with your own install script. Or you copy the files into a separate location and delete the files you don't want. I do that all the time and not just with Grav.

[Heraes-git]

I suppose @MakePixelsWork wants a system of update that can (and that's the purpose of any update system) to check files modifications and timestamps to decide wether or not it needs to be "updated". Thus, its modified htaccess wouldn't be overwritten.

Currently, an install places everything in the root of your site

When installing Grav, can't you decide to create a sub-folder at the root of your website, before installing ? Or even when installing, by specifying a sub-folder in the github command ?

[MakePixelsWork]

@Romarain > I think I can install in a subfolder, but then the site pages will also have that folder next to the domain. So www.domain.com/page becomes www.domain.com/subfolder/page/ where subfolder is 'grav', 'site', 'blabla', depending on what you chose.

@mahagr > Since these are needed in the root, and some of us developers also write our own HTACCESS stuff, we need to have some sort of combination. If for any reason I update the Grav system, and 'they' decide to overwrite the htaccess, all my edits are removed from the file. This also applies to robots.txt. Probably any file that is part of the system.

[mahagr]

This is how I do it:

• Install Grav
• Modify .htaccess and robots.txt files (or copy default versions you use)
• Update Grav only by using CLI command or from Admin, NEVER use the installation package

Grav will never override htaccess or robots files again. And yes, I do use custom files.

[jrivero]

I think these are sample files that are not strictly required by a grav site, to facilitate the update they should be removed, so it would be just unzip and replace. On my sites I don't use apache and the htaccess file is of no use to me, and on my sites I have my own robots.txt files that I need to maintain between updates.

[MakePixelsWork]

I'll take note of aforementioned procedures ... but assumed they would be updated with Grav updates. The team should know this, so if they can verify these are never overwritten, I can install something and then never overwrite it again.

And yes... I too can take care of two files, but I was just wondering if it wasn't a better option to have some module inside Grav that handles the Grav side of the file and in which you can handle some of your own code as well. Although on second thought, that's also a very crucial file that can fock up someones site. So maybe there is also a reason to NOT include it as an editable file inside Grav. Food for thought?!

Thanks to all for feedback!

[josephdpurcell]

It would be great to upgrade to CodeMirror6 for Grav 2. This may likely address #3666.

[u07]

1. A table editor like in DokuWiki. Tables are the weakest spot in markdown.
2. A plugin like "Admin" but for editors / content creators. It should be clean and simple, free of other stuff, so nothing distracts me from writing deep and profound articles.

[u07]

3. Automatic images insertion with full version available on click, like in DokuWIki.

![zebra](zebra.jpeg?width=400)

V

<a href="/user/pages/hires-photos-from-zoo/zebra.jpeg"><img src="/cache/x/zebra.webp"/></a>

May be there's already a plugin for this?

[svatas]

I just found that Roadmap. As I am the person who started Request #2947 I was checking what is going on that matter. I found that the translation philosophy change is not on the list to version 2. Is possible to add this topic as well?

[xinity]

@rhukster is 2.0 a dead project?