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!

[onetrev]

I wonder what the feasibility would be of implementing Gutenberg for Grav would be? If even Drupal is looking to do so, there must be some strong benefits to doing this. As I see it, a universal, cross-platform content editor definitely has some appeal -- from a developer standpoint and for end-users.

One specific benefit is it could also help make it easier for users to move from WP to Grav. As I understand it, Gutenberg (while far from perfect yet) is built to be able to be easily ported for working outside of WordPress. For example there is this cool gutenberg-js project.

[onetrev]

Just to add context to my above suggestion, a Gutenberg implementation for OctoberCMS has recently gone into beta. Unfortunately I guess the core for this implementation won't help us here since Grav is not Laravel based. But maybe other Gutenberg ports in the near future will be easier to integrate with Grav -- hopefully!?

[wernerjoss]

hm, please note there are people out there (including me) who have recently switched from Wordpress to Grav because of the Gutenberg disaster. so, if there are any plans to incorporate this in Grav, make it an option, NOT a requirement.

[rhukster]

@onetrev we really have no interest in Gutenberg or similar solutions in the core of Grav. If someone else wants to create this for their own or client needs, then that's fine.

[apidevlab]

Just my 2 cents... The option to modify the main theme "core" variables via the admin would be superb. Simply thinking of the main palette colours from Spectre (assuming the use of the Quark theme)

Also, +1 for...

Ameliorate/update some documentation pages, where there is some "ambiguous" information or lack of information. But that part could be filled by anyone (including me), given the opened editing of the documentation. So it's a hollowed statement, but I had to say it.

[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. :+1:

[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 https://github.com/getgrav/grav/issues/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?