Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap for Grav 2 #1767

Open
rhukster opened this issue Nov 28, 2017 · 118 comments
Open

Roadmap for Grav 2 #1767

rhukster opened this issue Nov 28, 2017 · 118 comments

Comments

@rhukster
Copy link
Member

@rhukster rhukster commented Nov 28, 2017

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 7.2 Requirement

    Grav 2 will require PHP 7.2 (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
Copy link
Contributor

@jgonyea jgonyea commented Nov 28, 2017

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
Copy link
Contributor

@ricardo118 ricardo118 commented Nov 28, 2017

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
Copy link

@apfrod apfrod commented Nov 28, 2017

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
Copy link
Contributor

@MujibAzizi MujibAzizi commented Nov 28, 2017

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
Copy link
Member

@mahagr mahagr commented Nov 28, 2017

@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
Copy link

@andrewscofield andrewscofield commented Nov 28, 2017

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 mahagr closed this Nov 28, 2017
@mahagr mahagr reopened this Nov 28, 2017
@mahagr
Copy link
Member

@mahagr mahagr commented Nov 28, 2017

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
Copy link
Member

@w00fz w00fz commented Nov 28, 2017

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
Copy link

@sphism sphism commented Nov 28, 2017

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
Copy link

@hexplor hexplor commented Nov 28, 2017

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
Copy link

@sphism sphism commented Nov 28, 2017

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
Copy link

@hexplor hexplor commented Nov 28, 2017

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

@sphism
Copy link

@sphism sphism commented Nov 28, 2017

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
Copy link
Contributor

@MujibAzizi MujibAzizi commented Nov 28, 2017

@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
Copy link
Contributor

@paulmassen paulmassen commented Nov 29, 2017

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
Copy link

@boettges boettges commented Nov 29, 2017

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
Copy link

@tourtools tourtools commented Nov 29, 2017

I would like to see also:

  • better multisite management
  • wysiwyg editor integration
@coder4life
Copy link
Contributor

@coder4life coder4life commented Nov 29, 2017

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
Copy link
Member Author

@rhukster rhukster commented Nov 30, 2017

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

@cpfeifer
Copy link

@cpfeifer cpfeifer commented Nov 30, 2017

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
Copy link
Member Author

@rhukster rhukster commented Nov 30, 2017

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.

@cpfeifer
Copy link

@cpfeifer cpfeifer commented Nov 30, 2017

@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
Copy link

@sphism sphism commented Nov 30, 2017

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
Copy link
Contributor

@Sogl Sogl commented Dec 1, 2017

  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
Copy link

@DamirPecnik DamirPecnik commented Dec 2, 2017

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!

@mahagr
Copy link
Member

@mahagr mahagr commented Feb 4, 2019

@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
Copy link

@adminnu adminnu commented Feb 5, 2019

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
Copy link

@lufog lufog commented Feb 6, 2019

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

@lufog
Copy link

@lufog lufog commented Feb 24, 2019

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
Copy link
Member

@mahagr mahagr commented Feb 25, 2019

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

@w00fz
Copy link
Member

@w00fz w00fz commented Feb 25, 2019

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
Copy link

@neilpanchal neilpanchal commented Mar 11, 2019

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
Copy link

@mahish mahish commented Mar 11, 2019

  • 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
@Romarain
Copy link

@Romarain Romarain commented Apr 8, 2019

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 :

  • 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.
  • 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 to quickly create a page 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 ! 👍
  • 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 panel admin 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.

@onetrev
Copy link

@onetrev onetrev commented Apr 9, 2019

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
Copy link

@onetrev onetrev commented May 7, 2019

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
Copy link

@wernerjoss wernerjoss commented May 13, 2019

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
Copy link
Member Author

@rhukster rhukster commented May 15, 2019

@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
Copy link

@apidevlab apidevlab commented May 18, 2019

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.

@Romarain
Copy link

@Romarain Romarain commented Jul 7, 2019

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
Copy link

@onetrev onetrev commented Jul 8, 2019

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 :) ....

@Romarain
Copy link

@Romarain Romarain commented Jul 8, 2019

@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
Copy link

@peachp peachp commented Nov 19, 2019

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
Copy link

@bleutzinn bleutzinn commented Nov 19, 2019

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
Copy link
Member Author

@rhukster rhukster commented Nov 19, 2019

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

@drzraf
Copy link
Contributor

@drzraf drzraf commented Dec 7, 2019

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
Copy link

@jrivero jrivero commented Jan 7, 2020

Grav 2 is abandoned?

@rhukster
Copy link
Member Author

@rhukster rhukster commented Jan 7, 2020

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

@CyberSinh
Copy link

@CyberSinh CyberSinh commented May 8, 2020

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

@mahagr
Copy link
Member

@mahagr mahagr commented May 18, 2020

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
Copy link

@sherpadawan sherpadawan commented Aug 25, 2020

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
Copy link

@sherpadawan sherpadawan commented Aug 25, 2020

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.