I’m sorry if this has already been covered, but I couldn’t find the answer. In fact, I may have found it and not recognized it. I’m coming from a WP background and I’m a fledgling developer. I managed to make some great progress today, I’m very happy with it, and I don’t want to give up on Grav.
I’m using the future theme, which I love, and I’m trying to put all child pages for my blog in a list in the sidebar between two sections About and Contact. I would prefer not to list individual blog post. Instead, I’d like to list categories in the sidebar.
When a visitor clicks on a category, say “Pets”, all the blog posts about pets will appear on the right (in chronological order). They can then select the particular post they want to read.
I’d like to have the blogroll by catagory enabled globally since my sidebar is.
If this is not rocket science, how can I get it done? Are there instructions for Grav novices?
Actually, I’m really happy with future. I found the line {% include 'partials/taxonomylist.html.twig' with {base_url: /blog, taxonomy: 'category', children_only: true} %}
…but I don’t know where to put it! I tried placing it between <section> and </section> of my sidebar.html.twig file, but my browser returned a pretty ugly error page.
Where do I put it? I’ve already installed the plugin. (Thanks by the way. It’s almost 100% what I was hoping for.)
Thanks a heap. As for the theme breaking, I don’t really want to be a developer. What I’m trying to do is get grav setup as a web site that I can then indefinitely add content to. When I get to that stage, which should be pretty soon, is it possible to not update grav anymore? Just keep it as I’ve got it?
Actually, I’ve looked at the theme you recommended, and to be perfectly honest it’s too complicated for me. I like it a lot, but I don’t have the expertise to configure and tweak it…
@sebawrite, I have had a look at Future and the Taxonomy List plugin.
I can give you the steps to use the taxonomy list in the left sidebar, but then you will stumble on the absence of css for styling the taxonomy list…
And to be honest… I feel reluctant to help you with this very outdated theme with imho messy code. I would strongly advise you to look for a more modern theme. If you like the look and feel, I would go for Quark. I doubt if it is more complex to tweak then Future. It is also ready for Grav 1.7 which will be released mid January.
I don’t really want to be a developer
You might also opt for wordpress.com which is free and hassle free. It will be updated indefinitely. You pick a theme and presto you can start blogging. There are more free blog providers available.
Okay. Well, before you waste your time anymore, I’ve changed to the Antimatter theme. I like it too, and hopefully it will survive for a while. As for Wordpress anything, I’d rather become a novice developer than a Wordpress guru.
Edit
Okay. I think I can put it clearly now. What I do not understand, and what I have not found in the README.md files, is how the front end is supposed to call the back end. If there’s a plugin installed that is modular in nature, like “recent posts”, there has to be a way for me to call it at a specific place in a page. Like shortcode, etc.
That’s what I don’t understand. How do I connect the front end and the back end in Grav?
So themes will have taxonomy cloud built in. For the ones that don’t you will need to modify a template. In Future theme you would modify the sidebar.html.twig file and add code like what’s below changing YOURURL for the url to the blog page.
You also need to be sure to assign your taxonomy tags to the main blog page and all the post pages from the admin panel. I added a div and header but you can style it however you like. It is usually best to make a child theme first and copy the templates you want to modify to the child theme similar to how Wordpress worked. This way updates don’t break anything. At the very least make a back up of any template before modifying it so if something goes wrong you can just replace it.
<div class="tagList">
<h2>Tag List</h2>
{% for tag in page.taxonomy.tag %}
<ul>
<li><a href="YOURURL/tag:{{ tag }}">{{ tag }}</a></li>
</ul>
{% endfor %}
</div>
Find the following code in the user/themes/future/templates/partials/sidebar.html.twig
{% endif %}
If you want a simple way to work in Grav, Install a simple theme like bootstrap4. Then install the TinyMCE Editor plugin.
Then with a little CSS you can use tables to create your page layouts which are responsive. The table works much like a visual builder. You install a table with 1 row, as many columns as you like. Then add your content in the table cells. You can even use a nested table.
With Twig Processing Enabled, you can use twig code right in your pages.
This test site uses a page called sidebar. I just dropped dropped this code {{ page.find('/sidebar').content }} in the table column I want the page to show in.
It makes it much easier than dealing with templates.
This page has the sidebar include and nested tables.
Also, the gantry 5 plugin with a theme that supports it like the helium or hydrogen theme, works well also. It has a visual layout area and you can positions ( like widgets ) to add to the layout manger and that code will show on whatever page you enable to show it.
It makes handling the header, footer, sidebars, etc much easier.
Please be aware that a few practices mentioned in this thread are considered bad practice and discouraged to use:
Using <table> for webpage layout:
A <table> is designed for tabular data, not page layout.
The use of <table> for page layout is a left over from the early days when there were no alternatives. The World Wide Web Consortium (W3C) declared the use of <table> as layout invalid in HTML4 and an ill practice since HTML5:
Tables should not be used as layout aids. Historically, many Web authors have tables in HTML as a way to control their page layout making it difficult to extract tabular data from such documents. In particular, users of accessibility tools, like screen readers, are likely to find it very difficult to navigate pages with tables used for layout.
And according W3C in their ‘Web Accessibility Tutorial’ on tables:
Notes: This tutorial provides guidance for creating tables used to display data in a grid. This tutorial does not apply to tables used for layout. As a general rule, tables aren’t meant to be used for layout purposes. Instead, a best practice is to use Cascading Style Sheets (CSS) for visual presentation.)
Defining page layout in the content of a page: Markdown (*.md) is designed to create content, HTML is designed to create structure, and css is designed for presentation (color, fonts, layout).
Ergo, don’t define the layout inside of Markdown (content).
Keeping these concerns separate is considered good practice in any area of software design.
Regular pages and modular pages are often/mostly designed without a sidebar. Considering the above, this should not be ‘fixed’ by creating a layout using a <table> in the page’s content, but should be properly designed by changing the HTML in a Twig template.
This can be done by overriding the provided template ‘default.html.twig’ in an inherited theme. Using Bootstrap4 as an example, the blog item template could be used as an example to create a two-column layout for content and sidebar.
Also note, when {{ page.find('/sidebar').content | raw }} is used in Markup, the page will not get updated when the content of /modules/sitebar has changed, unless the caching of the page has been disabled, which defies one of the strengths of Grav: caching.
This trick should only be used when the included data is an integrate part of the content. Not when used in a sidebar.
When used in a template, the content does get updated.
I agree with what you have stated, but the fact is that not everyone wants to learn to code or be a developer.
Most of the time sites are built with divs, nested in divs, nested in divs and a lot of css to make everything align and size correctly. It is hard for most people to make style changes using CSS, much less layout changes. Also, when building a website for a client and turning it over to them with no control over layout and design, it is a big step backwards. Most clients want a site that works properly and one they can make changes to without having to read documentation or watch videos on coding to figure out how to change something.
There are probably a lot of people who come across Grav and like what they see, but are more of a hobbyist. They will never learn to code and have no desire to do so. I am sure they can pick a theme and use markdown to make a site, but it probably won’t be the site they wanted. In the end they will move to something they can work with that offers a easy visual approach to design and editing.
Using tables is much easier to work with, don’t really require any more code, especially in a more detailed layout, plus they are easier for a novice to work with. The other benefit is that more people are already familiar with them from using them in their office software like Microsoft Word, Libre Office, etc.
As I said, I don’t disagree with your points, I am just stating my reasoning of why I made the suggestions I did. I personally have not used tables on a commercial website for a layout since 2007 or 2008. The site I linked was a test to see how it would work. They work very well, don’t require any more code and allow a novice to use work with a visual layout in Grav. I suggested it as a solution rather than having to be forced to learn to write code for those not interested in doing so.
Your post was like an omen last night, pamtbaau. So I ran off to try to use divs instead. I pulled out my hair trying to get them to work… the simplest of things, really. Then I gave up and I don’t even remember what I tried.
The truth is, I’m a writer. I went to school for writing. Since I was seven, I have written. That’s all. So naturally, I want to write.
This probably isn’t the place to talk about WordPress, but I moved away from it for security reasons and the fact that it’s kind of a money pit.
Today, I completed two articles (localhost) and looked around for aesthetically pleasing themes. I’m now on Bootstrap4 Open Matter and I guess we’ll just see how that goes. (Every hour of extreme frustration I spend on things that begin with a { could be spent creating copy…)
Side note. I’m impressed with the friendliness of the Grav community though, and I think I’d like to stick it out a little longer before giving up. I think complexity has become inherent in online publishing these days, so there are probably limited alternatives to turn to at this point.
I just started playing with using the bootstrap grid classes ( col, col-lg-4, col-lg-6, etc., ) in the body classes area for my modular pages. This seems to be working but I need to test further. It gives you the option of creating multi-column layouts using the modular pages and the grid classes. It would still require a small template modification which I can help you with.
I would consider checking out the Gantry5 Framework as it would make using sidebars, changing headers and footers as well as adding custom areas to your pages much easier.
This page is set up using the 6 modular pages. I can adjust the column widths simply by changing the class used in body classes field. It is a cleaner way to do the layouts without tables to avoid running into the issues that @pamtbaau and @Karmalakas mentioned in other posts.
Okay Tom. I didn’t understand everything you said, but I did manage to get Gantry5 Framework and theme Helium installed. I’ll get started with it tomorrow as it’s 11:30 here. Thanks for the offer of help.
(By the way, I tried to revert back to @pamtbaau 's suggestion to install the skeleton Blog Site, and I also tried to install the skeleton One-Page, but I kept getting the strange error that localhost/admin doesn’t exist. I checked all the permissions, restarted apache2, and even updated with bin/gdm to no avail… so I gave up, installed the vanilla Grav-Admin setup, updated it, and installed the Gantry5/Helium deal…)
@sebawrite, You mentioned above that you tried skeleton ‘Blog Site’. The skeleton came with demo pages like /01.home/blog.md. This page requires the template blog.html.twig which comes with Quark (and many other themes). When you switch to a theme that does not provide the template blog.html.twig the error will be thrown.
