tiagoroldao

Very nice! I would only replace the 4 stripes symbol for pages with children with an arrow, maybe, to make it clearer that it is expandable.

It seems a bit biased towards Foundation, this one... It's not that the author doesn't try to be objective, but the comparison seems at times to be between BS2 (and not BS3) and Foundation... For instance - BS3 is mobile-first. And it isn't just an add-on they glued to the 3rd installment, it is the main reason for v3 (and for how long it took). Also, the article implies that while BS3 has forceful fixed-width columns, Foundation doesn't, when it is the other way around - while BS3 gives you the choice between fluid and fixed rows (being that both respond to the same breaking points), with Foundation there is no fixed-width row option. It is relatively easily implementable but still.. --EDIT-- Only after writing this did I notice "Updated to Foundation 5 and Bootstrap 3" - Being that this was probably a comparison between older versions (and being that BS3 was a complete overhaul), it explains the biases I noticed...

onjegolders: Bootstrap 3 levels the playing field on the grid thing - before I'd totally have to agree (even using bootstrap over Foundation). On these new versions, they are pretty much on par with one another - though I find Bootstrap (and specially Bootstrap 3) to be friendlier with 3rd party scripts and the like..

It seems too much of a case-to-case thing here - if I was to use a "tag" Template, for instance, that had no template file (as I many times do, as I handle tag/date/search based page viewing on a parent template, generally), it would be terrible to have something like this enforced. If a flag is what is needed, a global boolean value would do the trick. But assuming any $pages->find() would not return file-less pages seems to me to do more harm than good.

Well, yeoman is a pure client-side stack, meaning it isn't made for backend programming at all. It is pure JS. What I did was set up two distinct projects for the frontend and the backend, respectively: I set up my PW templates as RESTish servicessingle php file with GET based logic for simple items php file + same name folder of related assets if it is something more complex And my UI as a yeoman project, that exports to templates/ui Then linking the two is just a matter of calling it in home.php: <?php include("./ui/index.html");?> Remember, yeoman is strictly frontend, and in general only caters to single-page-app type projects. But for that scenario, it is amazing!

Damn you, american projects that don't ship abroad!

Ok, so I forgot to do the obvious, and test the original problem. (I never used repeaters much)... Why do you say repeaters can't have page fields? I just tested is and it works fine! (screenshot to follow, my dropbox is acting out...) eheh... What Apeisa said!

Simple change in the InputField (InputfieldURL.module): public function ___render() { $rootUrl = $this->config->urls->root; if($this->addRoot && !$this->noRelative && !$this->notes && strlen($rootUrl) > 1) { $this->notes = sprintf($this->_("Start local URLs with \"/\" and leave off the \"%s\" part."), $rootUrl); // Instruction for local URLs displayed when site is running from a subdirectory } $out = "\n<input " . $this->getAttributesString() . " />"; $value = $this->getAttribute("value"); if(!is_null($value) && $value !== ""){ $out .="<p class='notes'>WebSite <a target='_blank' href='".$value."'>here</a>.</p>"; } return $out; } renders as: I had never thought of this, although there have been times where this would have been beneficial. This seems something worthy of adding to the core (maybe not done in 2 minutes like mine )

You could allow for each sub-page to have "team role" pages as children pages. These would have a role (either by using a simple text field like their title or a page field) and a multiple page field of users. So: AboutArea PageRole page (title: "senior" or "role" page field set to a the "senior" page) with list of users in a page field Other Role page Alternatively, you could use something similar to the any role system, but regarding roles in different Areas. So you would have: AboutArea PageRole page Other Role page And Another And each user would have a page field allowing for "Area_role" type pages. This would be better to give users control, but not to manage the roles. Hope these are of any help/inspiration.

The problem is that double spaces in html are meaningless - they are ignored completely. With good reason too - if whitespace in html code had meaning, you couldn't indent elements without impacting on the end result. Explanation here: http://stackoverflow.com/questions/433493/why-do-multiple-spaces-in-an-html-file-show-up-as-single-spaces-in-the-browser Why do you need to keep double spaces (without conversion to the html entity)? --EDIT-- Untested, but try something like this: <?php /** * If it works, Copyright Tiago Roldao * If it doesn't, I have no idea who made this */ class NonBreakingSpaceRemover extends Textformatter { public static function getModuleInfo() { return array( 'title' => 'Non Breaking Space Remover', 'version' => 100, 'summary' => "Converts html non breaking spaces back to normal spaces. ", ); } public function format(&$str) { $str = trim($str); if(!strlen($str)) return; $str = $value.preg_replace('/ /', ' '); } } Install it as a module, try it out, change it if it doesn't work. Again, completely untested, but a simple variant of the Newlines to List Textformatter, so it should work fine

I never had troubles with any lack of examples (and to be honest, the forum is incredibly useful, which is very rare...) but I came across PW with some experience in php programming already, and didn't need them that much. But... Being mostly a Javascript dev these days, I came to like the concept of the cookbook which is popular in JS frameworks and such. Basically step-by-step development guides for basic or typical things (like the guide to doing the buildings site, or a guide to doing a custom field, module, or hook...) It could be a nice introductory step, actually.

You could absolutely do a repeater, with the image field restricted to one image (so that each image corresponds to one text field in the repeater). But this problem has been tackled very well by Ryan, here: http://processwire.com/talk/topic/417-extending-image-field/ Also, I've been given this suggestion some time ago, and it has been very useful: the forum search engine isn't the greatest, but if you search in google, with something like "my search site:processwire.com" it can be a whole lot better

Yes, I solved it with: $pages->find("parent=$page, tags=$tag, limit=1, start=0")->count() The "start=0" was just to make sure it went well, as PW 2.3, as far as I know, doesn't paginate queries with limit=1. I don't think that's it. But I may be looking at it wrong: Shouldn't $pages->count() not be paginated? And I find it strange that this scenario occurs: If I have 100 pages spread out across 10 pages, 50 "a's" and 50 "b's", and do a $pages->count("parent=theParentOfThe100Pages, tags=a") in one of the 10 pagination pages, if there is at least one "a" page, the $pages->count() returns 50, but if there is no "a" page in this particular set of 10, $pages->count() returns 0. One extra question: If all queries are paginated, imagining I'm in /page10 of the pagination, showing pages 91~100 of my list. If I were to do a $pages->find() on an unrelated group of pages, using the same limit=10, but on a group of pages with 50 pages (effectively having 5 pages of results), what would happen? would the result be an empty array, from page6 onward?

I'm still concerned about this - I solved my problem, but I still consider the original issue to be a probably fixable bug.. Where should I submit it?

Didn't consider that, horst! Thanks!