Roadmap for Grav 2

[rhukster]

We thought that perhaps a GitHub issue would be the best place to solicit the communities ideas and thoughts for features and improvements for the next major release of Grav.

We have some preliminary ideas that I'll outline here, and i'll keep this list updated as we get feedback and ideas from you guys.

1. Collections and Objects

   This is a new system for handling collections and objects that will allow us to perform advanced collection handling as well as complex queries of collections and objects. We intend this to be available in Grav 2 as the go-forward approach, while still keeping the current collection/object system for backwards-compatibility.

2. Caching (PSR-16)

   We are going to rework the caching system using the new PSR-16 approach to provide a more unified and yet more flexible caching system. This will allow us to use our existing caching system, or even mix multiple systems with differing levels of caching as needed.

3. Plugins & Events

   Improvements to the plugins and their events to ensure plugins are only loaded when called.

4. Pages

   We plan on revamping the Page object to refactor and simplify it to improve performance. We also plan on creating a base class that can be used to develop new and specific page types.

5. Content Blocks

   A new mechanism for creating nested HTML blocks with varying levels of caching in different parts of the page. This will allow sophisticated page caching by having items that need to be refreshed more often have a shorter life cache, than those that rarely change.

6. Widgets

   A new simple system to allow reusable logic, rendering, and configuration. This is more akin to a WordPress widget or a Joomla module. These can be rendered at runtime or dynamically via Ajax.

7. Flex Integration

   Integration of some base classes, similar to the FlexDirectory plugin, that allow the easy creation of new plugins with complex CRUD (Create / Remove / Update / Delete) functionality to be used with the Admin plugin.

8. Large Site Support

   Grav is really great at small and medium sized sites, but for large sites with many thousands of pages, it's a case of diminishing returns. We want to utilize some of the collection, caching, and page improvements to provide mechanisms for Grav to handle these larger sites.

9. PHP 8.0 Requirement (UPDATED)

   Grav 2 will require PHP 8.0 (or later) to ensure maximum performance, security, and stability.

NOTE: We are striving to ensure Grav 2 will be 100% compatible with Grav 1.x. If there is anything that is just not going to be compatible, we will come up with a mechanism for migration, or an interim compatibility plugin/configuration option etc.

While we want to keep the list of features and functionality focused to ensure that this release is realized in a timely fashion, we would love to hear your thoughts about the current plans. Also if you have any specific features that you would love to see in Grav 2, please leave a comment below so we can track it.

Thanks!

[jgonyea]

How will backwards compatibility of Grav 1plugins/ themes be handled in Grav 2? Wordpress tries pretty hard to be backwards compatible across major versions, while Drupal typically requires a rewrite of a plugin.

I can see benefits to both approaches.

[ricardo118]

I would possibly also attempt to add some more functionality to themes. Currently some functions do not work in themes that work in plugins. It would be nice to have this.

Moreover maybe having Admin be less of a plugin and more of a part of the system (ie loaded before plugins and then able to be customised via themes or plugins)

[apfrod]

For me the power of grav is the admin blueprints - I'd love to see more focus on reusable and composable blueprints that have stronger bindings to the templates. Maybe even directly derived from template variables.

[MujibAzizi]

Happy to see this!

Something I would like to see added is the support to manage plugins (and its dependencies) directly via composer.

Internally we currently have a small set-up which already sets Grav as a dependency and downloads our custom plugins and its dependencies correctly. However, with the current set-up of Grav and our set-up you're not able to download specific versions of plugins provided by the Grav Repository.

We are working on a Grav Packagist experiment which kind of looks like https://github.com/outlandishideas/wpackagist. But native support (starting 2.0) would be even better.

Related to https://github.com/getgrav/grav/issues/1200 and https://github.com/getgrav/grav/issues/32

[mahagr]

@jgonyea My idea is to have compatibility mode which can be turned on and off -- mostly to allow developers to test their code with strict 2.0 mode. I want all 1.x code to work on upgraded site, but at the same time, I would like to prevent feature creep -- we need to be able to remove old functionality later on.

@ricardo118 Please give some examples of things you would like to see to work.

@apfrod Many of the planned items from above are to improve how admin deals with the content.

@MujibAzizi This is something I've been looking into, too. I want a more centralized way to handle vendor libraries, though composer is quite slow to run (times out) from the web interface and there are other issues, too.

[andrewscofield]

I think it'd be great to see a unified way for plugins/themes to handle ajax/json requests. Not sure if that is what the Flex Integration is since I'm talking about front end things mostly. I've done it myself a couple different ways and have seen other plugins do it in a few different ways.

For example, it would be great if you had a simple newsletter signup or search on a page. But it could also be used to power a React/Vue/Polymer/JS module or entire site if you wanted. Not that this can't be done now, but built in and unified functions and helping with security too would be awesome.

[mahagr]

Oops, clicked on the wrong button. CRUD (Flex Directory integration) is really not the same thing as AJAX, but it is kind of part of the whole picture. Most of the items listed in the first post are related to creating easier and unified interfaces to the content.

[w00fz]

What @apotropaic is describing really is some RESTful/GraphQL API which I agree is something we should also start considering as we approach the items in the list.

It's definitely under our radar though! Especially for allowing other languages/applications to integrate. It does need to be addressed more carefully because it will be a wide-spread and built-in integration touching several Grav's APIs. It will need to be consistent, secure and expandable.

[sphism]

That's funny, I just wrote up an idea that's been buzzing around my head for a while, it'll get lost in slack so I'll add it here.

---

Hey folks, I've not been around here in a while. Did anything happen about the advanced editor? I've been thinking for a while that Grav would be so sweet if there was a desktop app that ran the site for a client on their local machine, then synced their changes via git. It would be great UX and it's pretty straightforward since there's no database to worry about. I think it would be a killer feature that other CMS's would find hard to match... tablet and phone apps too.

[hexplor]

Holly molly looking so much for Large Site Support. Besides would love further improvements into admin blueprints ie. more compact list fields collection. It became really cluttered when using nested arrays.

P.S. You guys are great.

[sphism]

Large site support

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

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

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

[hexplor]

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

[sphism]

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

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

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

[MujibAzizi]

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

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

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

[paulmassen]

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

Menu manager

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

Template editor

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

[boettges]

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

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

[tourtools]

I would like to see also:

• better multisite management
• wysiwyg editor integration

[coder4life]

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

1. Collections and Objects

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

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

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

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

2. Caching (PSR-15)

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

3. Plugins & Events

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

4. Pages

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

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

5. Content Blocks

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

6. Widgets

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

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

7. Flex Integration

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

8. Large Site Support

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

9. PHP 7 Requirement

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

[rhukster]

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

[ghost]

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

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

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

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

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

[rhukster]

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

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

[ghost]

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

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

[sphism]

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

[Sogl]

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

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

[DamirPecnik]

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

[Moonlight63]

I'm so excited for Grav2. I have a few things I would like to see implemented, though they relate more to the admin more than anything. More complex user and group management features from the likes of the user-manager plugin and even my own page-ownership plugin (that I have neglected :P ). One more recent plugin that I made for my own use was adding a new blueprint field for admin that creates a select box (or an array of them), then based on what option you have selected it AJax's a different field type set by the blueprint. It originally started out as a way to add custom css to a modular page section (for example: you want to add a background color, it gives you a colorpicker, but if you want to add a margin it gives you a number or text field), and then I started adapting to create a form builder (uh oh, not that request again). It's still very much an experiment, but it "works." I went ahead and uploaded it to a repo so you can see what I mean: https://github.com/Moonlight63/grav-plugin-modular-section (relevant files being in /admin and possible usage case in blueprints/modular/section.yaml) Having something like this native that can swap the field (or fields?) being displayed has always felt like a major missing option when creating new templates or themes.

I also second possibly the ability to edit twig files from admin, but I see how that could be difficult. A better page manager would also be very welcome. I currently have a site where I must load a large number of assets into a particular pages sub-folder so they can be accessed by my twig template. The major problem being that grav thinks they are un-routeable pages and the admin takes a good bit to load them all in. Although, this would likely not be an issue with FlexDirectory style editing, aaaaand it's pretty much my fault for being lazy and not creating some cdn for the assets.

Overall better events and hooks will always be welcome, especially for admin plugins.

I am currently in the middle of creating a few super flexible and customizable gantry themes because I have found that I like editing gantry layouts way more than editing modular page sections. Then my only major hurdle is the fact that I can't just add a new section to a gantry layout from within the editor, and unfortunately the gantry editor doesn't seem as easy to extend as grav. I guess what I would really love to see is a "gantry-style" editor for modular pages, where a top-level modular page is like a layout, sub-pages are layout sections, and sub-sub-pages are like particles... (I'm now wondering how hard of a plugin that would be to make....... crap...)

Well, I din't mean for that to turn into a ramble, honest! When I think about 'what can be added to grav?' I get lost for hours... It's a problem...pls send help...

[OleVik]

A couple of cents:

1. Collections and Objects:

A subset goal of this should be exhaustive abstraction of data, related to previous discussions of API as noted above. Given a decent systems for handling roles and permissions, no data should be inaccessible to a RESTful/GraphQL API - though, @w00fz, I would side on shipping it as a plugin rather than fully integrated, that's a worthwhile level of security. Would also help with "7. Flex Integration".

2. Caching (PSR-15):

Depending on how this progresses, focusing on partial and incremental caching would be important to increase performance for systems with thousands of pages. Also assists in solving "8. Large Site Support".

9. PHP 7 Requirement:

Migration is important, but interim compatibility does not strike me as worth the time to implement. At the time of writing there are 221 plugins, several of which are unmaintained, currently incompatible, or entirely abandoned without requests for taking them over. To reiterate an older discussion, dependencies need to evolve in the direction @MujibAzizi and @mahagr mentions.

When proper Semantic Versioning is not in place across the extensions-ecosystem, it is inherently difficult to verify that a plugin will work with the current major/minor/patch-version of Core. Testing requires downloading, installing, and running the extensions - which is not a burden that should be placed on end-users. Rather, plugin- and theme-developers should be required to explicitly declare dependencies Composer-style upon release, or the GPM should at least compare release-dates to warn of out-of-date plugins.

A DevTools-command to bump version and declare ecosystem would not go amiss, to greatly simplify the task. Striving for backwards-compatibility across the board will take a lot of time and effort that would be better spent elsewhere. If developers want their extensions to remain in use, the onus is on them to rewrite and test to ensure compatibility with the system they are extending. As such the Abandoned Resource Protocol should probably have an equivalent for removal, when a plugin is unmaintained but locks up an extension-name that is explanatory.

[jimblue]

1. Be able to fetch data trough an API for modern javascript framework such as Vue.js or React.js. (GraphQL please 😄)

2. Change images manipulation library to imagine.

3. WYSIWYG HTML Editor integration (could be the very nice quill).

4. Add Twig extension in Grav core (a must have for date and currency)

5. Media management from admin (maybe one medias.yaml file per page with medias order and medias metadata)

6. Add a default page settings to change settings for all language at once (e.g. media order, children order, sitemap settings, etc...)

[Quanatee]

I agree with @OleVik on his migration/compatibility concerns. I would advocate a stable final Grav 1 release with "limited support" for those who may have a fairly customized version of Grav 1, like myself and may not prioritze migrating to Grav 2 for some time.

This is especially since admin plugin is a optional (I don't use it), the lifetime of Grav 1 can be quite long.

Wishlist:

Single Page Application (SPA) Implementation Not expecting this to be done, but some form of development and documentation to easily achieve SPA for Grav would be amazing and makes it easier to port to IOS or Android as an app.

[jgonyea]

Drupal has a batch api to break up large requests into multiple smaller ones to avoid timeout/ memory issues. It'd be nice to see a similar system in Grav.

[stephenvoisey]

Tiny one, but Markdown support for definition lists would be appreciated. Normally looks like this:

Sausage
: A meat based food product typically filled with pork if you're lucky

[stephenvoisey]

Another thought: Live page editing or in page editing of content. Simpla tried to roll this out as a cloud based idea, but sadly had to give up on that, although they have created an open version of their tech. https://www.simplajs.org

[librarianmage]

@stephenvoisey Would https://michelf.ca/projects/php-markdown/extra/#def-list meet your needs for Markdown definition lists? If so, you can enable that by enabling Markdown Extra in Grav.

[circa-0]

A simpler blog interface would be nice. Something that would allow as little learning curve as possible. Right now you can do it fairly easily, but for a normal end user that may not be super computer savvy, it may seem complex. Skipping that first step in naming the page and folder would help with that. You could have it detect those by the title they make the page. And make it a blog item automatically if you're making the page as a child of a blog.

On that same note, a built in WYSIWYG editor to replace Markdown would also be great. There's a plugin for it, which is great. But I think it should be the default option. I think this is one thing that would drive people away from using Grav over other CMSes.

[stephenvoisey]

@MathWhiz Sorry for the delay, thanks, that looks perfect. I missed the Markdown Extra comment in the documentation (It needs it's own heading) many thanks!

[manuel-84]

@rhukster you said "to perform advanced collection handling as well as complex queries of collections and objects", since Grav is using parts from Doctrine, I hope that in next releases will be easier for developers to build not only websites but also web apps handling complex data with relationships

I would like to have the possibility to add template-specific scss files (i.e. like we do with templates/mypage.html.twig we can have scss/templates/mypage.scss) that will be automatically compiled and added to the template assets

I would like to add new languages (like sardinian "sc") without editing the core

[NaorPenso]

I would like to request 2 features 😄 1) Page template creator plugin - that would create a page template from a drag-n-drop interface 2) Create default pages, which can be suppressed by local pages. What i mean by default vs. local? Think about a pre-built Grav instance with all of my KB articles - they will be the default pages within the system. in case anyone alters the pages they will be saved in a “shadow structure” that will be localized to that Grav instance. when the user lists the files, if there is any default file that was superseded by a local file, the local file will be the one pointed at.

This way, if i release a new version of the KB with new pages, they will only replace the default pages and not run over the changes that others might have made.

As a real-life example of this use-case being used by others, you can look as Splunk (big data analytics platform). Splunk enables building “apps” that provide further analytics. in case someone released an app, you can edit it using the “local” configurations and analytics. that way when the app owner releases a new version of the application, it does not run over any alterations made by the user.

Thanks! Naor

[stephenvoisey]

One of Grav's greatest features is the asset manager. But having just spent a couple of days doing SEO / Performance optimisations, I've sadly had to bypass a lot of what it offers.

The existing pipeline feature almost take care of this, because, while you can set a script to defer, to the best of my knowledge, you can't set the pipeline script to 'defer'. It's just output as a standard script line, albeit compiled by Grav nicely.

For now, I've had to manually add the scripts to a deferred.js script manually, which negates the really nice pipeline ability and would have allowed me to keep the scripts separated in a modular fashion.

The ability to defer CSS would be great, but its far more complicated matter when it comes to above the fold.

I don't expect Grav to handle the critical above the fold magic, although it would be great if some of the existing tech for this is added to Grav as a plugin. It would be nice however, for the option to exist to set a CSS asset to be deferred, and the relevant Javascript added by asset manager automatically.

[ghost]

I really love Grav for its simplicity, nearly all that what makes enterprise-scaled, database driven and often over engineered »full grown« CMS so painful to use, just isn't there in grav. I really appreciate the roadmap as given by @rhukster and I think making it easier to reuse exiting functionality by better base Classes and easier setup of CRUD plugins is a very good Idea. There is a whole lot of good Code in the Framework but it is sometimes difficult to reuse it, since it requires a lot of reading source code. I have two points on my wishlist: 1. Better documentation, especially for plugins that integrate into the admin panel. 2. A clean API for the routing, such that it is possible to use some more advanced route configuration like the routing system in Symfony. That way It would be much easier to make the thing a bit more »RESTful(ly)«. Listing and debugging route should be as easy as the setup of a new one, of a given method, as well as returning proper responses.

[mahagr]

@schmi85 Symfony routes are something I really much would like to take a look into, especially after they have finally fixed the performance in Symfony 4.1. To support this, we would need to raise minimum PHP version to 7.1.3, though...

[Moonlight63]

In my opinion, there is no reason in the world to not require php 7 at this point. Anyone who is still using php 5 is simply irresponsible from a security standpoint. Just my 2 cents.

On Mon, Mar 12, 2018 at 2:39 AM, Matias Griese notifications@github.com wrote:

@schmi85 https://github.com/schmi85 Symfony routes are something I really much would like to take a look into, especially after they have finally fixed the performance in Symfony 4.1. To support this, we would need to raise minimum PHP version to 7.1.3, though...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/getgrav/grav/issues/1767#issuecomment-372247649, or mute the thread https://github.com/notifications/unsubscribe-auth/AHK37ZKwIFie0TZK3E3VrC1mTp3zJzKmks5tdkJfgaJpZM4QtlGu .

[jgonyea]

@moonlight63, while it is true that the upstream packages are not supported, companies like Red Hat are applying security updates to the older versions of their packages. CentOS 6 still defaults to 5.3.3, but it does include later patches. I don't think one can summarily say that using php 5 is irresponsible.

[Moonlight63]

I am more talking about hosts that don't support it AT ALL. I've seen quite a few web hosts that until very recently just said "No, we don't want it." Obviously people will have to use it for compatibility reasons. It's simply my belief that php packages like grav should support or require newer versions of php as soon as possible as a security measure, even if it forces hosts to update their systems as well. Quite frankly, it is a hosts responsibility to keep their software up to date to avoid security vulnerabilities. Mission critical web apps are harder to update and take more time. That said, I know of no super large mission critical sites that are running on grav, as I would imagine a site like that would require something faster than a flat-file system. Most users of grav are running blogs or documentation wikis, and they can afford to wait for an upgrade. If I am wrong on this please let me know. If you are making something new, why wouldn't you want to use the latest and greatest available? Being up to date on security vulnerabilities is just a standard I hold my self to, I don't expect that everyone will follow that, even if it is the smart thing to do.

I didn't necessarily mean to make such a broad statement before. Every situation is different.

On Mon, Mar 12, 2018 at 5:08 PM, Jeremy Gonyea notifications@github.com wrote:

@Moonlight63 https://github.com/moonlight63, while it is true that the upstream packages are not supported, companies like Red Hat are applying security updates to the older versions of their packages. CentOS 6 still defaults to 5.3.3, but it does include later patches. I don't think one can summarily say that using php 5 is irresponsible.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/getgrav/grav/issues/1767#issuecomment-372502958, or mute the thread https://github.com/notifications/unsubscribe-auth/AHK37fcpEi8n7g7KsvCLdtXjMVESrqPwks5tdw3igaJpZM4QtlGu .

[l3aconator]

Massive +1 for larger sites

[jza34]

I use multisite setup feature of Grav, and so each site folder has its own plugins folder. So, unfortunately, I cannot use bin/gpm CLI to update and manage plugins for each site folder. I try to set a 'plugin' stream but it has its own darkside...

I wish CLI could manage plugins and themes for multiste setup

Thanks team!

[avxkim]

1. Provide better page collections, so we can do everything, just like with SQL queries.
2. Provide native smart views counter.
3. Improve performance for thousands of pages.

What's ETA on 2.0?

[tim-bradley]

As a simple hobby user, what I'd like to see built into the core:

1. Images > Improve url output for Media Actions Generate urls with (or swap generated urls with) an md5 hashed fingerprints instead of current non-semantic urls: For example, image.jpg?cropResize in page folder gets output as: path/to/page/image.1234khk234.jpg Instead of: really/bad/semantic/url/for/lotsofcrapnumbersandletters-image.jpg

2. Images > Easier sitewide image rules Similarly, easier sitewide defaults rules for creation of multiple versions of uploaded images with declared output urls, and automatic referencing when using the ![Responsive Image] format. For example, something like:

   
   types:
   defaults:
   type: jpg
   thumb: media/thumb.png
   mime: application/octet-stream
   image: 
     filters:
       defaults:
         thumbnail:
           cropResize: 100,100
           dpi: 72
           path: [images]          <- This and ...
           prefix: -'thumbnail' <-- this makes path `assets/images/thumbnail-image.jpg`
           responsive: false <-- not included in responsive markdown
           enableProgressive
         small:
           cropResize: 400,200
           dpi: 96
          path: [page]          <-- This and ...
           suffix: '-400x200' <-- this makes 'path/to/page/image--400x200.jpg'
           responsive: true  <-- included with ![Responsive Image] markdown
           enableProgressive
         medium:
           cropResize: 1200,600
           dpi: 150
           suffix: '-1200x600'
           enableProgressive
           responsive: true
           outputs: [webp,jpg] <--this would make type versions available in srcset too

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

[omiras]

Thumbs up regarding the WYSWYG editor. I am totally in love with Grav CMS, but the only reason I am not considering to use it for my customers is the default editor.

As commented before, I'm glad that we have a plugin for that, but I think it should be a configurable built-in option.

By the way, thank you very much for all the good work :thumbsup:..

[hughbris]

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

A few comments about this suggestion from @tim-bradley:

• I am having a lot of trouble imagining which sort of site is simple enough to be static, yet noticeably slowed down by Grav
• I don't support this in Grav core. There is a plugin called Blackhole (which I haven't had much luck with) that starts down this road. Less common functionality should be kept out of Grav core if possible so that core can stay lean and fast.

Don't get me wrong, this discussion is very welcome, however :)

[hughbris]

I have a few plugins I've "hacked" which for different reasons have not been integrated into release repositories. In some cases, the releases are pending.

It means I have to be careful when updating plugins not to upgrade those plugins, or I'll lose my local changes. It can get messy and there's nothing much protecting me except backups.

It would be a load off my maintainer mind if the gpm/updater referred to some sort of checksum for each installed plugin and check this, so that it can warn before applying updates. I'm pretty sure the mainstream CMSs do this, so their methods could be co-opted.

Another option might be to implement plugin inheritance like themes??