Soma

So if it's an Inputfield config... you have a checkbox "fname" ? Then you also have something like $this->set('fname', ''); in the _construct of your inputfield? Or it won't work as $this->fname would be empty always. I have same code as you and as soon as I remove, $this->set('fname', ''); from the construct, the checkbox won't get checked. (This could also be set in the Fieldtype, getInputfield() where the Inputfield is loaded.) So couple ways to do configs. Also I've seen in Checkbox module, you could set autocheck: $field->attr('autocheck', 1); $field->attr('value', $this->fname); and it will get checked if value is not 0.

Ah so it's an Inputfield heh... I see now. There's a lot of ways and traps for configuration with Fieldtypes/Inputfield. ... untill you changed the name?

Anyway, this would be an form example which wouldn't be different from if in a module or not if($input->post->checkme){ $content .= "checked {$input->post->checkme}"; } $form = $modules->get("InputfieldForm"); $form->attr("method", "post"); $form->attr("action", "./"); $f = $modules->InputfieldCheckbox; $f->label = "checkme"; $f->attr("id+name","checkme"); $f->attr("checked", ($input->post->checkme ? "checked" : "")); $form->add($f); $f = $modules->InputfieldSubmit; $f->label = "send"; $form->add($f); $content .= $form->render(); So please don't hestitate to share your complete code, or we are screwed! And my example links are to examples of Fieldtypes/Inputfields ...

Urhm? $f->attr('value', $this->input_country ? $this->input_country : 0 ); you don't ever need to set 1 or 0 on checkbox fields! It's the name that you check for not the value. So seems unessecary to me. $f->attr('checked', $this->input_country === 1 ? 'checked' : '' ); $this doesn't work in my book in ColorPicker for example, it's in the $field argument sent to getConfigInputfields($field) Ah, heh just seeing my ColorPicker also has set "value" on checkbox but as said it's not necessary, and that code is old meanwhile.

In getModuleConfigInputfields – $this doesn't work cause it's static. Then you think the context is the problem? If $this->fname resolves to 1 then it does work in your code or all those modules that use this wouldn't work either: https://github.com/somatonic/ColorPicker/blob/master/FieldtypeColorPicker.module#L116 https://github.com/somatonic/AutoSave/blob/master/AutoSave.module#L95 Also looking at your code, I'm wondering why $this->fname? I don't think this works in there, unless you set the fname in the construct or init. $this->fieldname doesn't work for me anyway, so shouldn't it be $field->fname? But wondering if you can share the whole code to see not just the checkbox. Is it a fieldtype or what?

That's also nice solution and something that usually works well for smaller amounts, just doesn't scale very good and high. It just takes a lot more power and memory in my tests back then with large sets of pages (+10'000), for larger than 10'000 I couldn't even execute it on without getting out of memory , while the a direct ("parent.template=parent_tpl") takes almost no time compared.

And last some code when children would have their own template: $allChildren = $pages->get("/locations/")->find("template=child_tpl"); or even checking for parent template $allChildren = $pages->get("/locations/")->find("parent.template=parent_tpl"); or $allChild = new PageArray(); foreach($pages->get("/locations/")->children() as $parent) { foreach($parent->children() as $child) $allChildren->add($child); } and there's even more variations depending on who writes it.

So to respond to your first post again: No there's not, but yes there is. Yes. Yes.

You're right, I'm just oversaturating a little. Post title doesn't say anything. Collecting children does a little more, but we do that all the time (I got two) Well there's sometimes a lot more than just how to, it's the what and where and why that may make a difference.

You can't do children->children() cause children is a PageArray and not a single page. always page->children() Not sure what $pages->get("children=/location/")->children() is supposed to do? So you want to build a <select> dropdown on a front-end form with all 400 as options? 400 is already a lot but would be no problem foreach the children, even nested if needed. It's where it start to get slow and you notice it may take 1-2 seconds to generate, but the searching and loading with PW isn't the problem (at least with 400), it's rendering the list. So in this case rendering 400 options for a select it would be wise to output the resulting markup and caching it using MarkupCache. That allows you to cache certain parts only of a page for a certain time. That would speed up not "loading" the list everytime. After all you don't have a choice than to foreach all the pages at the end, no? Please always be more/very specific to what you need to achieve and we can help more focused instead of trying to find out first what you're doing before a valueable explanation can be done. That can be very frustrating and lead to nobody helping you anymore. Collecting id's is something different thatn building a select. I'll go focus on more important things now.

value === 1 only works if the value is an 1 integer, which is not when submitted via a form post/get. value === "1" would. So what does $this->fname contain? and if that's 1 it does work. So does it work or not? I would make sure that $this->fname is really set at that time. So there's no issue cause it's working fine everywhere in core and my modules, so it's an issue elsewhere and between chair and computer.

Depends what you want to do. Seems not like it's not something really used or needed, collecting id's of children's children for whatever reason that is. Since we have an hierarchical structure and the API children parent, siblings is build for traversing, it may won't scale well (speaking of possibly thousands of pages) iterating with foreach and "collecting" ids. Always it's like this: for having a couple pages it may ok but won't scale infinitely. So it all depends largely on the structure you have and what templates they have. Taking all this into consideration will lead to new possibilities with API. Usually of how I would have this is that the child have their own template so you could use a $locationParent->find("template=subchild"), which would scale more but still maybe an issue if you go for very large sets of pages. But if it's only for small set of pages it may ok to just foreach all children and foreach each children of the children. So having to "collect id's" always rings a red alarm: "For what, and how many?".

Also === 1, won't work cause values in post are not integers but strings... small but big difference. So for checkboxes you check if is set in post and not for value usually.

It will not get sent if not checked .. naturally. Just value=1 in source I mean. Unless u set it to something else.

Checkboxes value always is 1 whether checked or not .. Its the name that counts. For me Willie is working fine.

That's what I was trying to communicate, but no luck. It's what I do in a similar situation and it's the perfect solution to this problem. The paragraph stripper is exactly built for this. But why simple if you can make it complicated.

Thanks seb this has been fixed in the latest commit.

Couldn't resist to give my tow cents too...

But you still use language fields, so 1 page has multiple languages? The "best" way to modify the urls is to hook Page::path and prepend the lang segment. But this will only modify urls you spit out with echo $page->url and PW will not recognize these urls, so you'd have to implement another code to request the right page depending on the new url. Kinda what LanguageSupportPageNames does, so why removing it?

Or with a different parent than "/" root. ... $parent = $pages->get("/parent/"); $res = $modules->MarkupSimpleNavigation->render($opts, null, $parent); ...

With the MarkupSimpleNavigation you could do it like this: $opts = array( "max_levels" => 3, "outer_tpl" => "", "inner_tpl" => "", "list_tpl" => "", "item_tpl" => "{id}|", "item_current_tpl" => "{id}|" ); $res = $modules->MarkupSimpleNavigation->render($opts); $res = trim($res, "|"); $allPages = $pages->find("id=$res");

These guys really have balls to write something they have no clue about.

http://www.quora.com/WordPress/How-does-Processwire-compare-to-Wordpress/

No need to, read again my post: There's a paragraph stripper already coming with PW: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Textformatter/TextformatterPstripper.module$$ Just add it to the text field after Textile formatter.

If a textformatter uses fomatValue you could hook into a get the field $this->hookAfter("TextformatterTextile::formatValue", $this, "hookTextile"); ... public function hookTextile($event){ $field = $event->arguments("field"); $value = $event->arguments("value"); if($field->type == "FieldtypeText") $value = str_replace(array("<p>","</p>"), "", $value); }