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 · 79 comments

Comments

Projects
None yet
@rhukster
Member

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

This comment has been minimized.

Show comment
Hide comment
@jgonyea

jgonyea Nov 28, 2017

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@ricardo118

ricardo118 Nov 28, 2017

Contributor

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)

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@apfrod

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

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

This comment has been minimized.

Show comment
Hide comment
@MujibAzizi

MujibAzizi Nov 28, 2017

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@mahagr

mahagr Nov 28, 2017

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@andrewscofield

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

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

This comment has been minimized.

Show comment
Hide comment
@mahagr

mahagr Nov 28, 2017

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@w00fz

w00fz Nov 28, 2017

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@sphism

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

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

This comment has been minimized.

Show comment
Hide comment
@hexplor

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

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

This comment has been minimized.

Show comment
Hide comment
@sphism

sphism 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

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

This comment has been minimized.

Show comment
Hide comment
@hexplor

hexplor Nov 28, 2017

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

hexplor commented Nov 28, 2017

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

@sphism

This comment has been minimized.

Show comment
Hide comment
@sphism

sphism 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

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

This comment has been minimized.

Show comment
Hide comment
@MujibAzizi

MujibAzizi Nov 28, 2017

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@paulmassen

paulmassen Nov 29, 2017

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@boettges

boettges 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 👍

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

This comment has been minimized.

Show comment
Hide comment
@tourtools

tourtools Nov 29, 2017

I would like to see also:

  • better multisite management
  • wysiwyg editor integration

tourtools commented Nov 29, 2017

I would like to see also:

  • better multisite management
  • wysiwyg editor integration
@coder4life

This comment has been minimized.

Show comment
Hide comment
@coder4life

coder4life Nov 29, 2017

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@rhukster

rhukster Nov 30, 2017

Member

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

Member

rhukster commented Nov 30, 2017

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

@cpfeifer

This comment has been minimized.

Show comment
Hide comment
@cpfeifer

cpfeifer 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 😊

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

This comment has been minimized.

Show comment
Hide comment
@rhukster

rhukster Nov 30, 2017

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@cpfeifer

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

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

This comment has been minimized.

Show comment
Hide comment
@sphism

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

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

This comment has been minimized.

Show comment
Hide comment
@Sogl

Sogl Dec 1, 2017

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@DamirPecnik

DamirPecnik 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!

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!

@tim-bradley

This comment has been minimized.

Show comment
Hide comment
@tim-bradley

tim-bradley Apr 11, 2018

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

tim-bradley commented Apr 11, 2018

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

@heihachi88

This comment has been minimized.

Show comment
Hide comment
@heihachi88

heihachi88 Apr 11, 2018

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

heihachi88 commented Apr 11, 2018

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

This comment has been minimized.

Show comment
Hide comment
@tim-bradley

tim-bradley Apr 11, 2018

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.

tim-bradley commented Apr 11, 2018

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.

@heihachi88

This comment has been minimized.

Show comment
Hide comment
@heihachi88

heihachi88 Apr 11, 2018

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

heihachi88 commented Apr 11, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@w00fz

w00fz Apr 11, 2018

Member

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.

Member

w00fz commented Apr 11, 2018

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

This comment has been minimized.

Show comment
Hide comment
@tim-bradley

tim-bradley Apr 11, 2018

@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

tim-bradley commented Apr 11, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@hughbris

hughbris Apr 11, 2018

Contributor

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

Contributor

hughbris commented Apr 11, 2018

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

This comment has been minimized.

Show comment
Hide comment
@koreos

koreos Apr 11, 2018

  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 commented Apr 11, 2018

  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

This comment has been minimized.

Show comment
Hide comment
@koreos

koreos Apr 11, 2018

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.

koreos commented Apr 11, 2018

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

This comment has been minimized.

Show comment
Hide comment
@mahagr

mahagr Apr 14, 2018

Member

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

Member

mahagr commented Apr 14, 2018

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

This comment has been minimized.

Show comment
Hide comment
@jlehtinen

jlehtinen Apr 27, 2018

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.

jlehtinen commented Apr 27, 2018

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

This comment has been minimized.

Show comment
Hide comment
@mahagr

mahagr Apr 30, 2018

Member

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

Member

mahagr commented Apr 30, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@jlehtinen

jlehtinen Apr 30, 2018

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.

jlehtinen commented Apr 30, 2018

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

This comment has been minimized.

Show comment
Hide comment
@CSixtyFour

CSixtyFour May 4, 2018

Contributor

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.

Contributor

CSixtyFour commented May 4, 2018

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

This comment has been minimized.

Show comment
Hide comment
@CSixtyFour

CSixtyFour May 8, 2018

Contributor

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.

Contributor

CSixtyFour commented May 8, 2018

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

This comment has been minimized.

Show comment
Hide comment
@drnasin

drnasin May 10, 2018

Contributor

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

Contributor

drnasin commented May 10, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@CSixtyFour

CSixtyFour May 10, 2018

Contributor

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

Contributor

CSixtyFour commented May 10, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@drnasin

drnasin May 22, 2018

Contributor

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.

Contributor

drnasin commented May 22, 2018

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

This comment has been minimized.

Show comment
Hide comment
@drnasin

drnasin May 22, 2018

Contributor

@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

Contributor

drnasin commented May 22, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@CSixtyFour

CSixtyFour May 22, 2018

Contributor

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

Contributor

CSixtyFour commented May 22, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@coolemur

coolemur May 29, 2018

GraphQL API would be a game changer!

coolemur commented May 29, 2018

GraphQL API would be a game changer!

@leotiger

This comment has been minimized.

Show comment
Hide comment
@leotiger

leotiger Jul 10, 2018

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

leotiger commented Jul 10, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@jlehtinen

jlehtinen Aug 2, 2018

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?

jlehtinen commented Aug 2, 2018

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

This comment has been minimized.

Show comment
Hide comment
@hughbris

hughbris Aug 3, 2018

Contributor

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

Contributor

hughbris commented Aug 3, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@mahagr

mahagr Aug 3, 2018

Member

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.

Member

mahagr commented Aug 3, 2018

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

This comment has been minimized.

Show comment
Hide comment
@hughbris

hughbris Aug 3, 2018

Contributor

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.

Contributor

hughbris commented Aug 3, 2018

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

This comment has been minimized.

Show comment
Hide comment
@mahagr

mahagr Aug 3, 2018

Member

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

Member

mahagr commented Aug 3, 2018

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

This comment has been minimized.

Show comment
Hide comment
@leotiger

leotiger Aug 8, 2018

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.

leotiger commented Aug 8, 2018

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

This comment has been minimized.

Show comment
Hide comment
@jza34

jza34 Aug 21, 2018

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!

jza34 commented Aug 21, 2018

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment