Is it possible to make the second page the default on arrival at the site?

Grav seems to load the first page by default, and the menu seems to depend on the menu ordering. I’d like to create a site where the default page is the second item in the menu. Is this possible?

@counterpoint, The docs might know… Configuration | Grav Documentation

Yes, I read that and didn’t understand it. Examples would help.

You could manually create the first item in the navigation partial of the template. So add a hard-coded link before it goes into the menu item loop.

@counterpoint, Maybe I do not understand your intension, but what is not working as expected when you set the following in user/config/system.yaml:

home:
  alias: '/second-page'

If the url in the browser points to the root of the site (in my case /localhost/grav/site-home/), Grav will display the page with route /second-page. “Second-page” is therefor highlighted in below image.

Untitled

Yes, I tried this out as well and it seems do what is required (unless I am misunderstanding). You can make any page the “home” page with this setting.

@pamtbaau Thanks for following up. You can blame me for impatience if you like, but I set out optimistically reliant on the claim at https://getgrav.org telling me “The Grav admin plugin provides a simple and intuitive interface to make configuration and content creation easy and enjoyable”. Before I say more, it’s worth saying that I like a lot about Grav and don’t doubt there is some justice to the claim that it is the best flat file CMS. But Grav is actually quite confusing for a newcomer. (Including the issue we’ve already discussed about the lack of information on the functionality of themes).

A big issue is that the implied claim that everything can be done via the web UI seems to be misleading. A lot of things seem to require editing of files, and at least a basic understanding of the formats used.

In this particular case, I think the obstacle was terminology. When a page is created, the system automatically creates something called “Folder name”. Once the page is created, this is only accessible under the tab called “Advanced”, which is a deterrent to looking at it.

Then, the documentation that you kindly linked talks about the “default path” in the text, and the configuration file uses the term “alias”. Nowhere is “Folder name” mentioned, although these three terms presumably refer to the same thing. Having written documentation, I do understand how hard it is. All the same, it is confusing and unsettling for a novice to face so much terminology.

So, I got it to work in the end. Yes, the mechanism is quite simple once understood!

@counterpoint,

“The Grav admin plugin provides a simple and intuitive interface to make configuration and content creation easy and enjoyable”.

Well… that’s marketing… The slogan used to be “[…] ridiculously easy”.

But Grav is actually quite confusing for a newcomer.

That seems to be true considering the fact that this remark recurs every now and then.

As far as I know, Grav has been build with developers in mind. And as a developer I really like Grav’s core. It felt like a breeze of fresh air after working with Joomla and WordPress. For me, the shell/terminal with VScode is so much easier, more flexible and faster…

[…] and at least a basic understanding of the formats used.

That certainly helps. I guess that knowing the concepts of Grav makes working with Admin easier.

Anyway, the setting for the home page can be found in Admin through menu ‘Configuration’ and tab ‘System’, section ‘Content’. It provides a dropdown of all existing pages.

May I ask what made you interpret it like that?
Here’s a quote from the first docs page:

To get a basic site up-and-running requires minimal Web development experience.

It clearly states, that even for a basic site you’d need some dev skills

To get a basic site up-and-running requires minimal Web development experience.

@Karmalakas, My interpretation of the statement “requires minimal” would be “requires almost no”.

Like “Our new trainee requires minimal supervision.”

However, above quoted statement only holds true when the user can accept the functionality provided by themes/plugins and a few minor configuration tweak. For anything else, development skills are required.

@counterpoint, I wonder though, what is the idea behind having the second page as the home page? I don’t think I’ve ever come across a site where the home page is not also the first menu-item. And how would the menu-item of the “second-page” then be called? “Home”?

Well… Different views I guess :slight_smile: For me “almost none” is the same as “at least some”.
But what actually triggered me, the interpretation, that “EVERYTHING can be done via the web UI” :man_shrugging:

@pamtbaau I’ll come back to the general issues later. The reason for my original question was a need to split control of a web site between two groups of people. The only way I could see to do that robustly was to have two identically designed web sites. The first site has pages and menu items as usual, except the second menu item links to the ‘About” page on the second web site. To do that neatly, that page is set as the home page. The first menu item is called “Home” but is actually a link to the first site. The second site is a subdomain of the first. With that in place, each group can have its own administrator(s) who can do anything, but cannot alter the other site. (They could break the setup, but nothing is perfect). To a user, it is hard to see that it is not a single site.

@counterpoint,

  • Not sure if I understand everything correctly, but it smells like an ugly solution.
  • About putting control on editors: I would like to point to a common Pythonian expression: We are all consenting adults.
    Which means: We trust people do not abuse their permissions.
  • If you really need to: Have you looked into Groups and Page access permissions?
    • Create 2 Groups of authors. Say ‘Authors1’ and ‘Authors2’
    • Grant each group: Admin login permission + Page CRUD permissions
    • Assign authors to either group Author1 or Author2
    • Go to page(s) for which you wish to limit access to 'Authors1` and disable page permissions in tab ‘Security’. For example when blocking Authors1 from changing page ‘Home’:
    • Do the same with pages for which you wish to block group Authors2
    • If a group does not have CRUD access, the button bar will not show buttons like ‘Delete’, ‘Add’, ‘Save’.
1 Like

@pamtbaau Yes, that provides a degree of control, thanks. But it doesn’t allow the authors to create new pages, which is a critical requirement. I’m not sure what it is you don’t like about the two sites solution - it looks like it will work well. It could be better to have the secondary site in a subdirectory rather than being a subdomain, from an SEO point of view.

@pamtbaau @Karmalakas Not sure it’s worth much of a dispute, but I didn’t only read the “minimal Web development experience” phrase. There are also statements making comparisons with Joomla or Wordpress. I think it is possible to build quite sophisticated sites using them, without ever straying from GUI web interfaces. And what counts as “web development” is pretty flexible - does someone who has built a number of Wordpress sites without ever editing any code count as a “web developer”?

That’s not to say that I particularly like Wordpress or Joomla. I’ve created a number of Wordpress sites while delving into it as little as possible. It seems to get over-complicated quite easily. As for Joomla, I have an application that used to be widely used and is still supported for some users, so I have no choice but to write code within the Joomla environment.

My view of Joomla might be coloured by early experience. When Joomla forked from Mambo, I was unconvinced by the reasons given, and joined the Mambo development team. I was lead developer for the major release that was built after the Joomla fork. Unfortunately, although I think we had the better code, Joomla had the more effective PR.

I dislike many of the design choices made by Joomla, and also find the development team quite unpleasantly arrogant. To me at least, Joomla seems an extremely hostile development environment, and the project appears to have little regard for third party developers. Which is ironic when you think that it is the availability of third party additions that dictate the choice of a CMS at least as much as the CMS itself.

But I am now semi-retired and could be accused of being past it!