Ralf Herrmann

You mean with the code discussed here in the last posts? Very easy. 

The grid system is based on 12 units, therefore the “ipsGrid_span12” for a full-width entry. For the 2x2 the example uses two times half that value: 6. 
If you want 3 entries per line, you just use 12 divided by 3, which is 4. So replace the ipsGrid_span6 with ipsGrid_span4 and you got 3 entries per line. 

The code is technically correct, but the system probably doesn’t understand that there are two DIVs in the IF/ELSE clause, which will only output one.

It could be optimized by using just one DIV there and the IF/ELSE clause only for the class. 

As in the past, individual articles will be published when they are ready. There won’t be a single day when we release a complete documentation which covers everything at once. 

I don’t understand. Can you clarify?

We will provide step by step instruction for all the the main functionalities and modules of Pages. Just give us a little time. 

Feel free to tell us where you are struggling at the moment. This helps us to make the documentation better. 

There are actually more, but they are being reviewed and finished. So expect more articles very soon. 

Add ipsPad as additional class to whatever you want to show with a default padding. 

So for example <div class='ipsGrid_span6'> becomes <div class='ipsGrid_span6 ipsPad'>

And regarding the grid view for article listings: while that is not a default option, it only needs a small template change, since a responsive grid is already in the CSS. 

So to have a grid view for articles:

1. Add a custom database template in the Pages’ template manager. Make sure it’s of the type “Featured Records”. Also make sure you assign it to your article database. Also call it “Article Grid” (that name is later used in the code). 

2. Open the “index” template of this newly created template group. 

Replace this part:

{{if count($articles)}}
		{{foreach $articles as $id => $record}}
			{template="entry" app="cms" location="database" group="article_grid" params="$record, $database"}
    {{endforeach}}
{{endif}}

With this:

{{if count($articles)}}
    <div class='ipsGrid ipsGrid_collapsePhone'>
		{{foreach $articles as $id => $record}}
            <div class='ipsGrid_span6'>
			{template="entry" app="cms" location="database" group="article_grid" params="$record, $database"}
            </div>	
    {{endforeach}}
    </div>
  {{endif}}

That’s it. Your articles are now displayed as a grid which automatically collapses on smaller screen. 

And a bonus for all those who want the 2x1x1 layout from 3.4 – use this instead:

{{if count($articles)}}
    <div class='ipsGrid ipsGrid_collapsePhone'>
		{{foreach $articles as $id => $record}}
            {{if ($id == 0)}} <div class='ipsGrid_span12'>
            {{else}}<div class='ipsGrid_span6'>
            {{endif}}
			{template="entry" app="cms" location="database" group="article_grid" params="$record, $database"}
            </div>	
        {{endforeach}}
    </div>
{{endif}}

Regarding some of the requested options …

• The sort-bar. That only appears for typical listings, where sorting makes sense. If you switch the database to article mode, it disappears. So you already have the choice. 
• Articles to show: Already an option of course. As well as “categories”, “show only featured articles”, “show pagination” and things like that. Things like ratings also disappear automatically if you turn them off. 
• Thumbnail image: already an option. (“record image”)

Styling these things (e.g. the borders and width of the record image) is by default mostly left to the theme and the templates, which is actually good practice. The database and the fields are about the content, the styling comes from the theme and the templates. If you mix these things too much, it gets really messy. Then you would maybe download an additional theme (with a grid view for example) in the marketplace and and it would break your database view or the mobile view because the styling from your database and the styling from the theme wouldn’t work together. 

Thanks for the feedback, Danny. 
You are certainly right about the documentation. Pages has it’s own structure and logic of modules and without proper documentation it can be be a struggle to understand it and get good results. 

But I also disagree about some points. 

• Wizards and Template: If you add a page, a database, a field, a menu, … – you will get wizards which guide you through the setup. Templates are now easier than ever, since you just open the page builder and drag & drop everything wherever you want to. That was impossible in 3.4, where the slightest layout change would require coding. Not anymore!
• Customization. Customization requires custom code. That’s just in the nature of things. The look of WordPress posts/pages is defined in template/CSS files and if you want to make even little changes, you would have to make code changes. That’s just the way it is. More user options alone won’t change this. I would even say that Pages offers more choices than those other CMS. In WordPress you can only define the position of sidebar widgets through drag & drop, in Pages you can do that for the whole page and for every page individually. 
  Another improvement in 4.0 is the field output, which is now controlled directly in the field settings, again helping you NOT to touch the page templates. Most other standard content management systems don’t even have custom fields as a stock options.
• And lastly, where are those “tons” of forum questions about Pages with 0 replies? If the questions are understandable and can be answered with reasonable effort, I keep answering them for months.