bernhard

Or just use $this->log('foo bar'); https://processwire.com/blog/posts/processwire-core-updates-2.5.15/#new-log-and-this-gt-log-text-api-functions

Hey Robin, I wonder what you think about this approach: This could also be packed in a module and I think the behaviour is a little bit easier to understand (checked is checked ? ). Maybe you tried something similar and found some drawbacks with this simple approach?

What about this? $wire->addHookAfter("Pages::added", function($event) { $page = $event->arguments(0); // check for page template if necessary here $page->setAndSave('check', 1); }); PS: Did you see @Robin S module?

https://github.com/adrianbj/TracyDebugger/blob/master/TracyDebugger.module.php#L2736 Learn from the best ??

Maybe, but maybe not. It would be an easy fix on the PW side and maybe a not-so-easy fix for Intelephense. It should not have any drawbacks and maybe has other benefits as well (like correct syntax highlighting by default, especially if the editor does not support file extension mappings). It seems that newer modules are already using .module.php so it would just be consistent to always use .module.php ?

?? I'll file an issue on github. Let's see what ryan thinks of renaming all those files to module.php https://github.com/processwire/processwire-issues/issues/860

Anybody? Does it also not work for you guys?

Thx adrian, that does indeed take care of it! Thx. Agree that this should be accounted for!

Hm. Well - doing a modules refresh is also a fix, but I don't think that this is how it should work... Any other opinions?

I'd call that "everything" ?

Hi everybody ? Playing around with a new PW Project... I installed the blank profile + Tracy + AOS, nothing else. Then I enabled Language Support and installed @jens.martsch 's translations. I enabled the AOS lang switcher ( @tpr ) and changing language works all fine except the menu, which changes only after a modules refresh. I tested changing the language via the user's settings (not AOS) and it's the same. Did you ever realize the same problem? Or do you think that this is not a problem? I'd call this a bug, so if anybody confirms that I can file an issue on Github... Thx!

Don't see anything wrong with that ?

Nice! ? On mobile, but you can even make it simpler by using 'moons' => $planet->planet_moons->each('title') See the API docs for WireArray. It has some nice features ?

You are saying "parent" here, but according to your explanation you are not looking for the "parent" (in the PW meaning), but for the page containing the reference to istanbul, correct? Such things depend a lot on your setup of the page tree. This might be a good read: If you have a setup like this (I guess that's your setup?) /countries (tpl=countries) /countries/austria (tpl=country, referenced cities: vienna,salzburg) /countries/turkey (tpl=country, cities: istanbul, ankara) /cities (tpl=cities) /cities/vienna (tpl=city) /cities/salzburg /cities/istanbul /cities/ankara And you visit page "vienna" the selectors could be: $page; // vienna $country = $pages->findOne([ 'template' => 'country', 'cities' => $page, ]); $siblings = $country->cities("id!=$page"); But it might make more sense (or might not) to sturcture your pages like this: /countries (tpl=countries) /countries/austria (tpl=country) /countries/austria/vienna (tpl=city) /countries/austria/salzburg /countries/turkey /countries/turkey/ankara /countries/turkey/istanbul Then it would be: $page; // austria $country = $page->parent; $siblings = $page->siblings("id!=$page"); This setup would have the benefit, that you can never assign one city to two countries. Well - if that is what you need, the other approach could make more sense (https://en.wikipedia.org/wiki/List_of_divided_cities) @elabx s is also correct, but $page->id is actually not necessary, because when you put your $page variable in the selector string, it will automatically return the page id ? Other than that it's a matter of preferance if you use array syntax or not or if you use "id!=$page" or ->remove($page) ?

Thanks for bringing this to my attention @szabesz! My favourite: Best wishes to him, best wishes for ProcessWire and of course best wishes to you @cstevensjr and your project! ? PS: @cstevensjr is there a way how we can subscribe to new topics on your site?

Thx to @Robin S I realized that GitHub now also offers unlimited private Repos for free. In some discussion about it I found another interesting alternative (if you don't want to host private code on external servers): https://gitea.io/en-us/

OK great for PW, bad for solving your problem ? Then I'm out of ideas, sorry ?

This statement seems like you didn't get what I tried to say. Means that you have maybe selected page 1018 in the page-reference-field "planet_reference" of page 1018. That means the planet_reference of 1018 points to page 1018 (itself) and could maybe end in an endless loop? No idea if that is possible and it would throw such an error. I think PW should be clever enough to prevent such errors. If not, that would be worth an issue report!

Sure! Thx ? I missed the memo it seems. Which ones are these? I'm talking about a new Grid module (or a Chart module or the like) that needs some javascript events to work: I think it would be nice to have some kind of base module that we can easily extend to our custom needs, but that does have some standards built in for things that can get complicated when building your own fieldtypes. I'm talking of all those tedious edge-case scenarios that make our lifes hard, like charts not updating it's size when resizing the window, grids not getting initialised when the field is loaded via AJAX, fields breaking when they are in a tab that is not shown on the initial page load. I think it would make sense to have some tested and reliable standard javascript events for all those situations. Or maybe I'm wishing something here that is not really possible? ?

I think even if that was the case it should not end in such an error, but I don't have time to test it right now and maybe others will have better ideas ?

Is planet_reference of page 1018 pointing to itself? BTW: Use dump() or the shorthand d() better than echo in the console ?

Hi @Manuel and welcome to PW and the forum ? I don't see anything strange here. Could you paste the whole code? Are you sure you don't have any endless loop somewhere? I'd also recommend that you install TracyDebugger - you can try snippets like the one posted above easily in the console: https://adrianbj.github.io/TracyDebugger/#/debug-bar?id=console

Hi @Robin S I've just tried your example, because I'm always using ProcessPageEdit::buildForm for such things. In my case your hook fires twice on a regular page edit and three times on an multilang field with two languages... Any reason why you are using Field::getInputfield and not ProcessPageEdit::buildForm like in this example that I've just posted:

$wire->addHookAfter('ProcessPageEdit::buildForm', function($event) { $page = $event->object->getPage(); if($page->template != 'home') return; // example if($page->isUnpublished()) return; $form = $event->arguments(0); $field = $form->getChildByName('title'); // example $field->collapsed = Inputfield::collapsedNoLocked; }); ?

Well... me neither. I'd also prefer to have one common and stable solution, so if you are now willing to accept those changes (I also read the thread again and was confused by my own explanations sometimes. One point was misleading (that I was requesting to place the files in the module's folder which would break on every update, of course) and it's always a little hard to have such conversations via internen + non-native language ? ) I'll try to send a PR for your module as soon as I start working on the related modules!