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!

[tim-bradley]

@hughbris - Re A Static Option - Maybe it should be a pluggin. It depends on Grav's objectives. But it is faster (more so as site size and load increases) and uses less resources, and it isn't accurate to describe this as a 'a less common functionality' - it is 'less common' because it isn't a functionality. Perhaps a better method to determine whether to provide proper support in core or not is:
How many Grav users would actually use this functionality? I suspect a significant share would.

[avxkim]

Enable Pure Static Option in Core While Grav is fast, it would still be nice to be able to specify a pure static output (except for /admin) without plugins / hacks for speed and even lower resource usage.

Not needed in core 100%. Better improve page collections and overall performance instead of adding useless functionality. If you need SSG, use something else, like Jekyll

[tim-bradley]

Not needed in core 100%. Better improve page collections and overall performance instead of adding useless functionality. If you need SSG, use something else, like Jekyll

@heihachi88 I can understand debate about whether this should be a plugin vs core feature - but to describe this as 'useless functionality' and to suggest I go use Jekyll is both factually wrong and inconsiderate respectively. Also, suggesting that only one or the other can be implemented is wrong too. I realise you have your wants, as I do mine, but lets keep an open mind to suggestions - that is what this thread is about.

[avxkim]

@tim-bradley, well, in what cases this should be USEFUL in a GRAV core? Core should be clean and fast as @hughbris noted. I don't see a reason to use GRAV if you plan to use a plain html functionality.

[w00fz]

Guys let’s keep this civil and let’s try not to turn anyone’s idea down, they are all welcome!

I think there’s definitely room for improvement in the collections so that external resources such as plugins can do more work with them, including generating static content.

[tim-bradley]

@heihachi88 - I suspect you think I was attacking @hughbris . I was not, and apologise if my response to his comments came off that was. This is deteriorating so, I will simply say this before I leave:

• There are real world benefits to offering a static output option
• A static output option could be implemented so that it has no impact on performance for those not using it, and with very little core addition - ie. it doesn't have to 'clutter up' the core nor ruin GRAV's awesome performance for those not using it
• Wanting a static output option from Grav is not comparable to using Grav as a typical SSG (Jekyll, Hugo, etc) -> Grav offers many additional benefits they cannot offer, including admin with sign in/ authorisation, image processing, asset management etc

[hughbris]

LOL, I had a response prepared, but it's not important any more. Perhaps this open issue is not for judging the merits of suggestions (as I did) and better thought of as a brain dump. Seriously, open a new issue in Grav core to put forward your case and anyone can debate this feature. I'll pitch in!

BTW I would use this functionality in a flash with a bloated CMS. Ideally I would switch to Grav instead though :)

[koreos]

1. Large Site Support will be very nice and is very needed :-)
2. Edit template from admin panel is also very needed and useful. For example like here https://generatepress.com/premium/
3. Please not use MySql or any SQL!
4. Simple add block with text, js, php to the content and code with shortcode=snippet. Look here is perfect solution http://monstra.org/documentation/shortcode-api or here is demo http://webuzo.com/demos/Monstra

Important questions:

1. For how many pages/subpages is Grav now? Only for 1000 or little more?
2. When we can see Grav 2.0? :-)
3. When we can see new admin panel and what price will be?

[koreos]

And now in admin panel is Pages for all but I think will be really more simple and useful for many people who are not webmaster do it separated: News Blog Pages Gallery Downloads etc. - it looks much better.

[mahagr]

FYI, I updated PHP 7 requirement to 7.2

Please read: https://getgrav.org/blog/raising-php-requirements-2018

There is also another roadmap for Grav 1.5: #1977

[jlehtinen]

Any ideas for how modular pages might turn out in Grav 2.0? I've noticed this is a major pain point for content creators at the moment, often leading to cries "let's switch to Wordpress!". (Are collections/objects or content blocks possibly related to this?)

For easier creation of modular pages inside admin (well, local file system as well) I'd intuitively think something like this…

• Allow modular pages to consist of multiple markdown files in the same directory, i.e. modular.md (as it is now) and sections/modules such as _hero.md, _columns.md, _cta.md, all named with a preceding underscore, just like current modular section directories are
• Display all the modular sections present in the directory in Admin's editor view, i.e. all in one, long view with expand arrows and drag handles for ordering
• Page media resides in the same directory

There would have to be a default modular template for these, because the current "name is the template" system wouldn't work.

[mahagr]

@jlehtinen Collections/objects are a kind of solution for this, or at least they allow you to have multiple different strategies on how the files are stored in the filesystem. It wouldn't (itself) fix admin, though, as for how admin handles pages is more of a design decision in admin itself.

[jlehtinen]

True, nothing stopping from making the admin work as described above for modular pages as it is. Just trying to think of a solution that's intuitive & efficient for both admin dashboard and filesystem users.

[CSixtyFour]

I would like to be able to edit all yaml files in the admin panel.

It would be really nice for users to be able to edit form and language files themselves rather than having to jump out to a text editor or IT support.

[CSixtyFour]

One small one

I would like the slug for modular pages to be seo and user friendly i.e. does not start with _ such as homepage#_services

There is already a lot of good slugness built into Grav but unfortuntely mostly for pages not modulars.

[drnasin]

@CSixtyFour I'm not sure I understand the "modular seo" suggestion. I have it like so on my homepage (grav) and every section is prepended with hash (#services, #faqs ...)

[CSixtyFour]

@drnasin yeah I think my comment wasn't very clear at all.

I use modular panels a lot but and I've ended up having to create a manual anchor field so I can link from other modulars/ pages.

Pages have the slug field but this doesn't work well with modulars (link then contains _ and can't be manually set), I wish modulars had an equivalent to the slug field built in for creating anchor links.

[drnasin]

I would also like to add my $.02 on this subject as I have been using Grav a lot in the last year. I use it for 80% of my projects and new customers so I really had the chance to test it to the limits. Here are the current limitations for me, areas I can't "push" Grav into so I have to use the "usual suspects".

Grav e-commerce

Besides the snipcart plugin which is pretty much useless if you don't use snipcart we really don't have any really e-commerce support. Even in the "club" we have one theme (again using snipcart). We need more stable (official?) solution for e-commerce so we can start using/pushing grav into this direction. Would love to start making more e-shops based on Grav. For now I have only one but the customer's needs were really low (no shopping cart needed, so it more of a catalogue rather than a shop). Summary. We need official "e commerce" plugin. Would be willing to take over the project if needed.

Grav editorial/news

Again another weak spot for me as I can't "push" Grav into news portals. There is no "editor can edit only his content" system which makes it look very amateurish in front of the customers so I don't use it there...

(off topic) Gantry

I'll be the first to admit I was so wrong about Gantry. Gantry is so amazing and it deserves so much more "credit". Once you've mastered Grav (my platform of choice), Gantry is so frickin awesome! We need more docu on how to implement our designs into Gantry (I have my ideas but would love to see an official video..kind of "making of" a rockettheme theme). Also more docu on using Grav vars inside particles (had to figure out on my own)

(both) Learning curve

I said it somewhere and I'll say it again. I personally LOVE that Grav is a bit "harder" to swallow. Not because Grav itself. It is of how Grav "connects" 3 technologies (usually very new to a developer). Twig, YAML and Markdown. I myself had issues learning Grav but it was so worth it. I tried to get few younger devs who work for me excited but to no avail. Learning 1 new technology was "hard". Let alone 3 + how they all connect. I think you guys did a brilliant job with documentation(s). Always up to date and current. I'm not sure what else could be done better here. I already have 2 abstracts in works to offer to various conferences and try to get more word about Grav out there (to devs, not just "Normal joe"). We need more devs and agencies (like me) excited who will push Grav to customers.

[drnasin]

@CSixtyFour

I use modular panels a lot but and I've ended up having to create a manual anchor field so I can link from other modulars/ pages.

You would have to do that in any CMS :) but creating those anchors on the fly is not so hard! It's just a small for loop in modular.twig ... or did I misunderstood something..again... :D

[CSixtyFour]

@drnasin Yes you right but the point I was trying to make was that there is already a simple built-in possibility in Grav - using slugs as anchors - however slugs are fine for pages but don't work well with modulars and it would be nice if they did as it could be really useful rather than reinventing the wheel.

[coolemur]

GraphQL API would be a game changer!

[leotiger]

@drnasin: Concerning GRAV-ECOMMERCE, I made a lot of progress with a modified version of the shoppingcart plugin by @flaviocopes. On top I added two add-ons that offer a lot of nice features like stock management, unique product support, e.g. for artists, double checkout control (client and server side) which adds additional security, product stock check, bulk updating, including translations, compatibility with high speed optimizations (see #2093), etc.

I will roll out some of this stuff during the next weeks.

[jlehtinen]

One thing I've always found a bit less than optimal about Grav is how cluttered and unorganized the root and user folders seem. Might it be possible, for example, to move the host specific configurations to, say, /user/config/hosts?

[hughbris]

@jlehtinen:

move the host specific configurations to, say, /user/config/hosts?

I'm on board with this change. Don't agree that it's especially cluttered and disorganised at present, though.

Probably user/hosts is a better path, since not everything in host folders is necessarily config.

Also, I imagine it's reasonable to support the current hosts structure (deprecate) until v3.

[mahagr]

Regarding host configuration, I've been using /user/sites or /sites (eg: /user/sites/getgrav.org/config) as it allows me better encapsulate all site-specific content into a single folder structure. It allows me to use environment:// stream better to customize anything I want without too much effort.

[hughbris]

Regarding host configuration, I've been using /user/sites or /sites (eg: /user/sites/getgrav.org/config) as it allows me better encapsulate all site-specific content into a single folder structure.

Are you saying this is currently supported? Isn't that the multisite structure, and is that a good idea since it's not quite the same thing? (I can see pros and cons.)

It allows me to use environment:// stream better to customize anything I want without too much effort.

New to me, sounds cool.

[mahagr]

It is all supported, though only through setup.php. Environments and multisite are the same feature, but multisite with setup.php allows you to have more freedom in how you set it up instead of being locked to default behavior..

[leotiger]

I've been discussing today with @rhukster in the context of the new Babel plugin for GRAV. He detected an issue that I've been unaware of:

It's common practice of plugin authors to introduce language variables for the plugins under a common namespace, the plugin domain, e.g.

en:
    PLUGIN_BABEL:
        DOMAINS: Domains
        TRANSLATIONS: Translations
        ETC: etc.

On the contrary many themes but as well a few System definitions directly attach the variables to the language root. This introduces two problems:

• Variable names without the necessary specificity may be overwritten by other variables, imagine a definition named DESCRIPTION in theme and as well in a plugin and directly attached to the language root. This causes a consistency problem.
• It introduces the necessity to add a lot of tracking for these cases for plugins, etc. that handle translations (hopefully there will be more in the future)

You can read more on this in the documentation issue for the Babel plugin:

Unclassified domain

Would be great if GRAV 2.0 would force to use contextualizations declaring invalid all language definitions (by remove or other means) that do not fulfill this condition:

en:
    DESCRIPTION: A description

should trigger an invalidation. The effective root level below the language should only allow arrays and no definitions. And clearer:

All definitions shall be attached in a language yaml file to a common root denomintor, the language domain:

en.rootdenominator.definition1 en.rootdenominator.definition2

and so on.

[jza34]

Hi! Could be great to make it easier to extend forms. Currently only based on the frontmatter make it difficult to customize with twig... Thanks!

[newbthenewbd]

Here go my five kilobytes of a tiny humble idea that totally isn't going to ruin someone's few days' worth to implement in a backwards-compatible manner, would it be possible to get something similar to the Auto Date plugin (but perhaps setting the dates during onAdminSave :upside_down_face:) officially integrated into Grav 2, thus starting to ignore the timestamps provided by the OS? (well, mostly, the compatibility code has to work somehow)

My reasoning behind requesting this change is that most of the time, whenever the creation dates are relevant at all, people don't want them to change during page modification - think a blogger fixing a typo in an old post, just for that post to jump ten pages upwards with virtually zero ways to figure out how exactly it was dated before. (logs, eh?)

At the same time, for the websites which do want the dates to change as a result of even the slightest edits (#masterSEO?), an option could be added to make the dates get modified during the above-mentioned onAdminSave, or a plugin could supply that functionality, too.

Okay, one says, but if a plugin works for fluid dates, why isn't a plugin for static dates enough? Quite simple - system timestamps are unmanageable. Now, so that I don't end up figuring out unrealistic horror scenarios with specialized virus scanners putting All ok!! messages in some very unfortunate places, let me mention my own story right now, be it horror or not.

<story> I wanted to create a plugin for page favorites, and it has forced me to put stuff in user/data to preserve correct dates, a massive increase in overhead, while a simple favorites: x page header variable could work very well, if the timestamps were ignored. In fact, I haven't done this, as I use auto date and I'm lazy, so the plugin is private. </story>

Okay, just kidding. It's a true story too, but that one is easily solvable. Here comes the...

<actual story> A few months ago, newbthenewbd/grav-plugin-tinymce-editor#18 has been submitted to the TinyMCE Editor Integration plugin, which I maintain. It's essentially an issue about static relative links to attached media always being wrong with modular pages. I would like to have a fix for it available in the next, presumably long-awaited update, so I've checked my options, ordering from easiest to hardest. Option no. 1 Just use absolute URLs, letting a single page rename, page move or whatever else affecting the path mess up it all. Baaad! Option no. 2 Generate the relative URLs dynamically on page load with PHP, for we all know how fast the required DOM parsers are, right? This works with Markdown, but with HTML... Baad! Option no. 3 Generate the relative URLs dynamically with JavaScript on page load, ignoring the pleas of the users caring about their privacy, and possibly those with messed up browsers, too. Okay, this actually works, as it did for the person who submitted the issue. But still... Bad! Option no. 4 Generate the absolute URLs dynamically, running the generator only when an action is performed in the admin plugin that modifies the path, assuming that the people who are modifying files directly definitely have the time and abilities to run what usually is a simple search-and-replace. Good! But wait... I can generate the URLs on the pages directly getting renamed and/or moved just fine, but how do I get to their children without breaking all the dates and orders? Oh, of course, apply a very ugly hack using raw PHP functions that will break someone's website the next time Grav updates... Ough! Option no. 5 Like option no. 2, but add a clever cache setup that remembers the corresponding URLs. Perfect! Except... Not only is this so difficult to do good that it will end up broken in multiple ways, most of which will first be noticed by the end user (long live cache!!), it's also still slower than option no. 4.

Quite obviously based on the context, I thus far chose option no. 4 without modifying children, so unless I figure out some magic to achieve this using some of the safe functions available in Grav, modular pages will still be broken somewhat, just in a hopefully slightly less infuriating way. ~</rant>~ </actual story>

Anyone still reading? Oh, good. So what does the above have to do with the feasibility of using a plugin for fluid dates, versus one for static dates? Also quite simple - if the default behavior is something similar to what the Auto Date plugin does, then the dates only get modified when a designated event is fired, typically letting a determined plugin modify pages without triggering date changes, in a way that isn't going to break precisely while the plugin's author is having their well-deserved lunch.

[hughbris]

My reasoning behind requesting this change is that most of the time, whenever the creation dates are relevant at all, people don't want them to change during page modification - think a blogger fixing a typo in an old post, just for that post to jump ten pages upwards with virtually zero ways to figure out how exactly it was dated before. (logs, eh?)

At the same time, for the websites which do want the dates to change as a result of even the slightest edits (#masterSEO?), an option could be added to make the dates get modified during the above-mentioned onAdminSave, or a plugin could supply that functionality, too.

That was a fun read! Might be missing something, but aren't these issues most easily solved by adding different date headers in the frontmatter? So as well as simply date, there's also, say, modified. date is like a creation date and treated as essentially immutable. If deemed useful and reliable, system date can be derived as needed.

I've been through these considerations when I used to work a lot with popular syndication formats (RSS/Atom). We had requirements:

• retain original item date
• maintain a date for substantive changes (discretionary to editor, I like the definition in the Atom standard)
• maintain a date for trivial edits ("just in case", more of an audit/accountability requirement)

We left it up to consuming applications (reader etc.) to decide if they wanted substantive edits to result in the items being promoted to the top of listings.

So Grav's Admin editor interface could include a checkbox where editors can indicate whether the edit they are making is significant. Their call. That checkbox would affect whether the modified header is updated.

(Note that this is separate to publication dates, which are already covered in Grav by publish_dateand unpublish_date.)

[jlehtinen]

Have there been any plans to make Grav stateless in future versions? We've run into a problem where Grav is the only piece of our infrastructure where load balancing between server nodes for redundancy isn't possible, because the cache file naming doesn't match between instances, and we can't use session persistence.

[rhukster]

I didn't actual realize there was a problem. Not tried this myself but having different cache files should not be an issue in itself if using file based cache. They would just be unique per server. Even using a unified cache like mcached or redis should just result in unique cache per instance, but should still work. What is the problem specifically regarding that?

Session also being unique per server simply means that user session should sticky to a single server. This is very common approach and is supported by most load balances. So again what specific issues are you having there?

Maybe open a new issue about this so we can discuss a bit more in depth?

[lufog]

I would like to see in Grav 2.x the following features: 1) The ability to choose a content storage system, such as Flat or SQLite. In addition, SQLite will solve many problems associated with content bind. For example, what to bind comments to the page or to the user. 2) Decoupling of some components of the admin plugin. For example takeaway standard content editor in a separate plugin. For now, in order to adapt any HTML editor to Grav, you have to resort to a lot of crutches. For example, to make your editor interact normally with the Page Media box. 3) And of course, the editor of groups and users. I have no idea why it still does not exist, at least in the form of an official plugin for the admin plugin. 4) The possibility of carrying languages into separate packages.

[mahagr]

@Lufog-git

The idea we have is to keep all the main data in the filesystem -- after all the idea of Grav is to have all the data as files so you can easily copy them over or push the changes into git. That said, I'm currently investigating having indexes in separate files or alternatively in SQLite. Those can be removed and will be rebuilt if they are missing.

What comes to the other ideas, we have had those in our mind, too, but not enough time to do everything we want.

[qumuq-til]

From a purely architectural point of view I do hope Grav isn't going down the same path as every other major CMS, that is, adding databases first optional and then as a requirement (even if it's SQLite), adding widgets on top of modules, and on top of that adding WYSIWYG editors in 5 flavors, no less. Even though we all want Grav to be more and more popular, it's probably much more important to let it stand out in the crowd by sticking fast to its original strengths, rather than evolve into Wordpress. Not saying that's what's happening in version 2 or even 3, but let's just hope it would never happen.

For me Grav was a breath of fresh air, simple, lean, understandable and a system that made a lot of sense. I always developed websites in a text editor, had full control over the code and would never willingly touch a CMS like WP or Joomla, so Grav essentially leveraged all the pros of that approach and didn't introduce any cons. And importantly compared to other CMSes out there it's super easy to learn.

[bleutzinn]

In addition I would like to suggest:

1. Multi-user support by preventing simultaneous page edits through a check-out and check-in mechanism.
2. Support for a publishing workflow like draft-review-staging-live.

[fosil]

Mainly, please, do not change any basic concepts! because Grav is great for fast and highly customized small and medium-sized sites.

Stay "flat" (no SQL ballast), leave only basic things in the core. The concept for expansion is strong enough. There is no need to produce another complicated and confusing system in which the same non-it guru administrator does not know. Here we have WP, Joomla ... :-)

• No WYSIWYG: From this are plugins. The one who needs it will make the plugin lightly, and I suppose it will offer it to the community. The ease of working with Blueprint allows you to easily structure the design pages into individual fields in which the basic formatting provided by markdown is sufficient. This is much better for today's intricately structured sites than a heap of hideous HTML hells (because of responsivity!)
• No SQL (I'd like to repeat it again :-): Grav is manageable through the versioning systems like git. SQL will destroy it.

What would be useful (in my opinion):

• More powerful query system for collections. E.g. childrens of PAGE with tag in array(tag1, tag2) not tag = tag3 and category = category1 - But let's not get over it so it does not have to go to relational databases
• Possibility to install things that are not part of the development of a particular site as a dependencies. (core system, plugins). It is not necessary to have plugins in repository. And does it make sense to invent something that already exists? Composer? It would be ideal to separate "distributed" and "per project custom" plugins into the file structure.
• More delicate rights management. I often need one user (group) to set up a plugin but not install it. Or, you could only edit / paste pages in a specific part of the site. But most of all (because I use Grav mainly for smaller sites), I just have to disable plugin installations and allow only some configurations (system, plugins). This makes Grav for the end customer even easier and more usable for administration. He sees only the most necessary and not billions of buttons and choices, as is the case with WP, Joomla ...
• Smarter page media
  • add an alt / caption to the image in the media
  • possibility to have such page media boxes more in blueprint (store in a subfolder with the name of a field?). Ideally drag and drop copying / moving between boxes
  • keep the page media idea, but have a similar component at the system level for shared media
• small improvement multi-language support - e.g. date in non-english languages

[rhukster]

Just FYI, we are NOT going to change the fundamental paradigms behind Grav and suddenly require SQL. All we will do is to move more things to our new FlexObjects paradigm that lets you customize the storage mechanisms. The default mechanisms will mimic the existing folder structure that you use today, but will allow customization to store files (such as indexes) in other locations, including databases.

[adminnu]

I am very pleased with grav and try to go everywhere with wp and other cms. First of all, due to the speed of creation of simple sites on it and easy understandable administrative interface.

What is missing. In my experience, when the site is designed and there you can run an editor who is poorly versed in development, he often has a problem with its content, namely: 1) If you add your own page management properties, YAML FrontMatter, it just forgets what everyone is responsible for. Therefore, it would be great to be able to make these parameters in the form of fields on the edit page, without developing plug-ins, where the editor could put a checkbox, for example, if this is a boolean field, select a file from the loaded ones, for example, a banner page, etc. And unused, standard, fields, hide. The expert mode is great, but it is difficult, especially to add for example one property to each page. 2) If you upload a file in Russian or with spaces, then it cannot be inserted into YAML FrontMatter, or rather, you can, but you need to add quotes, and in some cases such images are not displayed. Therefore, the editors first rename the image on the computer so that there are no spaces and everything is in Latin, and then they only load. Why not add maybe renaming files uploaded to the page? Well and to replace with the automatic machine spaces and characters which in url will be transformed to essences? 3) It is more convenient to implement the selection of the parent folder, now if you create a page not from an open folder, you have to search for the desired folder among the many unnecessary as well as modular pages. Some improvement is needed here. 4) Authorship of pages with reference to the current user. For example, to specify authorship now, you need to add the YAML FrontMatter property again, for users, it would be nice to add 2 fields at once, the creator and the author, so as not to go into the expert mode. And it's great if the creator will automatically be put on the account. 5) Now there is no convenient way to display information about a user from accounts, that is, there are accounts of the authors of articles, with filled in data, a photo. But in order to display it on the page, you need to add his email, name, photo to YAML FrontMatter. 6) Combine the authorization of the administrative panel and the site. For example, there was a need for site users who are in such a group to show the site structure differently, but not to add site authorization, but simply log in to the administrative panel and watch the site. It is the same and vice versa, if there is authorization on the site, to have access to the administrator panel, without re-authorization.

[DaliborIlic]

Just GraphQL, please, everything else is sublime.

[mahagr]

@adminnu

1. Unknown but existing frontmatter variables are already kept in Flex save. I didn't fully follow your idea, though. There's also a way to customize form by ACL.
2. Yes, this is a limitation/feature of YAML and is true for English, too. Renaming already works (you need to configure it), though with a few issues.
3. Do you mean that you'd like to have modular content in the same folder with the page?
4. Can already be done, but isn't automatic without some custom code.
5. If you mean showing author box in a page, it's really easy to do.
6. There's already configuration option for this, I'm using it in multiple sites. :)

[adminnu]

Thank you very much for your reply, I am glad that what I have described is already there or will appear soon. It will be great if these changes appear in the documentation.

3. Do you mean that you'd like to have modular content in the same folder with the page?

No, I'm just talking about this select https://monosnap.com/file/s2bibGz86fUg55mqVEodihEuRRtlWU . It is very inconvenient if it is a publisher, where the number of pages is huge, the list will be very large. Not to mention the extra modular pages. It should be improved in terms of user experience.

[lufog]

@adminnu @mahagr I talked about something like this on admin plugin repo: https://github.com/getgrav/grav-plugin-admin/issues/1563 Where I proposed my solution to this problem.

[lufog]

I would like to see сhecking for updates to themes/plugins by name and author. Since not all extensions written for grav are published in the repository. I had a case of a client site crash after updating Grav and plugins. It turned out that the plug-in written by me, for his website, when updated, was replaced by another from the repository. I was lucky at that time, because I set up a scheduled backup.

[mahagr]

@lufog I'm using symlinks for my own stuff, which prevents them from being updated from the repository.

[w00fz]

Namespacing themes and plugins by author name and type is something I always wanted to have. That would definitely prevent name collision between same name/ different author and same name / different type (theme vs plugin).

v2 is probably the best place for looking into this.

[neilpanchal]

Completely unnecessary but insanely awesome: Re-design Admin interface that takes advantage of Spectre CSS's components. Or take inspiration from Stripe UI :-) The current admin interface looks very dated...circa 2010'ish.

[mahish]

• image processing on upload/save (simply put: in admin not in website itself)
  • Im having timeouts on heavy-image sites
• image meta (captions,…) editting capabilities in admin (simply put: native gallery support)
  • clients can't add captions for images easily

[Heraes-git]

Even though we all want Grav to be more and more popular, it's probably much more important to let it stand out in the crowd by sticking fast to its original strengths, rather than evolve into Wordpress

Wouldn't have said it better. This is pretty much the most important and wise comment in this topic. GRAV team must always remember that the danger is to become too big. And I know that it is hard to stop oneself when improving more and more.

So, basically, the metalogical roadmap should be :

• To fix bug / correct flaws (if there's)
• To improve (rapidity, rendering, etc) if possible.
• To maintain plugins : the nevralgic center of any CMS is its plugins. GRAV is doing well for now, but there's still a few third party plugins that can be missing some support sometime, and would gain interest in being integrated in the "official" plugins. This being said, I'm incredibly satisfied on how fast the Grav team is responding on Github, and have to thank them for that devotion to even the tiniest soul.

GENERALITIES FOR GRAV'S WEALTH

If I had a few personal ideas on how to improve Grav, it would be this :

• Improve/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.
• Create categories to sort plugins on the official depot. I'm actually doing my own tree-sorting in my bookmarks, but it would be appreciated to have categories when browsing the library.
• Keep track of possible missing or wanted plugins. (suggestion box ?)
• Keep track of "abandonned" plugins (inactivity on GitHub / old update) : very usefull to bring some people to participate !
• Attach a "team" to each plugin, in order to contact volounteers (devs / regular users) rapidly on Discord. This could be seen as a "unofficial pro support".
• Impose or strongly encourage use of the built_in_css yaml option for development of plugins, in order to allow webdevs to deactivate plugins' CSS and avoid certain conflicts with their design.

And then, regarding to development with Grav and features :

INSTALLATION / CLI

• New CLI commands :
  • A single command to install Grav, based on a preset of possible installations (cloning master or testing or specific branch + install it directly in the actual folder (not in a sub one) + composer command automatically following + $bin/grav install). Excuse-me ? You said that "it's impossible because it would require to have Grav already installed for having the aforementioned commands" ? :) Well, it would be a good idea to have a kind of stand-alone grav command or installer (like npm). But it's just an option, a sophisticated caprice.
  • Ability to quickly check installed things (plugins, themes, etc). That's a real miss : actually, there's the possibility to manually pipe to grep ( $bin/gpm index | grep '| installed' ), but the last time I tried the exact same technic, it failed (maybe due to Grav update and new outputs ?). Anyway that's tedious and a command would facilitate things (like $bin/gpm installed or $bin/gpm index -i).
  • A backup restoration command ?
• More craaaazyyy CLI commands :
  • Ability to change a page's frontmatter option ? (would be so coooool :D )
  • Ability to change a plugin config option ? (same ^^)
  • Ability to toggle between a dev or prod environment :
    • Automatic creation of the /user/localhost folder, with clones of system.yaml and admin.yaml.
    • Auto-defining of basic presets for each environment (cache, pipeline, etc).
  • Ability for developers to quickly create bunch of pages at the OS level in order to avoid manual folder/file creation (I imagined a plugin wich could do that ; but have no skill to develop it for now). Options would be : Title, type (regular/modular), parent, template and/or markdown name. A batch creation could be feasible for any parent branch (/root or another) : collective type and template/markdown name, followed by an input for each page's name, and voila ! A dozen pages created in a snap ! ^^
• Reallocation of the whole Grav updating command : I found strange to use $/bin/gpm self-upgrade instead of $/bin/grav self-upgrade. All general Grav maintaining should be done with the grav command. GPM should stick to packets.

ADMIN PANEL

• Native <table> feature in the page editor. Not a basic one in unreadable markdown : a full one, with WYSIWYG cells ! :+1:
• Positioning of the media dropzone on the right side of the editor, not below. It's pretty impossible to drag things comfortably for now. I actually developed my own CSS remaping, I could share it.
• Ability to sort pages (drag'n'drop) directly on the root of the Pages tree in the admin panel.
• Ability to sort modular pages in the admin panel instead of only in the frontmatters (necessitate dev skills).
• A clarification of the difference between "published" and "visible".
• The gathering of mainly used options in the Content tab, in order to accelerate page's edition. I think about visible, routable, template, and body_classes, for now (wich are the most used options by both devs and users). Also, the children tree (but it takes place, I know). Moving them (or allowing to do it) from the Advanced tab to the Content tab would be appreciated. It may be actually feasible with blueprints, so please ignore this request if it's the case.
• A more logic use of the superadmin variable. It seems that some plugins (like admin-addon-user-manager) fail to work correctly because of the fact (or plausible hypothesis) that to perform some deep tasks, it is necessary to activate that power, but that at the same time it doesn't take into account any sub-rule limitation (this giving unwanted access on certain things).
• The possibility to tweak the template dropdown, in order to hide some templates we don't want to appear (ex : the error template appears, despite it won't ever be volontary used 99.99% of time).
• Fixing of the tabs selection when opening a new page edition : actually, it positions the view in the same tab than the one in wich we were during the last page edition. It should open the editor always in the Content tab, in order to avoid user's confusion.
• A batch edition for pages (for accelerating the change of template name, etc). We can imagine a checkboxes type of thing, on the left of the pages' tree, with some action to perform.

MARKDOWNS / TEMPLATES / TWIG

• The possibility (if not yet) to have an HTML version of the markdowns, and a way to link those versions to some plugins (I mean, an accessible variable or something, in order for any plugin to work specifically with this type of file instead of the markdown).
• A default /modular folder, with a default /modular/default.html.twig template. Actually new incomers in Grav may be confused about how displaying a modular page, because of that absence.

DEBUG BAR

Messages tab

The name of the variable/content dumped with the {{ debug() }} calls. Actually, it just displays the result, on the left (ex : true. True for what ?), where it should display the name + the result for a better view. When dumping one or two things, it's okay, but if tens of dumps are let in templates for debugging purpose and suddently activated, or if a simple loop is done with a few dumps, it's hell.

Timeline tab

The possibility to unfold an entry (ex : Twig, or Pages) in order to see exactly wich elements are implied in the rendering, and the time they take. Actually, if we see that the Pages generation takes too much time, we're unable to see what page specifically cause the problem. Same thing for all the actual entries : we don't have a real tracking. Maybe I'm mistaking and there's a way to do it, but I don't know.