Soma

Ok, looked at this situation as I wondered and had similar issues in the past. If you really want to have a checkbox inputfield checked by default in this context you have to use the uncheckedValue, checkedValue property instead to make it work. Following example works fine: $f->attr('name', 'formatting'); $f->attr('uncheckedValue', "no"); $f->attr('checkedValue', "yes"); $f->attr('checked', $this->formatting == "yes" ? 'checked' : ''); This makes sure a unchecked value is saved, instead of nothing. And default in construct then can be $this->set('formatting', "yes");

But that anyway a little special with checkboxes, you usually don't have it checked by default. Maybe I'm completely off but it's all a little tricky with checkboxes: Since when a checkbox is not checked there will be no setting saved, it's "empty", not sent etc. So only when checked it will have an value of 1 saved to db. Defining a default value of 1 in construct will not save it to db, only if you save the first time, but then it will always be 1 cause you overwrite it when it's loading. So what you trying to do is: if checkbox is empty/not set make it checked? How is this gonna work anyway when there's no value saved when unchecked? So making a default of checkbox to 1 will give hard time as when it's not checked. Not going to work. Apart from that, contrary to what you say, for me the value, when checked and saved, is save in db no matter what the default is. Instead make it inverse, by default it's on and disable it when checked.

That means this doesn't work for you? $field->attr('autocheck', 1); $field->attr('value', $this->fname); I can't reproduce this. Works fine. There's no issue, as you don't specify value = 1 for checkbox. So don't do this: $field->attr('value', 1);

Put in search.php $log->save('querylog', $q) And you'll have a log file querylog with timestamp and queries.

It's the same as "status<" . Page::statusTrash . ", sort=bla" Or "status<" . Page::statusUnpublished . ", sort=bla" Edit: edited As it has to be smaller than trash or unpublished, since include=all will also return unpublished pages.

Trash has id 7 so this should work. Do you have any other has_parent in your selector?

Yeah first! Cool, looks great, great idea, haven't been able to look at this yet as just too much going on lately...

Ah sorry for the misinforming, ok it's the value is returned by the formatValue so you grab it via $event->return. This should work: wire()->addHookAfter("FieldtypeText::formatValue", null, function($event){ $value = $event->return; $value = str_replace(array("<p>","</p>"), "", $value); $event->return = $value; });

The alternative lang fields work fine, so your doing something wrong. Are the langs really named fr it? Are the file field limited to 1 file upload?

Just don't specify a parent. It's not mandatory if you have template or selector.

If you add temporary code, to delete certain pages, to the templates/admin.php: remember to remove it afterwards to avoid headaches, facepalms and keep you healthy. Actually happened a couple times already, I'm getting older too.

Ahm, so just missed that also with my earlier posts, it's that formatValue() or format() in Textformatters arent really hookable as it stands now. What you would instead do is hook into the text fields and hook into formatValue(), which is where textformatters are run when output formatting is on. Those are hookable in the system as they contain ___. So it would look like this instead of hooking a textformatter: $this->addHookAfter("FieldtypeText::formatValue", $this, "hookTextFormating"); public function hookTextFormatting($event){ $field = $event->arguments("field"); $value = $event->arguments("value"); .... } Or in a template wire()->addHookAfter("FieldtypeText::formatValue", null, "hookTextFormating"); function hookTextFormating($event){ $field = $event->arguments("field"); $value = $event->arguments("value"); .... } So after all coming this route, it doesn't matter if a Textformatter uses format() or formatValue().

I'm not against at all with you doing it with a hook, just am confused why you choose the "extra" manual hook way over what is obviously already there and can be done via adding multiple textformatters. It's exactly designed for what you need here, so have hard time seeing the need to do extra workaround with a hook. But if it's for learning reason, why not... I'm not sure what you mean my solution is elegant? The code to add the Textformatters? Or simply using a second textformatter on the text field, which is obviously not my solution but designed best practice in PW. I think the method you have isn't hookable because it's not hookable. Does it have like "___formatValue" three underscores?

Yeah but the $user is still from the request and it's not overwriting it for $user as that was already set earlier, you may have to load it again before user is the new logged out user. $session->logout(); $user = wire("user"); if($user->isLoggedin()){ $content .= "user is logged in $user->name"; } BTW I don't trust that API gen and never use it, I would recommend to use github so cause the code you linked isn't the exactly the same in current version. Although the behaviour remains the same. https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/Session.php#L324

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.