Robin S

FYI, Ryan has pushed a fix for this issue to the dev branch.

You don't want to chain methods together like that if there is a chance that one of them will return something unexpected. What I mean is if $page->find('name=foo|bar') finds zero pages, then there will be no first() page, and you can't get the children() of nothing. So you want to break it up a bit more, e.g. $mypages = $page->find('name=foo|bar'); if($mypages->count) { $mychildren = $mypages->first()->children(); if($mychildren->count) { // do something with $mychildren } } Or seeing as you only want the children of a single page (the first) then you can shorten it a bit by using child() instead of find()... $mychildren = $page->child('name=foo|bar')->children(); if($mychildren->count) { // do something with $mychildren } (Actually, $page->find() is different than $page->child() or $page->children() in that it will find pages at any depth under $page, but in your case I think you want to get only a direct child of $page).

If I'm going to type that out I might as well create the GitHub issue: https://github.com/processwire/processwire-issues/issues/583

Not totally sure what you are asking, but you can do a sort of some pages (either as part of a selector, or using the sort() method of WireArray) or you can set the sort value of some page(s) (either by setting $page->sort to some integer value, or by using the $pages->sort() method). The sort value of pages under a given parent determines their order in the page tree if no automatic sort of children is defined on the parent template/page. And if you do "sort=sort" or $some_pagearray->sort("sort") you are sorting by the sort value. Makes sense?? If you are saying you want to go through some pages and put them in a manual order that is different than their manual order in the page tree then one approach is to set a custom property of each page to an integer and then sort by that custom property. foreach($some_pagearray as $p) { // Some code to work out $sort_int for $p so that it will go where you want // ... $p->custom_sort = $sort_int; } $some_pagearray->sort('custom_sort');

I see the issue now. It's not related to PageTable fields as such, and it affects both the "Restore the previous value" and "Unpublish the page" options. I'll add a comment in the GitHub issue.

What rule did you enter in the "Required only if" input? I tested it with a checkbox field and couldn't reproduce the issue.

Thanks, fixed now.

@celfred, I don't think I'll be able to get my head around all the facets of your PW-based game, so will just answer in general terms. First thing is that, broadly speaking, there's no reason to avoid using plain PHP arrays, functions, etc in your development if that is easier or clearer for whatever you're wanting to achieve. Behind the scenes PW will be using these native PHP types and functions anyway. So it comes down to choosing whatever you find easiest or most transparent. So by all means use WireArrays/PageArrays where you find that easiest - in most circumstances that will be the way to go. But in your code I saw some places where you are creating new Page objects that are not actually going to be saved in the page tree anywhere. As if you are just creating these pages as a way to temporarily store some data. That doesn't make much sense to me and leads me to think there is probably some better way to do it. And it also pays to think about creating some structure to your data so that if you need to debug it or come back to the code in six months time you can dump things and understand what is going on from the dump. So that's why I suggested using a PHP array where the key names and array structure reveal the purpose of what you're doing. But if you need to take the 'players' element and do other things with it in the PW API then you're right that it would be easier if it were a PageArray rather than a plain PHP array of Page objects. So you could make that element a PageArray and then add pages to it... //... foreach($allPlayers as $player) { // Define the $groupId // Use an underscore (or other non-integer) in the $groupId to force it to be a string, not an integer // That way when array_multisort() is used later the keys will be preserved $groupId = $player->team->id . '_' . $player->group->id; // Optional: add $groupId to $player as a custom property in case you need it later $player->groupId = $groupId; // Add player to a PageArray in $uniqueGroups using $groupId as key if(!isset($uniqueGroups[$groupId]['players'])) $uniqueGroups[$groupId]['players'] = new PageArray(); $uniqueGroups[$groupId]['players']->add($player); } //... Then when you later need to work with the 'players' element it is a PageArray that you can use methods like sort() on. And while looking into the issue I discovered something new: although you cannot create a nested PageArray, you can create a WireArray of PageArrays. So you could think about taking this approach if you are more comfortable sticking with PW API methods rather than doing sorting etc in plain PHP. An example of what I mean about a WireArray of PageArrays... // Create a new WireArray to hold the PageArrays $my_wirearray = new WireArray(); // PageArray number 1 $pa1 = $pages->find("template=foo"); // PageArray number 2 $pa2 = $pages->find("template=bar"); // PageArray number 3 $pa3 = $pages->find("template=baz"); // Attach some custom data to the PageArrays $pa1->data('karma', 25); $pa2->data('karma', 13); $pa3->data('karma', 37); // Add the PageArrays to the WireArray $my_wirearray->add($pa1); $my_wirearray->add($pa2); $my_wirearray->add($pa3); // If you need to sort the WireArray by the custom data $my_wirearray->sort('-karma'); // Or maybe you want to explode on that custom data $karma_values = $my_wirearray->explode('karma', ['getMethod' => 'data']);

I was able to reproduce this issue. It seems to occur when any of the pages being cloned have file or image fields in their template. If the parent page has a file/image field but not the children then setting output formatting off before cloning the page seems to work. But if the child pages have a file/image field then setting output formatting off on those children doesn't work. But I don't think output formatting should need to be off when cloning a page - the clone() docs make no mention of output formatting and don't show it being set in the example code, and indeed it doesn't need to be off unless a file/image field is present. And seeing as setting output formatting off in the child pages still doesn't allow for a successful clone I'd say this is a bug. @simonsays, do you want to open an issue for this in the GitHub issues repo?

I discovered the empty $input dump as soon as __debugInfo() was made the default dump in Tracy. Sorry, I should have raised it at the time but was in the middle of something so just changed back to the full dump setting and then forgot about it. Maybe it's just because I'm more used the full dump, but I still prefer that option. I like having more info in the dump rather than less and don't mind wading through it to find what I'm looking for.

I just thought you might have some trick, because in this post you seemed to be able to use Tracy to dump inside Page::resetTrackChanges but when I tried bd() was undefined inside that method.

Hi @tpr, any thoughts on this...

Hi @adrian, Until Ryan adds core support for loading Tracy early, what do you think about adding some Tracy option to make it easier for users to load Tracy early if they don't mind making changes to the core index.php for that purpose? Something like Tracy checks if $config->earlyTracy is true and if so doesn't load files that will have been loaded in the modified index.php. So the user only has to modify core file(s) and not Tracy files. On a related note, I'm trying to follow the suggestions you made here to load Tracy early but I can't get it working. I have these extra lines in index.php... require_once $config->paths->siteModules.'TracyDebugger/tracy-master/src/tracy.php'; require_once $config->paths->siteModules.'TracyDebugger/includes/TD.php'; require_once $config->paths->siteModules.'TracyDebugger/includes/ShortcutMethods.php'; ...and have commented out their equivalents in TracyDebugger.module, but I get this error: Fatal error: Class 'TracyDebugger' not found in D:\_Websites\_www\1testing\site\modules\TracyDebugger\includes\TD.php on line 6 Could you explain again any tricks you know for how to load Tracy early? Thanks.

@adrian, until a fix is found a workaround is to set one (or both) of the Page Reference fields to dereference as a PageArray. Related issue: https://github.com/processwire/processwire-issues/issues/152

@adrian, is there a chance that somehow the value is in fact the user being edited? You could dump the ID of $value to check. Just a guess, but I'm wondering if the strict comparison here... $value !== $this ...doesn't catch a user page because it is a object of classname User rather than just a plain Page.

I think you'll find it easier if you use a plain PHP array so that you can make it nested/multidimensional. You can't have nested PageArrays you see. I'm not sure I 100% understand your scenario, but hopefully this helps: // Get $allPlayers somehow $uniqueGroups = []; foreach($allPlayers as $player) { // Define the $groupId // Use an underscore (or other non-integer) in the $groupId to force it to be a string, not an integer // That way when array_multisort() is used later the keys will be preserved $groupId = $player->team->id . '_' . $player->group->id; // Optional: add $groupId to $player as a custom property in case you need it later $player->groupId = $groupId; // Add player to $uniqueGroups using $groupId as key $uniqueGroups[$groupId]['players'][] = $player; } bd($uniqueGroups, 'uniqueGroups'); // have a look at what's in $uniqueGroups foreach($uniqueGroups as $groupId => $data) { $uniqueGroups[$groupId]['karma'] = 0; // initialise to zero $uniqueGroups[$groupId]['bonus'] = 0; // initialise to zero // Tally up the group's karma foreach($data['players'] as $player) { $uniqueGroups[$groupId]['karma'] += $player->karma; } // Do the same for bonus //... } bd($uniqueGroups, 'uniqueGroups'); // have a look at what's in $uniqueGroups // Sort the $uniqueGroups by karma (for example) array_multisort(array_map(function($group) { return $group['karma']; // return the value you want to sort by }, $uniqueGroups), SORT_ASC, $uniqueGroups); bd($uniqueGroups, 'uniqueGroups'); // have a look at what's in $uniqueGroups See this article for a good introduction to array_multisort() - in the code above array_map() is used to get the sort values instead of another foreach().

This CSS seems to be working well for me so far... #tracy-debug-bar { position:fixed !important; left:auto !important; top:auto !important; right:0 !important; bottom:0 !important; }

That screencast is with the latest version (4.10.19).

Hi @adrian, I'm experiencing an issue with Tracy in AdminThemeUikit (I don't remember it happening in AdminThemeDefault) where the debug bar forgets its position between page loads. I normally keep the debug bar at bottom right, but it forgets this and jumps up to the top left (sometimes other random locations too). It seems to be related to opening a modal window, with Tracy enabled for modals. See in the screencast below how after opening and closing the modal then reloading the page Tracy is now at the top left of the screen. Hopefully not too tricky to fix. If in fact it is tricky, I wouldn't mind an option that keeps the debug bar locked in the bottom right because personally I never move it from there. Edit: it does happen in AdminThemeDefault also. Funny, because I always have Tracy enabled for modals and I don't remember this occurring before. Maybe a side-effect of a recent update to the module?

If the hook is removed then it will fix the issue I was seeing, because with the autocomplete attribute being on the password fields those fields aren't autofilled by Chrome. So if the extra condition you added to the JS prevents your generated password from being cleared and you can therefore remove the hook then it will be all good from my end. I guess if/when Firefox autofills the password field it doesn't affect the value attribute? I can't test it here because I can't get Firefox to autofill the password field anyway (or I just don't know what steps are required to reproduce the issue on that browser).

I guess the issue is because of how you are assigning $r. When you assign like this $r gets the value of $p->repeater but is otherwise not connected to it. The PHP manual says: So when you add an item to $r you are not adding it to $p->repeater. Does the problem resolve if you assign $r by reference? $r = &$p->repeater;

Sure, is now pending approval approved for the directory.

Are you positive the   is not actually there in the source? Not sure what tool that screenshot is from but some tools will decode HTML entities in which case   would just display as a space between words. Also, I can see an inline color style in your screenshot - is that coming from Javascript perhaps? If so, disable all your Javascript to make sure it is not responsible for converting the   entity.

A couple of things that might be relevant to the problem: 1. $cache is an API variable (WireCache) - better not overwrite it with something else. 2. WireCache provides everything that the MarkupCache module does plus more. Maybe consider using WireCache instead.

Welcome to the PW forums @Jules Vau Probably silly question, but you are entering   right? It is working for me with the same settings as you show above (although I didn't enter anything in Extra Allowed Content as that shouldn't be needed in this case). I tested in 3.0.99 but I don't think anything has changed in this regard since 3.0.96.