adrian

Would $pagefile->isTemp() be of use here? https://github.com/processwire/processwire/blob/06325993851113436b20b375a6b08cbf38230657/wire/core/Pagefile.php#L1330 I use it in CustomUploadNames

Looks like it:

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

I'd recommend you post a Github issue about this for Ryan, in case he doesn't read this thread.

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:

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?

@ErikMH - nice work narrowing it down to findMany(). Did you know there was a fix for a major issue with findMany() that was implemented for 3.0.195 - https://github.com/processwire/processwire/commit/1eb156f1aac64d388374c63cd401279f8d528481 Does upgrading to the latest dev fix the issue for you?

@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.

Just one last comment - perhaps it's a JS error that is resulting in a similar issue to what I see when JS is off. Any browser dev console errors?

Sorry if I wasn't clear - I thought you had some sites that were working with recent PW versions, so I thought if they were on the same machine you could try connect the non-working install to the DB of a site that is working. I really have no idea if this will uncover anything - just a very crude trial and error approach.

It depends on the view - Tracy makes Adminer context aware. But in the view you are seeing, it should look like this, in which case, it would be the checkbox to the left of "Table". But clearly that is missing from your screenshot. What I can tell is that based on that and some other missing UI elements, it looks like JS is disabled in your browser.

Click the checkbox to the left of "Modify" at the top of the table list.

Another crazy idea - can you point this problematic install to the DB of a site that is working in recent PW core versions? It might help to determine whether it's a problem with the DB or the core files. Maybe also try to run optimize on all of the DB tables? Adminer (within Tracy) makes this easy.

@ErikMH - just throwing out ideas here, but have you tried running: $pages->parents()->rebuildAll(); I know it doesn't seem likely given that everything works with the older PW core, but maybe worth a try :)

I know it's not really any help, but testing here on my local dev setup on PHP 8.0 and PW v3.0.193 (and I just upgraded to v3.0.197 and tested again) with this DefaultPage.php class file: <?php namespace ProcessWire; class DefaultPage extends Page { public function returnParentId() { return $this->parent()->id; // or return $this->parent->id; } } And when I call it, I get the ID of the parent page:

@Flashmaster82 - I think at this point, you just have to wait for Google to reindex your pages. Have you submitted a sitemap.xml to help with this? In the future, if you are protecting the entire site, you might want to use the ProtectedMode module and use the maintenance mode option so Google knows it's temporary and won't update its index.

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.

Hi @tcnet - firstly, I am sorry if I came across as criticizing the module - it was genuine question - I thought perhaps there was some other advantage I wasn't aware of. For example, sometimes I want to be able to access the "Database Queries", "Timers", and "Autoload" sections that are only available in Tracy when debug mode is on. I was wondering if perhaps this module allowed for that. Regarding the changes in 3.0.163 - I thought the ability to install modules being restricted to debug mode and the new $config->moduleInstall() options were both introduced in that version, but maybe I am wrong. I don't see any reason to remove the module - I was just hoping for some clarification so we all know its benefits. Thanks for the contribution!

I thought the same thing but assumed I must be missing something. @tcnet - can you please explain the advantage of this over the various moduleInstall options?

Weird - I have no idea why that would be happening - maybe it can't be overwritten in Valet for some reason? There might be a better way for me to check if the request is a response from PW page or not, but I am hesitant to change the current logic without understanding things a bit better. Any Valet experts out there who have an idea on what the best way forward is?

What does that original: bd($_SERVER['PHP_SELF'] . ' : ' . $this->wire('config')->urls->root . 'index.php'); return now?

@jploch - thanks for those. I am honestly not sure the best approach to fix this. The problem in question is this: // check if request is to a PW page - otherwise it's maybe an AJAX request to an external script $isPwPage = $_SERVER['PHP_SELF'] == $this->wire('config')->urls->root . 'index.php' ? true : false; But, I can't seem to trigger a situation at the moment where this returns false (even making an ajax request to an external script). I don't think I want to replace PHP_SELF with SCRIPT_NAME because I think that would return an incorrect result if the external script was an index.php file. Possibly you could add: $_SERVER['PHP_SELF'] = '/index.php'; to the frontControllerPath() method. I expect that will fix things, but not sure if there might be some side effects, but it might be the best solution. Let me know it that works for you.

Interesting - Valet seems to mess with PHP_SELF. Could you please find out what bd($_SERVER['SCRIPT_NAME']); returns. It looks like there might be another option around setting: 'usePathInfo' => true in general.php (https://github.com/laravel/valet/issues/340) - is that something you are familiar with? I think general.php is a file in the Valet system, but not really sure.

Hi @jploch - it looks like the issue is a problem with what $_SERVER['PHP_SELF'] is returning. Could you please add the following code to line #53 of the RequestInfoPanel.php file and let me know what is returned? bd($_SERVER['PHP_SELF'] . ' : ' . $this->wire('config')->urls->root . 'index.php');

@jploch - it should be fixed in the latest version.