Soma

I'm not sure, but it may doing something when trashing a page and save that page again so it ends up in trash. Very likely. Your solution is perfect to go. But maybe you can aslo just use the Pages::trashed instead as this would be just once after the page is trashed.

I haven't tried this module on blog profile, but you can edit the form id in the module settings.

Just in case. This login code in here with custom login code, will break if login throttle is enabled and kicks in: See here for how to handle this: https://processwire.com/talk/topic/107-custom-login/?p=58627

Just wanted to mention it also here that all front-end login code posted mostly in this forum has one flaw. The problem is with the login throttle that once it's kicking in, you'll get an WireException thrown and interrupt your login as you will only see this error and nothing else. There's a thread where this was asked and the solution is to use a try/catch to perform the login, this way you can catch the error message and output it where you want it. Looks like this try { $u = $session->login($username, $password); if($u && $u->id){ // user logged in do something $session->redirect("/profil/"); } else { $errors .= "Login failed."; } } catch(WireException $e){ // in case of multiple false login (throttle login) $errors .= $e->getMessage(); // get the error message } There was a mention here https://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/?p=50501

Logout need a refresh/redirect to reset session and user. https://processwire.com/talk/topic/1559-login-big-problem/?p=14153

What version of PW are you using? Cause there was a problem with alternative language file fields that was fixed not so long ago.

I don't really get the reason why not? There must be a reason why you restrain from adding the second Textformatter that does exactly what you want? foreach($fields->find("type=FieldtypeText") as $f) { $f->textformatters = array("TextformatterTextile", "TextformatterPstripper"); // add textformatters $f->save(); } Done. Not sure why your hook isn't working. You mentioned that you modified the textile formatter, how and where? Make sure it is really called TextformatterTextile.

Hm, I've never said 400 is too much, just that it will take some time to load and you could use markup cache Ryan does the same I guess for the modules.processwire.com dropdown with all 250 modules (actually maybe just ProCache anyway)

Maybe it will help somebody. Jaja.

Maybe because integer is int and not bigint or tinyint? Edit: Sorry, wasn't reading all thread, hehe. Agree it would be nice feature to have more options to integer, although not often needed that's maybe why it's still missing?. Also there's a min-max setting though uncommented in integer module.

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.