Leaderboard

It looks like this commit is responsible: https://github.com/processwire/processwire/commit/fc0db2bb224075e7d6e4105619a2293a5ca4b7a0 more specifically PagesLoader.php on line 1176 where parent_id is unset.

Excellent thought. I haven’t done this before, so hopefully I’ve got the details right: findMany() combined with getPage() gives pages whose parents are (incorrectly) NullPage

Ok, so I can confirm but it doesn't have anything to do with page classes - it appears to be all about getPage() together with findMany(). Here is a bare bones example with page classes disabled. Notice the change in parent between find and findMany:

@ErikMH. As requested, I have split the posts relating to your NullPage errors into its own thread ?. @bernhard, @adrian just tagging your for FYI. Thanks.

ProcessWire 3.0.197 resolves 9 issue reports and adds 3 feature requests. For details in resolved issues and feature requests, be sure to see the commit log. I'll cover a couple of my favorite feature requests that have been added this week: New $files->getCSV() method This comes by way of feature request #400 via @bernhard to add something to abstract away the redundant details of reading a CSV file into one simple method call. This simplifies the reading of a CSV file by abstracting file-open, get-header, get-rows and file-close operations into a single method call, where all those operations are handled internally. All you have to do is keep calling the $files->getCSV($filename) method until it returns false. This method will also skip over blank rows by default, unlike PHP’s fgetcsv() which will return a 1-column row with null value. Here's how you use it: Let's say we have this CSV file (first row is the header): Food,Type,Color Apple,Fruit,Red Banana,Fruit,Yellow Spinach,Vegetable,Green Here's how you'd use the new method: while($row = $files->getCSV('/path/to/foods.csv')) { echo "Food: $row[Food] "; echo "Type: $row[Type] "; echo "Color: $row[Color] "; } There are also several $options supported, see the $files->getCSV() documentation page for more. There's also a new $files->getAllCSV() method that does the same thing but returns all the rows in the CSV file in one call. Improvement to InputfieldPageListSelectMultiple Next was feature request #339 that requested adding the enhancement developed by @Robin S (via the PageListSelectMultipleQuickly module) into the core. This enhancement keeps the selectable page list open for multiple selections rather than closing it for each selection. It also better indicates when an item is selected. While I ended up writing it in a different way than Robin S.'s module, the end result is nearly identical to Robin S.'s short GIF screencast below: Also added this week is a new "visibility" option for Inputfields: Open + Locked (not editable), along with some small hook documentation improvements in the Pages class. Thanks for reading and have a great weekend!

@kongondo Nice work on the advancements!! I've been a wee bit busy, so haven't had much chance to further my setup. Do the beta testers have access to your latest updates? If so where would I grab the latest package from? Hope all is well your side! ?

Nicely done, @adrian!

OK, guys, it seems there was one more piece to the puzzle. Like @adrian, when I recreated the situation in a simple test environment running 3.0.192, I couldn’t recreate the problem. I should have tested this yesterday, but where I’d discovered that changing findMany() to find() in my code worked around the problem, I figured I’d found it. So, the following conditions are necessary but insufficient: PW 3.0.192 or greater (including the current version) page classes findMany() instead of find() I believe I’ve found the final ingredient. I have tested this in a simplified environment and recreated the problem: 4. getPage() In real life, I’ve rolled my own pagination (since I’d wanted to provide users with logarithmic-like controls for moving backwards and forwards through the site, and provide them with sign-post dates); this paginating has worked well. But it means that rather than a foreach loop I cycle through results in a for loop, and then assign the item with a getPage(). So, Adrian’s code looked like: foreach($pages->findMany('template-basic-page') as $p) { d($p->id . ' : ' . $p->returnParentId()); } but mine looks more like: $items = $pages->findMany('template=Test'); for ($idx = 0; $idx < 1; $idx++): $p = $items->getPage($idx); echo ($p->identify()); endfor; (Yes, that’s my test system, where I’ve hard-coded it to “loop” through just one test record; it’s sufficient to show the problem though: ProcessWire\TestPage #279 id: 1025 name: 'test-record-a' parent: '' template: 'Test' title: 'Test record A' data: array (1) 'title' => 'Test record A' parent there should = '1'. I see that I can do the same thing by removing getPage() altogether: $p = $items($idx); In the grand scheme of things, I don’t know which is better; however, this assignation — whether implicit or via getPage(), seems to be the final piece: add this, and $this->parent() becomes a NullPage. So, to sum up: all of this works fine in 3.0.150-or-so (where I developed it) on up through 3.0.191. As of .192, it breaks. Switching from findMany() to find() works around the problem. Sticking with findMany() and using the customary foreach() code pattern also works around the problem. Phew! @kongondo, I agree that the commit you link to looks relevant. Do you think the (implicit or explicit) getPage() may call any of that code?

That's a real shame - I thought we might have been onto something. I just tested findMany() here, calling that same method I demo'd above and everything looks fine. Does this setup demonstrate the issue when you run it on your site?

Thank you, @adrian, for that pointer. I’d had no idea that JS hadn’t been running. I’ll look into your example soon! But the big news is that I’ve solved the problem! @ryan, @bernhard, & @kongondo — thanks to each of you, too, for your encouragement and good ideas! Essentially, there is a bug, but it only presents itself when using findMany() instead of find(). As of 3.0.192, if you assemble a batch of pages with findMany() , and then call a function defined in a page-class definition on one of those pages, the $this variable in that function will have an empty parent property. By contrast, in 3.0.191, the $this variable in that function will have the proper value in its parent property. And also by contrast, in both 3.0.191 and in 3.0.192, if you use find() instead of findMany(), the function will have the proper value in its parent property. So, the bug shows up only in 3.0.192 or later and you’re using findMany() and you’re trying to find any parent-based information from the perspective of $this within a function of a page-class definition. For my own use today, I’m perfectly OK using find() instead of findMany(), though there may come a time when I’m dealing with too many records for that to work gracefully. So I can upgrade beyond 3.0.184! Thanks again to everyone for your help; I’ve learned a lot through this process. If an admin would like to break all this out (it has nothing to do with Ryan’s original post — I meant to reply initially to his announcement of 3.0.192!), I’d be grateful

@ErikMH - it's for a different script, but this page (https://csplite.com/csp217/) explains how to either disable the script in the cloudflare dashboard, or how to adjust your CSP to prevent the error. It's definitely something you'll want to fix because JS errors have a habit of breaking lots of JS everywhere, hence the issues with adminer, but I am sure it won't be the only problem.

Hi everyone, Just announcing a couple of new features that have actually been live for a week or so. 1) Guest dumps This allows any calls to bd() be() etc by guest users (regular visitors, webhook calls etc) to be logged and displayed in the Dumps Recorder panel. This panel will open automatically (on page reload) on another browser tab (where you are logged in). To turn this feature on, click the "Enable Guest Dumps" toggle button on the Panel Selector. The cog icon for this panel will change to orange to let you know it's on. There is no security risk having it enabled, but if you have a well trafficked site and it is left on, the file that stores the recorded dumps could become very large so you won't want to leave this on. This is my favorite new feature in a very long time so be sure to try it out. 2) Automatic includes Any files you place in /templates/TracyDebugger/includes/ will be automatically included. You could have a file with some helper functions or the file could have an include statement to pull in a site-wide functions file. This will give you access to any functions in these files via the Console panel.

IMPORTANT!!!!! Hi everyone. I've made a few changes in the latest version that are worth mentioning, with the first one being a possible (although unlikely) security fix. 1) A couple of the panels (User Switcher and PageRecorder) store info in the module's config settings JSON, but when using these, it would also save any of the settings set via $config->tracy. In general this is probably just annoying, but in the case of the $config->tracy['forceIsLocal'] setting (introduced in Nov, 2021), this override could also be saved to the module's main config settings. Hopefully if you have used this setting, you have only used it locally with things like Docker where the normal isLocal() method fails, but please check your sites if you have ever enabled this somewhere live. In particular I know that @teppo and @netcarver (and I think @Robin S) have been using this feature, but pretty sure still only on local machines. 2) Even though that forceIsLocal setting is potentially dangerous, I decided to add it to the config settings (with a warning) as well so it's more transparent. Note that the debug bar displays a yellow warning icon on the left side if this setting is enabled. 3) I also added a table that lists out any $config->tracy overrides in an effort to make it more obvious what overrides in place. 4) I've revamped the Log panels further with better logic to control when the yellow / red colors are applied to the icon. I have improved the sort logic within each specific log file and I have added the yellow / red highlighting to the lines that are new since you last loaded them. I have also increased the default number of lines from 10 to 100 - this makes these panels much more useful and because of other recent changes it is now performant enough to do this. Note that upgrading from an old version of Tracy won't increase this, so you might want to do that yourselves in the settings. Thanks everything and sorry for the override settings getting save to the default one issue!

And of course it has nothing to do with getPage() either :) Just all about findMany()