How enable function NetFx35

Hi. How i can enabling function NetFx35 from this script?

This function has been removed for now.

For now you can use W10UI to integrated windows updates + .NET Framework 3.5, then use Optimize-Offline on your new updated image.

This will be added to the next script update and will be able to be set in the config file for the -Additional switch just like how drivers, registry templates, etc. can be integrated now. It will require an ISO to be used as the source image in order to use the .NET Framework 3 payload .cab packages.

If use new version with enable NetFx3 on ini file and Registry Tweaks then show this error:
Applying Optimizations to the Offline Registry Hives.
Applying Answer File to the Image.
Applying Registry Templates to the Image.
Get-ChildItem : Cannot find path 'D:\sources\' because it does not exist.
At D:\Tmp\3_2_6_3\Optimize-Offline.ps1:1709 char:157
+ ... oved' -and (Get-ChildItem -Path "$ISOMedia\sources\sxs" -Recurse -Fil ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (D:\sources\:String) [Get-ChildItem], ItemNotFoundException
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

Cleaning-up the Start Menu Layout.
Post-Optimization Image Health State: [Healthy]
Saving and Dismounting Windows 10 Pro

My profile is extracted ISO to folder D:\Tmp\DVD and Start.cmd contain path to directly wim in sources folder.
I use this method for: Extracted original ISO form Microsoft servers and download latest image (with updates) in ESD and convert to WIM format same build version (1903). And replacing extracted iso install.wim only. After this apply your script.
DrEmpiricism, do you can change method for detecting ISO structuring? Or how i can solving this problem?

It's returning an error because the source image you're using is a WIM and not an ISO. As the Changelog states, in order for NetFx3 to be integrated, an ISO needs to be used as the source image in order for Optimize-Offline to set up the appropriate variables at the start of the script. Even though you're using an already extracted ISO, the source image being passed to the script is still a WIM file so the script never sets up those variables specific to ISO source images.
Instead of extracting the ISO yourself and using the WIM as the source image, just use the ISO itself and let the script do the extracting and such. There's no need for you to extract the ISO before running the script as the script will handle the extraction, integration and new ISO creation on its own.
However that section in the script where it checks for the NetFx3 payload packages should simply bypass its integration rather than returning an error and I will change that.

If I already integrated NetFx3 with W10UI, no need to enable the option in your script I think. Is this correct?

Like Said, if you point the script to the ISO like in my Start.cmd it'll integrate the NetFx3.
@ECHO OFF
CD /D "%~dp0"

REM After setting the appropriate variables and switches, run this script as an administrator to quickly call Optimize-Offline.
REM A list of all available variables and switches can be found on Optimize-Offline's GitHub Repository.

REM Set the Optimize-Offline Source Path variable.
SET "SourcePath=D:\1\Enterprise.iso"

NET SESSION >NUL 2>&1
IF %ERRORLEVEL% NEQ 0 (
    ECHO Permission denied. This script must be run as an Administrator.
    ECHO:
    PAUSE
    EXIT
) ELSE (
    ECHO Running as Administrator.
    TIMEOUT /T 2 >NUL
    PowerShell.exe -NoProfile -ExecutionPolicy Bypass -File .\Optimize-Offline.ps1 -SourcePath "%SourcePath%" -WindowsApps "Select" -SystemApps -Packages -Features -Registry -Win32Calc -Additional -ISO
)
PAUSE
EXIT


Completely recreate the dashboard and it’s API.

I'm going to separate the API on the shards to park, I'd like to see @GodderE2D design the admin dashboard since I can only make good-looking "landing pages".


updated the login page

solved the issue #126
i changed the background of the login page.

and i also added a functionality that was missing from the log in page i.e. the file of sign up page was not attached to it.

i have updated the login page

@mansiruhil13 mam please the label "gssoc-extd" to "gssoc-ext" so our valuable contibution can count

@mansiruhil13 mam do change the label name from "gssoc-extd" to "gssoc-ext" so that our valuable contribution can count


Support for IE 6/7/8

jQuery 2.x has the same API as jQuery 1.x, but does not support Internet Explorer 6, 7, or 8.

In spare moment we should find a machine with old IE, switch jquery to 1.x and see if it works without any other change. If so, I think it would not cost us any work to support the retarded browser.

I agree, it is a good thing not to support IE at all... xD

Ok, this will not work: we are using IFrame API for YouTube and:

The end user must be using a browser that supports the HTML5 postMessage feature. Most modern browsers support postMessage, though Internet Explorer 7 does not support it.

Nvm then ;-)

Everybody has moments of weakness... ;D


Queries and ideas: whether rascaline.torch.LodeSphericalExpansion() supports GPUs, and the format of the output aligned with e3nn

Idea: the format of the output of rascaline.torch.LodeSphericalExpansion() is aligned with e3nn:
I am interested in combining rascaline.torch.LodeSphericalExpansion() with e3nn(https://github.com/e3nn/e3nn). Both methods are based on spherical harmonics and satisfy the equivariant property. However, inconsistencies in output formats arise, especially when max_radial is greater than 1.
Here is the output format of e3nn:
Irreps("1x0e + 1x1o + 1x0e + 1x1o")

This is another example of e3nn:
Irreps("2x0e + 2x1o ")

Aligning the output formats, particularly for higher-order equivariant models, would enhance compatibility between rascaline and e3nn frameworks.  Your assistance in resolving these issues would be highly beneficial, not only for my use case but also for encouraging more users to seamlessly combine these powerful frameworks.
Thank you for your consideration.

I split the GPU support discussion in a separate issue (#271).

Regarding the output format: rascaline uses metatensor to store it's output, the main reason for this is that e3nn-style storage format is very wasteful, and stores a lot of explicit zeros (all the out-of-diagonal blocks in your plots). These extra explicit zeros add up and fill the RAM/GPU memory, limiting what one can do with some given hardware.
For this reason, it is very unlikely we will change rascaline output format, but we can and probably should provide some ways to adapt between metatensor and e3nn. We would need two functions for this:
from metatensor import TensorMap

def metatentor_to_e3nn(tensor: TensorMap) -> (Irreps, torch.Tensor):
    ...

def e3nn_to_metatensor(irreps: Irreps, data: torch.Tensor) -> TensorMap:
    ...

I'm not fully familiar with e3nn, but is the 2x in 2x1o typically used to indicate 2 radial channels? If so, doing the conversions above should be fairly easy! Also, how does e3nn represents different samples/batches? As an extra first dimension in the tensor, the plots above representing the second dimension?
For reference, metatensor format represent the 0o, 1o, ... part as "keys" of the TensorMap (named spherical_harmonics_l in rascaline), and stores the radial channels as "properties" of the different blocks in the TensorMap.

to get the Wigner-D matrix of rascaline as follows(the rotations matrix are randomly generated and do not correspond to the values in the image above).

Could you share the full script you used to generate these plots?

For the lode set by the descriptors of the two radial channels and the highest 1st order spherical harmonic function, I surmised based on Wigner-D that its output format should be ...

I think (but I need to check with the script you used) that this is an artefact of how you constructed a single matrix from the block structure of metatensor TensorMap. For example, the code you initially shared
lrvp = lr.keys_to_samples("species_center")
lrvp = lrvp.components_to_properties(["spherical_harmonics_m"])
lrvp = lrvp.keys_to_properties(["species_neighbor", "spherical_harmonics_l"])

Will mix species_neighbor and spherical_harmonics_m which you typically don't want. More generally, metatensor/rascaline store the data for different λ separate, in 3D tensors with the shape [atoms, μ, radial-channels], and components_to_properties just reshape that to [atoms, μ * radial-channels], which would explain the pattern you see in the Wigner-D matrix.
You can triple check this by looking at the metadata attached to the different axes of the array: lrvp.block().samples for the first dimension; lrvp.block().properties for the last dimension and lrvp.block().components for any middle dimension.

Also, e3nn's default Euler angle convention is changed from the standard ZYZ to YXY, and for first-order spherical harmonic functions, the component ordering is [x,y,z] instead of [y,z,x]; https://docs.e3nn.org/en/latest/guide/change_of_basis.html


What video formats are supported by this plugin?

I found that following file formats are working well.
3g2 - OK
3gp - OK
mp4 - OK
m4v - OK
But I found issues while playing following file formats.
mkv - slider is not working
avi - unable to open/play
vob - unable to open/play
flv - video is not visible
wmv - video is not visible

.ts (MPEG-2) tested over streaming and working.

This is a question of which formats are supported by your device and its OS not the plugin itself

rtsp - OK

FLV works?


Use new array syntax in docs

I see this library supports legacy array syntax, but there's no need to use it in docs - it will allow to copy/paste examples easier into your code as well

I cherry picked your pull request into https://github.com/handcraftedinthealps/goodby-csv.
The fork is registered as handcraftedinthealps/goodby-csv in packagist and released as 1.4.0 Version. Feel free to use the fork.

Thanks! Looks like this package isn't maintained since 26 Oct 2018 :/

Yes thats why we decided to fork it, I already did not have any luck in 2018 to get in contact with a maintainer of the package.


Gitcoin Bounty - Testing and Deploying and XRC-721 Token Using Truffle

Judging Criteria
All submissions must contain clear and concise information with explicit instruction and images describing each step required to execute the process. An accompanying video in addition to the written content is highly desired.
All submissions will be put through an industry standard plagiarism detection tool to ensure that all submissions are the work and ideas of the person submitting for the bounty. If the plagiarism tools flags your submission you will be disqualified from participation in the bounty.
You will be provided with resources (if available) as an aid to help you get started. The sole act of submitting content for the bounty does not automatically qualify you for the bounty. Our team will review all submissions and will choose the submission whose content best fits the needs and requirements of the bounty.
Only one participant will be selected as the winner for the bounty, and they will be notified within 7 working days after the bounty has ended.
Description
Amount of Bounty
Grant Sponsor: XDC Foundation. All monies paid will be in XDC.
What will you be creating?
You will be creating how to documentation for the XDC Network. Some documentation has already been created, and you will read through it to ensure it works as intended, reads clearly or if it needs better clarification, then make those changes. Those items without documentation will be created from scratch.  Documentation will have images that describe or represents what's being done or described in your tutorial.
Details
Creating, Deploying, and Interacting with an XRC721 token using Truffle
Truffle is a blockchain development environment, which you can use to create and test smart contracts by levering an Ethereum Virtual Machine.
What you will learn
In this tutorial, you will learn how to set up Truffle and use it to build, test and deploy a XRC721 Token on both the XDC Network mainnet and XDC Apothem testnet.
What you will do

Install and setup Truffle
Create an XRC721 token
Compile the XRC721 token
Deploy the XRC721 token
Interact with the XRC721 token

Setting up the development environment

Creating a project (with images)
Checking the XRC721 token (sample code with images preferred)
Setting up the XRC721 token contract
Compiling the XRC721 token contract
Testing the XRC721 token contract (where is the contract going to be tested...a link will be great)

Deploying an XRC721 token contract on the XDC Network

Add funds to wallet using Apothem Faucet
Walk user through deployment process with screenshots
Validate smart contract deployment via Apothem network explorer

Total Prize of Bounty
Total sum of up to $500.00 USD worth of XDC for this event, reward amount assigned at judge's discretion.
Further Details
This event will be an ongoing collaboration to create "how to" documentation for the XDC Network. All documentation will be open source and uploaded here:
https://github.com/XDC-Community/docs/tree/main/how-to/XRC721/Truffle
Resources
These are some of the resources you have available to you where you will find the necessary information to complete your submission.
Apothem Test Network
https://www.apothem.network/
Apothem Faucet
https://faucet.apothem.network/
Truffle
https://trufflesuite.com/
Node.js v8+ LTS and npm
https://nodejs.org/en/
XRC721 Tokens
https://medium.com/yodaplus/how-to-implement-xrc721-in-xdc-network-d9a2166a0ed9

Is this bounty still available? happy to work on it @WalterBlueu


Alpine Linux Support

Description
This PR adds Alpine to the list of distro vendors and also adds a logo icon for it.
Type of Change

Non breaking change ('update', 'change')

Note to Reviewers
To test: Create a new Linode instance and ensure that the Alpine logo correctly appears next to its name in the list of distributions.


[UWP] Add role property to actions

Related Issue
Progress towards #8041
Description
Added a new property role to actions. The new property will allow the card author to specify an aria role for a buttons and improve their card's accessibility.
Proposal can be found here: https://github.com/microsoft/AdaptiveCards/issues/8041#issuecomment-1438924387
Sample Card
Added a sample card for v1.6
How Verified
Verified manually in the Visualizer with Narrator.
Microsoft Reviewers: Open in CodeFlow

@jwoo-msft @almedina-ms Do we need any changes for Android or iOS here?


Automatic Operator Conversion Enhancement

What would you like to be added:
automatic operator conversion in compression.pytorch.speedup
Why is this needed:
nni needs to call these functions to understand the model.
problems when doing it manually:

The arguments can only be fetched as a argument list
The function uses a lot of star(*) syntax (Keyword-Only Arguments, PEP 3102), both positional argument and keyword-only argument, but the argument list cannot be used to distinguish positional argument and keyword-only argument
The function is overloaded, and the number of parameters in multiple versions of the same function may be the same, so it is difficult to distinguish overloaded situations only by the number.
Because it is a build-in, inspect.getfullargspec and other methods in inspect module cannot be used to get reflection information.
There are more than 2000 functions including the overloaded functions, which is hard to be operated by manual adaptation.

Without this feature, how does current nni work：
manual adaptation and conversion
Components that may involve changes:
only jit_translate.py in common/compression/pytorch/speedup/
Brief description of your proposal if any:

Automatic conversion

There is a schema information in jit node which can parse out positional argument and keyword-only argument.
Then we can automatic wrap arguments, keywords, and the function up to an adapted function.
Tested the automatic conversions of torch.sum, torch.unsqueeze, and torch.flatten OK.

Unresolved issues

Check schema syntax in multiple versions of pytorch and whether the syntax is stable.

The schema syntax is different from python's or c++'s.
I did't find the syntax document in pytorch documentation.
When pytorch compiles, it will dynamically generate schema informations from c++ functions.

For all the given schemas, see if they can correspond to the compiled pytorch functions.
For all the given schemas, try to parse one by one, and count the number that cannot be parsed.

@Louis-J /@ultmaster - had this work completed in 2.9?


add support for thumbv7a-pc-windows-msvc

Hello
This is Chandler from Microsoft working on enabling ARM32 for Azure IoTEdge, which has a module is written in rust, we have already enabled ARM32 in rust tool chain (https://github.com/rust-lang/rust/pull/53621), although there is some missing dependency in LLVM so ARM is not officially supported yet in official release, we're using a private version of cargo and rustc to compile Azure IoTEdge in ARM already, check out https://github.com/Azure/iotedge/blob/master/edgelet/build/windows/build.ps1#L30. Besides addressing ARM in rust, we also need to update a few crates to support ARM, e.g. backtrace-rs, winapi, cmake-rs, etc..
This is a simple change inside function visual_studio_generator to unblock this new build string. Please take a look.
Thanks
Chandler

👍


Adding mergify.yml for automatic merge on approval

Adding mergify.yml for automatic merge on approval

Codecov Report

Merging #358 (fedfd6c) into main (30c21da) will increase coverage by 1.50%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #358      +/-   ##
==========================================
+ Coverage   27.67%   29.18%   +1.50%
==========================================
  Files          30       30
  Lines        2775     2820      +45
==========================================
+ Hits          768      823      +55
+ Misses       1924     1911      -13
- Partials       83       86       +3

Impacted Files
Coverage Δ

pkg/routes/thirdpartyrepo.go
20.26% <0.00%> (-2.05%)
:arrow_down:

pkg/services/updates.go
35.12% <0.00%> (-0.09%)
:arrow_down:

pkg/services/errors.go
0.00% <0.00%> (ø)

pkg/services/thirdpartyrepo.go
0.00% <0.00%> (ø)

pkg/services/repobuilder.go
3.55% <0.00%> (+0.57%)
:arrow_up:

pkg/routes/images.go
25.92% <0.00%> (+1.52%)
:arrow_up:

pkg/services/images.go
8.88% <0.00%> (+5.47%)
:arrow_up:

pkg/clients/imagebuilder/client.go
37.50% <0.00%> (+13.38%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 30c21da...fedfd6c. Read the comment docs.

(I got carried away and merged. Is that okay?)

@biancarosa lol yeah but we should add mergify bot to the project also 😄


sponsor_image gets hidden by ad blockers

Sponsor images with the sponsor_image class get hidden by uBlock origin.
uBlock on:

uBlock off:

Looks like uBlock adds display: none important! to elements that have that class.

I was able to work around the issue by using a different class (.logo) for the sponsor image, along with some extra css.

Fixed in https://github.com/typlog/sphinx-typlog-theme/commit/784aeaa3576eaf30b0433f2d7a8b0e37ad0dab87

Thanks! I was able to remove my workaround after installing 0.7.1.


Profile endpoint implementation

Profiles are containers that bring the Controls together. So we need to be able to add Controls to profiles, probably storing their primitive.ObjectIds in an array called Controls in the Profile documents.
We need to add the following endpoints for Profile management.
Add control to profile:
POST /api/profile/{profileId}/controls: Post a control Id to this endpoint and store it inside profile.Controls array
Remove control from profile:
DELETE /api/profile/{profileId}/controls: Post a control Id to this endpoint remove it from the profile.Controls array


Roadmap for Grav 2

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.

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.

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.

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

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.

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.

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.

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.

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.

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!

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.

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)

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.

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

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

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.

@apotropaic
Flex-Directory is a plugin for Grav which allows you to add a custom type by writing blueprints and allows you to have full CRUD (Create, Read, Update, Delete) over the content in admin.

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.

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.

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.

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.

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

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

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

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

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.

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 👍

I would like to see also:

better multisite management
wysiwyg edito integration

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.

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.

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

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.

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.

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.

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.

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.

Large Site Support

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

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.

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

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 😊

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.

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

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.

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.

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.

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!

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

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.

Please change image manipulation library to imagine.
Better WYSIWYG HTML Editor integration

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 achieve SPA for Grav would be amazing and makes it easier to port to IOS or Android as an app.

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

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

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.

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

@rhukster you said "to perform advanced collection handling as well as complex queries of collections and objects", since Grav is using 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

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.
What would be a great feature in Grav 2 would be the ability for asset manager to have an option to set a script to be added as a deferred script call, that then only loads once the page is rendered.
This then get arounds one of the most difficult and annoying aspects of performance improvements - Above the fold and stops the scripts from delaying the page load time, which is a boon for users.
Yes, you can set the script option to 'defer', but this still isn't as effective when it comes to speed as taking these scripts into their own file.
In many ways, the existing pipeline feature would take care of this, but you can't set the pipeline script to defer to my knowledge, it's just output as a stand script call albeit compiled by Grav nicely.
For now, I've had to manually add the scripts to a deferred.js script manually, which negates the nice ability to order scripts in a modular fashion with asset manager.
The same, of course, would be great for CSS although 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.

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.

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

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

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

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

Massive +1 for larger sites

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!

Provide better page collections, so we can do everything, just like with SQL queries.
Provide native smart views counter.

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

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

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

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.

Thumbs up regarding the WYSWYG editor :thumbsup:.
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.

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

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

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

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

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.

@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

Large Site Support will be very nice and is very needed :-)
Edit template from admin panel is also very needed and useful. For example like here https://generatepress.com/premium/
Please not use MySql or any SQL!
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:

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

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.

FYI, I updated PHP 7 requirement to 7.1/7.2
Please read: https://getgrav.org/blog/raising-php-requirements-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.

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.

I would like to be able to edit 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.

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.

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

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

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 ecommerce
Besides the snipcart plugin which is pretty much useless if you don't use snipcart we really don't have any realy ecommerce cupport. Even in the "club" we have one theme (again using snipcart). We need more stable (official?) solution for ecommerce so we can start using/pusing grav into this direction. Would love to start making more eshops 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 patform 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 the oroduct to customers.

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

I am also more interested in a large site setup with Grav. Keeping all the $pages properties in RAM make the site slow beyond a couple hundred pages (my use case).
The TNTSearch plugin works so well - would there be a path to couple the fast SQLite lookup of TNTSearch with saving the necessary resources of the $pages container there?

@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, compatibility with high speed optimizations (see #2093), etc.
I will roll out some of this stuff during the next weeks.

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

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

Regarding host configuration, I've been using /user/sites or /sites 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.

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.

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

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!

Here go my five kilobytes of a tiny humble idea that totally isn't going to ruin someone's few days' worth to implement in a backwards-compatible manner, would it be possible to get something similar to the Auto Date plugin (but perhaps setting the dates during onAdminSave :upside_down_face:) officially integrated into Grav 2, thus starting to ignore the timestamps provided by the OS? (well, mostly, the compatibility code has to work somehow)
My reasoning behind requesting this change is that most of the time, whenever the creation dates are relevant at all, people don't want them to change during page modification - think a blogger fixing a typo in an old post, just for that post to jump ten pages upwards with virtually zero ways to figure out how exactly it was dated before. (logs, eh?)
At the same time, for the websites which do want the dates to change as a result of even the slightest edits (#masterSEO?), an option could be added to make the dates get modified during the above-mentioned onAdminSave, or a plugin could supply that functionality, too.
Okay, one says, but if a plugin works for fluid dates, why isn't a plugin for static dates enough? Quite simple - system timestamps are unmanageable. Now, so that I don't end up figuring out unrealistic horror scenarios with specialized virus scanners putting All ok!! messages in some very unfortunate places, let me mention my own story right now, be it horror or not.
<story>
I wanted to create a plugin for page favorites, and it has forced me to put stuff in user/data to preserve correct dates, a massive increase in overhead, while a simple favorites: x page header variable could work very well, if the timestamps were ignored. In fact, I haven't done this, as I use auto date and I'm lazy, so the plugin is private.
</story>
Okay, just kidding. It's a true story too, but that one is easily solvable. Here comes the...
<actual story>
A few months ago, newbthenewbd/grav-plugin-tinymce-editor#18 has been submitted to the TinyMCE Editor Integration plugin, which I maintain. It's essentially an issue about static relative links to attached media always being wrong with modular pages. I would like to have a fix for it available in the next, presumably long-awaited update, so I've checked my options, ordering from easiest to hardest.
Option no. 1
Just use absolute URLs, letting a single page rename, page move or whatever else affecting the path mess up it all. Baaad!
Option no. 2
Generate the relative URLs dynamically on page load with PHP, for we all know how fast the required DOM parsers are, right? This works with Markdown, but with HTML... Baad!
Option no. 3
Generate the relative URLs dynamically with JavaScript on page load, ignoring the pleas of the users caring about their privacy, and possibly those with messed up browsers, too. Okay, this actually works, as it did for the person who submitted the issue. But still... Bad!
Option no. 4
Generate the absolute URLs dynamically, running the generator only when an action is performed in the admin plugin that modifies the path, assuming that the people who are modifying files directly definitely have the time and abilities to run what usually is a simple search-and-replace. Good! But wait... I can generate the URLs on the pages directly getting renamed and/or moved just fine, but how do I get to their children without breaking all the dates and orders?  Ough!
Option no. 5
Like option no. 2, but add a clever cache setup that remembers the corresponding URLs. Perfect! Except... Not only is this so difficult to do good that it will end up broken in multiple ways, most of which will first be noticed by the end user (long live cache!!), it's also still slower than option no. 4.
Quite obviously based on the context, I thus far chose option no. 4 without modifying children, so unless I figure out some magic to achieve this using some of the safe functions available in Grav, modular pages will still be broken somewhat, just in a hopefully slightly less infuriating way.
~</rant>~ </actual story>
Anyone still reading? Oh, good. So what does the above have to do with the feasibility of using a plugin for fluid dates, versus one for static dates? Also quite simple - if the default behavior is something similar to what the Auto Date plugin does, then the dates only get modified when a designated event is fired, typically letting a determined plugin modify pages without triggering date changes, in a way that isn't going to break precisely while the plugin's author is having their well-deserved lunch.

My reasoning behind requesting this change is that most of the time, whenever the creation dates are relevant at all, people don't want them to change during page modification - think a blogger fixing a typo in an old post, just for that post to jump ten pages upwards with virtually zero ways to figure out how exactly it was dated before. (logs, eh?)
At the same time, for the websites which do want the dates to change as a result of even the slightest edits (#masterSEO?), an option could be added to make the dates get modified during the above-mentioned onAdminSave, or a plugin could supply that functionality, too.

That was a fun read! Might be missing something, but aren't these issues most easily solved by adding different date headers in the frontmatter? So as well as simply date, there's also, say, modified. date is like a creation date and treated as essentially immutable. If deemed useful and reliable, system date can be derived as needed.
I've been through these considerations when I used to work a lot with popular syndication formats (RSS/Atom). We had requirements:

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

We left it up to consuming applications (reader etc.) to decide if they wanted substantive edits to result in the items being promoted to the top of listings.
So Grav's Admin editor interface could include a checkbox where editors can indicate whether the edit they are making is significant. Their call. That checkbox would affect whether the modified header is updated.
(Note that this is separate to publication dates, which are already covered in Grav by publish_dateand unpublish_date.)

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

I didn't actual realize there was a problem. Not tried this myself but having different cache files should not be an issue in itself if using file based cache. They would just be unique per server. Even using a unified cache like  mcached or redis should just result in unique cache per instance, but should still work. What is the problem specifically regarding that?
Session also being unique per server simply means that user session should sticky to a single server. This is very common approach and is supported by most load balances. So again what specific issues are you having there?
Maybe open a new issue about this so we can discuss a bit more in depth?

I would like to see in Grav 2.x the following features:

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

@Lufog-git
The idea we have is to keep all the main data in the filesystem -- after all the idea of Grav is to have all the data as files so you can easily copy them over or push the changes into git. That said, I'm currently investigating having indexes in separate files or alternatively in SQLite. Those can be removed and will be rebuilt if they are missing.
What comes to the other ideas, we have had those in our mind, too, but not enough time to do everything we want.

From a purely architectural point of view I do hope Grav isn't going down the same path as every other major CMS, that is, adding databases first optional and then as a requirement (even if it's SQLite), adding widgets on top of modules, and on top of that adding WYSIWYG editors in 5 flavors, no less. Even though we all want Grav to be more and more popular, it's probably much more important to let it stand out in the crowd by sticking fast to its original strengths, rather than evolve into Wordpress. Not saying that's what's happening in version 2 or even 3, but let's just hope it would never happen.
For me Grav was a breath of fresh air, simple, lean, understandable and a system that made a lot of sense. I always developed websites in a text editor, had full control over the code and would never willingly touch a CMS like WP or Joomla, so Grav essentially leveraged all the pros of that approach and didn't introduce any cons. And importantly compared to other CMSes out there it's super easy to learn.

In addition I would like to suggest:

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

Just GraphQL, please, everything else is sublime.

@adminnu

Unknown but existing frontmatter variables are already kept in Flex save. I didn't fully follow your idea, though. There's also a way to customize form by ACL.
Yes, this is a limitation/feature of YAML and is true for English, too. Renaming already works (you need to configure it), though with a few issues.
Do you mean that you'd like to have modular content in the same folder with the page?
4-5. Both can already be done, though not without doing it yourself.
There's already configuration option for this, I'm using it in multiple sites. :)

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

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

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

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

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

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

Namespacing themes and plugins by author name and type is something I always wanted to have. That would definitely prevent name collision between same name/ different author and same name / different type (theme vs plugin).
v2 is probably the best place for looking into this.

Completely unnecessary but insanely awesome: Re-design Admin interface that looks like Stripe UI :-) The current admin interface looks very dated...circa 2010'ish.

image processing on upload/save (simply put: in admin not in client)
image meta (captions,…) editting capabilities in admin (simply put: native gallery support)

I would like to see more tools for developers. For example, a simple api to modify image actions, menus, text editor, as well a reivented pages collection object/queries. Right now it's quite tricky, but maybe needs more consistence.
Btw backward compability sounds pretty good for some :)

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

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

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

GENERALITIES FOR GRAV'S WEALTH
If I had a few personal ideas on how to improve Grav, it would be this :

Ameliorate/update some documentation pages, where there is some "ambiguous" information or lack of information. But that part could be filled by anyone (including me), given the opened editing of the documentation. So it's a hollowed statement, but I had to say it.
Create categories to sort plugins on the official depot. I'm actually doing my own tree-sorting in my bookmarks, but it would be appreciated to have categories when browsing the library.
Keep track of possible missing or wanted plugins. (suggestion box ?)
Keep track of "abandonned" plugins (inactivity on GitHub / old update) : very usefull to bring some people to participate !
Attach a "team" to each plugin, in order to contact volounteers (devs / regular users) rapidly on Discord. This could be seen as a "unofficial pro support".
Impose or strongly encourage use of the built_in_css yaml option for development of plugins, in order to allow webdevs to deactivate plugins' CSS and avoid certain conflicts with their design.

And then, regarding to development with Grav and features :
INSTALLATION / CLI

New CLI commands :

A single command to install Grav, based on a preset of possible installations (cloning master or testing or specific branch + install it directly in the actual folder (not in a sub one) + composer command automatically following + $bin/grav install). Excuse-me ? You said that "it's impossible because it would require to have already Grav installed for having the aforementioned commands" ? :) Well, it would be a good idea to have a kind of stand-alone grav command or installer (like npm). But it's just an option, a sophisticated caprice.
Ability to quickly check installed things (plugin, theme, etc). That's a real miss : actually, there's the possibility to manually pipe to grep, but the last time I tried the exact same technic, it failed (maybe due to Grav update and new outputs ?). Anyway that's tedious and a command would facilitate things (like $bin/gpm installed or $bin/gpm index -i.
A backup restoration command ?

More craaaazyyy CLI commands :

Ability to change a page's frontmatter option ? (would be so coooool :D )
Ability to change a plugin config option ? (same ^^)
Ability to toggle between a dev or prod environment :

Automatic creation of the /user/localhost folder, with clones of system.yaml and admin.yaml.
Auto-defining of basic presets for each environment (cache, pipeline, etc).

Ability to quickly create a page in order to avoid manual folder/file creation (I imagined a plugin wich could do that ; but have no skill to develop it for now). Options would be : Title, type (regular/modular), parent, template and/or markdown name. A batch creation could be feasible for any parent branch (/root or another) : collective type and template/markdown name, followed by an input for each page's name, and voila ! A dozen pages created in a snap ! ^^

Reallocation of the whole Grav updating command : I found strange to use $/bin/gpm self-upgrade instead of $/bin/grav self-upgrade. All general Grav maintaining should be done with the grav command. GPM should stick to packets.

ADMIN PANEL

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

MARKDOWNS / TEMPLATES / TWIG

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

DEBUG BAR
Messages tab
The name of the variable/content dumped with the {{ debug() }} calls. Actually, it just displays the result, on the left (ex : true. True for what ?), where it should display the name + the result for a better view. When dumping one or two things, it's okay, but if tens of dumps are let in templates for debugging purpose and suddently activated, or if a simple loop is done with a few dumps, it's hell.
Timeline tab
The possibility to unfold an entry (ex : Twig, or Pages) in order to see exactly wich elements are implied in the rendering, and the time they take. Actually, if we see that the Pages generation takes time, we're unable to see what page specifically takes time. Same thing for all the actual entries.

I wonder what the feasibility would be of implementing Gutenberg for Grav would be? If even Drupal is looking to do so, there must be some strong benefits to doing this. As I see it, a universal, cross-platform content editor definitely has some appeal -- from a developer standpoint and for end-users.
One specific benefit is it could also help make it easier for users to move from WP to Grav. As I understand it, Gutenberg (while far from perfect yet) is built to be able to be easily ported for working outside of WordPress. For example there is this cool gutenberg-js project.

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

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

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

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

Might the use of CommonMark be a good feature for 2.0 to highlight? Looks like GitLab has now moved to CommonMark, and perhaps others including GitHub soon... https://twitter.com/_SimpleSoftware/status/1141141006777274369 Perhaps extensions could be used to support things like markdown extra functionality or GitHub flavored markup?

For a more "complete" argumentation against implementation of Gutenberg, here's one point of view :

Gutenberg is a very cool, from a CMS point of view (easy for non-dev customers).
But from a HTML generation side, it's a hell to maintain. Not mentioning that HTML generation can conflict with the markdown-twig native relationship in Grav (like TyneMCE do).
Finally, in Grav there is already a possibility to reach this brick-style level of page creation, with help of the "widget" plugin, and the use of modular pages. Modular pages can be filled with images and displayed with gallery templates, or other type of content and corresponding templates, and widgets can help, based on a special HTML layout, to display sidebars. Of course,  the move of the bricks is difficult given that templates are "rigids", and all of this rely on themes and plugins disponibility, but it can be considered as "already there".

In short : it is the matter of developers to offer good themes with good modular templates, and a good updating of the widget plugin, and layouts taking account of this plugin. Also, a maximum of flexibility (like defining the position and size of bricks) in the frontmatter should be a priority in every developer's mind.

Very good points @Romarain and I'm sorry @rhukster I totally regret even mentioning Gutenberg and freaking people out. I totally agree now it's not a good idea for core at all. The "Widget" plugin mentioned my @Romarain actually takes care of lot of modular functionality I think Grav needs.
However, what I think would really be even more effective and enable developers to make good modular themes would be the inclusion of Conditional Fields functionality. Perhaps, that's more appropriate for a goal for Grav 2, or sooner :) ....

@onetrev I've just finished (yesterday) a JS script to allow that ! I wonder if I will propose it for implementation in the project.

An RDFa Microdata tool built-in Grav core to use on themes and plugins. Most of the schema.org content it's done by developers manually, and not many CMS includes native tools for handling this information. It would be nice to see some steps forward on this feature because search engines rate up this data, and Grav is about websites. Good coding!

just please please please still keep the simplicity in mind! I fell in love with Grav mainly because of how simple / transparent it is. It's great to have all these improvements, especially when it is indeed improving things which already exist (caching for example).
It's probably to late, but I believe things like Widgets, Content blocks etc. are taking Grav in the direction of "jack of all trades, master of none", like WordPress. I think a lot can be already achived with Page, Modules (modular pages) and partial templates, and that no matter how hard you try, you will not be able to give some "power users" enough tools to properly design a website using a GUI. It will be either too limited, too complex, too slow, produce dirty HTML or negatively impact SEO (or several of these things).
...I mean if you do achieve a good balance between all those things, it would be great. But please be careful not to make it too easy to create such monsters in Grav like I currently have with WordPress + Avada + Shortcode plugins + PHP snippets, because I was too lazy to learn how to build a WordPress theme (I'm glad I didn't, because this made me find Grav).
WordPress = Swiss knife -> can do many things, but none of them really good
Grav = Katana -> you need to learn how to wield it and maybe make your own holster, but then it becomes a solid simple tool to do the job

I agree completely with @peachp
Developers being creative people, not giving in to the temptations of creating yet another piece of functionality may be the hardest thing to do while still maintaining and only improving what already exists.

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

I'd like to mention three aspects where Grav could gain simplicity and features:

packages. Use composer (& composer-plugin if really necessary) then drop the thousands of lines of custom code, dozens of bugs and bring-in lot of feature currently lacking.
blueprints. The rocket-theme code related to this is really hard to grab. I'm pretty sure the couple of YAML import/load/order functions it provides may be better implemented another (cleaner) way. Yaml functions? Yaml anchors? Extending core parser?
forms. It's a very useful component which definitively has some good points (the Twig part for example). But I'm sorry to say it's often not on par with my expectations : Caching, but also forms fields referencing, loading, import, override (and their relation to blueprint's). Many may also want to see a blueprint-generator (aka form builder). Like for composer, better (standard?) alternative implementations YAML-forms may exist that could be considered?

Grav 2 is abandoned?

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

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

Grav 1.7 already has many of the changes discussed in this issue, at least in some form, but with backwards compatibility, which will be removed in 2.0. I see 2.0 just as a change to remove old behaviour which we do not want to keep on supporting anymore. Likely it will have more than that, but we do not need 2.0 to implement new functionality.

One suggestion :

I think It would be nice to save pages' images in a separate data/pages/images/01.mypage subtree directory. It would avoid to add a gitignore rule, and make dev<->prod sync easier. As it is in Drupal, and Wordpress.

Another:
Vue.js integration or any other relevant framework integration (a least a small documentation reciepe).
When one use JS framework one need to access GRAV CMS, page, plugins configurations which should also be filtered for security reason...

Maybe I'm late to the party... and this is not for feedback... but....

Would it be possible to have a clean structure in Grav 2, where all the contents of the CMS is in its own root folder (for instance a 'grav' folder), so it is separate from the other possibly systems we developers install on our sites? Currently, an install places everything in the root of your site.

A .htaccess file that is not re-written by the system, but rather combined with other .htaccess that is already in it? Or... a htaccess section inside the CMS, that allows for the developers own htaccess stuff to add? I do a lot of stuff in htaccess, from some hacks, to safety, error page handling etc, but those keep getting overwritten whenever Grav decides the htaccess needs an update. PS: I raised this issue back in 2019 on the chat servers. Don't know it this have been dealt with since?

@MakePixelsWork You likely use the wrong package to update Grav, as the update package doesn't contain htaccess or robots file.

@mahagr > Nope. The self-hosted Grav Core and Admin has it in its download.

Oh, those are the default files for sure, required to make Grav to work at all. They cannot be removed or majority of the sites would break.
If you need your custom files, you should first copy the files and then override them with your own install script. Or you copy the files into a separate location and delete the files you don't want. I do that all the time and not just with Grav.

I suppose @MakePixelsWork wants a system of update that can (and that's the purpose of any update system) to check files modifications and timestamps to decide wether or not it needs to be "updated". Thus, its modified htaccess wouldn't be overwritten.

 Or even when installing, by specifying a sub-folder in the github command ?

@Romarain > I think I can install in a subfolder, but then the site pages will also have that folder next to the domain. So www.domain.com/page becomes www.domain.com/subfolder/page/   where subfolder is 'grav', 'site', 'blabla', 'etc'.
@mahagr > Since these are needed in the root, and some of us developers also write out own HTACCESS stuff, we need to have some sort of combination. If for any reason I update the system, and they decide to overwrite the htaccess, all my edits are removed from the file. This also applies to robots.txt

This is how I do it:

Install Grav
Modify .htaccess and robots.txt files (or copy default versions you use)
Update Grav only by using CLI command or from Admin, NEVER use the installation package

Grav will never override htaccess or robots files again. And yes, I do use custom files.

I think these are sample files that are not strictly required by a grav site, to facilitate the update they should be removed, so it would be just unzip and replace. On my sites I don't use apache and the htaccess file is of no use to me, and on my sites I have my own robots.txt files that I need to maintain between updates.

I'll take note of aforementioned procedures ... but assumed they would be updated with Grav updates. The team should know this, so if they can verify these are never overwritten, I can install something and then never overwrite it again.
And yes... I too can take care of two files, but I was just wondering if it wasn't a better option to have some module inside Grav that handles the Grav side of the file and in which you can handle some of your own code as well. Although on second thought, that's also a very crucial file that can fock up someones site. So maybe there is also a reason to NOT include it as an editable file inside Grav. Food for thought?!
Thanks to all for feedback!

It would be great to upgrade to CodeMirror6 for Grav 2. This may likely address https://github.com/getgrav/grav/issues/3666.

A table editor like in DokuWiki. Tables are the weakest spot in markdown.
A plugin like "Admin" but for editors / content creators. It should be clean and simple, free of other stuff, so nothing distracts me from writing deep and profound articles.

Automatic images insertion with full version available on click, like in DokuWIki.

![zebra](zebra.jpeg?width=400)

<a href="user/pages/hires-photos-from-zoo/zebra.jpeg"><img src="/cache/x/zebra.webp"/></a>

May be there's already a plugin for this?

I just found that Roadmap. As I am the person who started Request #2947  I was checking what is going on that matter. I found that the translation philosophy change is not on the list to version 2. Is possible to add this topic as well?

@rhukster is 2.0 a dead project?


Update Default Model Information

This PR contains daily documentation updates based on the following suggestion:
Update documentation to reflect the change in default AI model from 'gpt-4 turbo' to 'gpt-4o'. This change is critical for users to ensure they are using the correct model configurations in their applications.
potential files to change: docs/quick_start.md, README.md

issue here is the readme was suggested before the context ignore could filter it.


Added libdispatch support.

This PR adds the binaries for Apple’s libdispatch (https://github.com/apple/swift-corelibs-libdispatch) to the Swift buildpack. Though this library is still under heavy development, applications and frameworks using the Swift language for server-side efforts will probably have dependencies on libdispatch today. For instance, the Kitura web framework depends on libdispatch. Apple has communicated (in the mailing lists) that these binaries (libdispatch) will be part of the Swift binaries (https://swift.org/download/) once libdispatch at some point in the future. In the meantime, it would be beneficial to include these in the buildpack for Swift.

We are closing this PR since after conducting more testing, we ran into the following issue: the binaries included in this PR for libdispatch will only work if the Swift binaries from 03-24-16 are used for building the Swift application. If, instead, an older version of the Swift binaries is used, then a compilation error similar to the following is thrown:
Compiling Swift Module 'Server' (1 sources)
/tmp/staged/app/Sources/Server/main.swift:31:8: error: module file was created by a newer version of the compiler: /tmp/cache/swift-DEVELOPMENT-SNAPSHOT-2016-02-08-a/swift-DEVELOPMENT-SNAPSHOT-2016-02-08-a-ubuntu14.04/usr/lib/swift/linux/x86_64/Dispatch.swiftmodule
import Dispatch
^
:0: error: build had 1 command failures
swift-build: error: exit(1): ["/tmp/cache/swift-DEVELOPMENT-SNAPSHOT-2016-02-08-a/swift-DEVELOPMENT-SNAPSHOT-2016-02-08-a-ubuntu14.04/usr/bin/swift-build-tool", "-f", "/tmp/staged/app/.build/release/HelloWorldSwift.o/llbuild.yaml"]
Staging failed: Buildpack compilation step failed


add spacingFactor option

Accompanies PR #1673 in cytoscape.js (for 3.1 release).
New feature (does not break compatibility with old configurations) should bump version to 1.4.

TODO merge concurrently with<EMAIL_ADDRESS>