apeisa

I figured that out, but if you want to move it up few paragraphs or down...

It looks and feels good. I couldn't figure out how to move elements like images and tables around?

Thanks Ryan. I do agree what you say. Going to direction I suggested could lead into Drupal way to manage permissions - which is called checkbox maze. I think this is the pain point and not clear enough from current screen. I like this thinking. Most of the time when you tick "page-edit" permission from template => access, you also tick create and add children permissions. But there are those circumstances where you need more granular permissions on templates and this would allow it.

I think there are some difficulties with current way permissions are handled. I think most of the misunderstood come from the fact, that certain permissions are set directly at the template => access view and others are combined from role permissions and if "edit pages" is granted from template level. Those who have been here from 2.0 (and used permissions back then) understand well why it is so - but current situation is little bit difficult and confusing. I think all the page creating / editing / moving etc permissions should be set on template => access view. So it would look like this: Access tab would have these: VIEW | EDIT | DELETE | CREATE | CLONE | ADD CHILDREN | LOCK | MOVE | SORT And default permissions would be all the others: page-template (changing templates) user-admin profile-edit I know that there comes lot of flexibility to having permissions tied into roles, but when it comes to template permissions I think it just adds confusion. Or is there any scenario where it is good to require permissions to be set first on permissions-roles level and then added again on template-roles level? Only thing it adds is possibility to have things like "you cannot allow page-editing for these roles in this template, because that role doesn't have page-editing permission in general", which leads to confusion and restrictions like diogo has above. I know this is something that I and Ryan have talked about million times, and now that I have built few more sites with little bit more challenging user access schema I am pretty confident this is a way forward.

Should this file be translatable: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Markup/MarkupPagerNav/MarkupPagerNav.module Especially prev / next labels? I know these are easy to set from template code, but it is boring stuff if you have primary lang something else than English.

One problem I noticed while using (and really enjoying!) this module. If I have this kind of structure: /news/ (tpl: news) /pw3-released/ (tpl: news-item) /ryan-looking-for-drupal-work/ (tpl: news-item) /soma-takes-over-pw-project/ (tpl: news-item) And all those pages use Simple Navigation with these options: $options = array( 'collapsed' => true, 'selector' => 'template!=news-item' ); When looking one of the news-item pages it will render the navigation just fine (excluding the news-items, but showing the "/news/" page. But what is missing is the "parent" class from the news page in nav list. Not sure if that is intended or something that is difficult to fix, but it is frustrating to lose css class there. We are still under the news-page.

I like the mobile design a lot, but I dislike that navigation was hidden.. Or at least I couldn't find it?

Pw already does that. Just put the files somewhere and htaccess will make sure Apache serves them instead of pw.

Using these module(s) it should be easy enough to build those things in templates (so no need to mess with module files). Extending or hooking into these modules is also possible (I am happy to add hooks if needed). And of course, we are here to help.

This is interesting topic, since there is this PSR movement going to make different PHP-frameworks and applications to follow same style. I do like the PW standard, but it is pretty far from the PSR-2: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md Biggest differences being using tabs instead of 4 spaces and not using Allman-style indenting. I have always preferred tabs, but it seems that it is good way to mess with version control (lot's of white space diff when people mess with spaces and tabs). Spaces are more bulletproof on that regard. Of course PSR-stuff are just recommendations, but looking at the big picture and php-community at large, it might be a good idea to slowly gear towards that? Or what says Ryan?

I am not sure I fully understand your question. Page name needs to be unique only among siblings. So your described page-tree is perfectly valid. If you were asking if this module is suitable for offering same content for differend devices, then it is not intention of this module and that could be done in template level.

Try saving the field (setup -> fields -> files) and trying then again. I have seen that "Please use on of: <empty here>" error but it has always been temporary problem. Not sure what have caused it.

In Diogo's example: <?php if ($cat->id == $page->id) echo "We are here";

Actually it says otherwise:

Wait for Nik, he has pretty insane posts to likes ratio...

Michael should comment here so we can like him! And PW coffee mug? Great idea!

Are you sure it is that exact place that is causing the warning?

The query will not be a problem. But if you need to keep those pages in memory it might be. Then just add limit or pagination. But I wouldn't be too worried.

You might be looking for something like this: $ids = "1001|1223|2311|3321"; $favs = $pages->find("id=$ids");

I don't understand how you page tree goes? What are posts and what are categories? Can you post a screenshot? It seems that you are looping through all the posts and getting categories that way -> you should loop just the categories.

https://github.com/ryancramerdesign/ProcessWire/commit/ac246677a674490f212b46fb5533ac007bf1679e

To continue from where Arjen left - I would probably create two new templates: files & file Files would get only one (hidden) page (/files/) and maybe not template file at all. No need for other fields than title either. Then file-template would get file-field, image-field for thumbnail and maybe textfield for extended summary (if needed). Then the "special glue" is to create page-field called: "files". Allow it to choose multiple pages and give it nice inputfield (asmSelect probably best here). Then configure it to have pages under your /files/ page. Then add this files-field to your "content" template and you are ready to go! On template level it would work like this (content.php): // Loop the pages you have chosen in your files-page reference field foreach($page->files as $p) { // And then echo the stuff those pages have in their fields echo "<a href='{$p->file->url}'>$p->title</a>"; } PS: The files template is not necessary at all, but it will allow you to set /files/ page to have children with only file-template. This will keep your content clean in the long run, and also it will hold a nice place if you want to extend and offer some "file search" or something like that.

What I am always confused about field groups is how would one organize the fields? You have already organized them through templates, you can filter or sort them through field type and it also excludes built-in fields by default. What kind of group labels you would have? Can field be part of multiple groups? How many fields do you have? I agree that current field listing could be snappier to use (maybe little bit of ajax etc), but I find Ctrl+F pretty quick there

Out of the interest, I compared few of the most popular/promising responsive frameworks. Gotta say that those big boys (foundation and tw bootstrap) are huge. Kube 20.4kb Skeleton 8.8kb + 1.7kb + 9.6kb ~ 20kb Foundation 85kb Twitter Bootstrap 115kb (without minification and gzip) Then I took a look at few responsive sites we have build from scratch and the amount of css was between 10kb ~ 50kb. Usually less than 20kb. Of course lot of the code from the frameworks can be removed per project basis, but that adds management overhead. Reason for this "study" was that I am looking for best possible starting point. I am thinking going for simple responsive grid / column system and some very basic typography settings, but pretty much with that. I am not keen adding 100kb CSS just for starters. I am not only worried about loading time, but about performance of mobile browsers to handle that all (specially with older/cheaper devices).

I think the 25=>24 width is just to keep the 1% margin between fields. Of course that wouldn't be an issue if box-model would be used. IMO hundred classes for different widths feels more cumbersome solution than inline widths. If you are gonna style the markup yourself, why not leave all the widths unset (does it put 100% then? I don't know) and style the widths and positioning with own css.