NullPage Errors when dealing with Parent Pages

[ErikMH]

I’ve been running 3.0.184 for a while now, so it’s possible that new errors that I’m seeing are due to an intervening change, but with 3.0.193 I’m getting lots of NullPage errors when dealing with parent pages (and, I’m guessing, other related pages) in methods defined in custom page classes.

For example, this code worked perfectly in 3.0.184:

public function getEntry() {
    $me = wire($this);
    $parent = $me->parent;
    $theHTML = "<h3>{$parent->getTitle(true)}, <span class='small'>{$me->getTitle(true, false)}</span></h3>";
    ...

In 3.0.193, the $parent->getTitle(true) causes

Exception: Method NullPage::getTitle does not exist or is not callable in this context

I cannot seem to create a parent object at all. Is this faulty coding on my part? Or an as-yet-unsupported part of 3.0.193 lazy loading?

Thanks!

[ErikMH]

7 hours ago, ryan said:

I'm not aware of any recent changes that would affect pages in that manner. But for your code, I would drop the $me = wire($this); there is no $me, there is only $this. ?  And rather than referring to $me->parent; refer to $this->parent(); with the parenthesis, so that it is a method call rather than a direct access property. Since you are "inside" of the Page class here, the interface is a little lower level than if you are outside of it. Usually it doesn't matter but in this case of things like "parent" I think it might be safer to method calls rather than properties, because these things are dynamically loaded and so accessing the method ensures that happens. 

First, thank you very much, @ryan, for your code pointers. I’m not sure how I’d fallen into the habit of $me = wired($this);, but my custom-class code was riddled with it. I removed it all, and changed all references to ->parent properties to ->parent() method calls. On 3.0.184, this sped up most page loading by about 10% (hooray!), but had no other discernible effect. It’s a testament to ProcessWire’s efficiency that I haven’t ever felt the urge to go hunting for speed improvements....

Anyway, I then attempted to upgrade to 3.0.193 — and immediately was presented with NullPage errors.

So I tried 3.0.189, which ran fine. So too did 3.0.191.

I was becoming pretty sure the problem was going to be introduced with 3.0.193, but I tried 3.0.192 — and boom!

So, this is code that I’ve been running in production without incident since last June, but 3.0.192 is causing major difficulties, which continue with 3.0.193.

I don’t see anything wrong with my code (but, then again, I’m the guy who put $me = wired($this) into all his custom classes). I’ve looked at the descriptions of everything between 3.0.191 and 3.0.192 on GitHub, but nothing stands out as related. It’s late here now, so I’ll write up a summary of the logic that’s causing the problem tomorrow morning, but essentially a custom class method is called, correctly, and it’s now failing to run — giving an error that the method isn’t callable because the object is null. But it’s not null — and I get exactly the (non-null) results I expect up through 3.0.191.

Here’s a link to 3.0.192 on GitHub. I’d be very grateful if anyone can give me further guidance (or figure out which bit of 3.0.192 is responsible). I’ll post more details in about 12 hours.

[administrivia: Clearly, therefore, this problem doesn’t belong in this thread; I’d be happy if someone could split it out and put it somewhere appropriate.]

[ryan]

@ErikMH The line producing the error you mentioned is making a $parent->getTitle(); call. What is getTitle() ? That's not a PW Page method, so I'm wondering if that's a method you've added in your custom page class? If so, and you called this on the page representing your homepage. The value of $page->parent would correctly be a NullPage, as you are seeing there. So even if we track down an issue causing this particular instance, I'm thinking you'll want to update your code to account for the possibility that a getTitle() method may or may not be present. Maybe this?

$parent = $this->parent();
if($parent->id && method_exists($parent, 'getTitle')) {
  $theHTML = '...';
}

 

[ErikMH]

Thank you for pursing this with me, @ryan! I was swept away by various events today and wasn’t able to to add more details until now.

All of my custom classes are subclasses of a class I call vsPage, which itself extends Page. I make sure to add stub methods to vsPage such that, if I inadvertently call an undefined method, it’s dealt with gracefully. In the case of getTitle(), I’m actually intentionally using the method inherited from vsPage: getTitle() gets the page’s title, falls back to its name if title is empty, and adds some punctuation and a subtitle field, too, if it exists and is populated.

The page’s parent uses a different template (not home!), which is also a subclass of vsPage.

I’ve double-checked home.php, and getTitle() is never called on anything there.

I’ve double-checked every custom class PHP file, and everything is either directly or indirectly inherited from vsPage, where getTitle() is defined.

I’ve changed the line so that it calls getTitle() only on the page itself, rather than on its parent, but I still get the same error. I then reversed course and changed the line so that it calls getTitle() only on its parent, and not on the page itself, but I still get the same error.

I’ve commented out the line altogether in IssuePage, but the equivalent line in PostPage (see below) causes the same problems. And once I’ve commented out all calls everywhere to getTitle(), I begin hitting the equivalent error with another method, markupALikeness().... Essentially, I seem to be unable to call custom class methods at all.

getTitle() works exactly as I mean it to (through 3.0.191) for every template class that I throw at it. No errors are reported in 3.0.191, AFAICT, even with debug mode and Tracy Debugger on. You can see the live site (running 3.0.184) at https://tolkienists.org/. The title of each entry is formed via getTitle(). For the next twelve hours or so, the first three entries will be:

1. Beyond Bree, February, 2022 — a journal issue (IssuePage extending vsJournal extending vsPage extending Page)
2. № 196: Chad Bornholdt — a blog post (PostPage extending EntryPage extending vsPage extending Page)
3. The Great Books № 214: The Hobbit by J.R.R. Tolkien — another blog post; this one shows the subtitle that gets added to the title via getTitle(), in fact.

This same page running 3.0.191 on my test machine looks exactly the same.

Since I use this method in constructing entries on basically every page on the site, I haven’t yet seen a single page generated in 3.0.192 or 3.0.193. Instead, I get this:

Call Stack
#	Time	Memory	Function	Location
1	0.0001	377648	{main}( )	.../index.php:0
2	0.1780	7369472	trigger_error( $message = 'Exception: Method NullPage::getTitle does not exist or is not callable in this context (in /home/716930.cloudwaysapps.com/aqewnfhddd/public_html/tolkienists-org/public/wire/core/Wire.php line 564)\n\n#0 /home/716930.cloudwaysapps.com/aqewnfhddd/public_html/tolkienists-org/public/wire/core/Page.php(1809): ProcessWire\\Wire->___callUnknown()\n#1 /home/716930.cloudwaysapps.com/aqewnfhddd/public_html/tolkienists-org/public/wire/core/Wire.php(420): ProcessWire\\Page->___callUnknown()\n#2 /home/716930.cloudwaysap', $error_level = 256 )	.../index.php:64

Well well… Error: Exception: Method NullPage::getTitle does not exist or is not callable in this context (in wire/core/Wire.php line 564)
#0 wire/core/Page.php (1809): Wire->___callUnknown()
#1 wire/core/Wire.php (420): Page->___callUnknown()
#2 wire/core/WireHooks.php (951): Wire->_callMethod()
#3 wire/core/Wire.php (485): WireHooks->runHooks()
#4 wire/core/Wire.php (488): Wire->__call()
#5 site/classes/IssuePage.php (43): Wire->__call()
#6 site/templates/home.php (95): IssuePage->getEntry()
#7 wire/core/TemplateFile.php (327): require('/home/716930.cl...')
#8 wire/core/Wire.php (414): TemplateFile->___render()
#9 wire/core/WireHooks.php (951): Wire->_callMethod()
#10 wire/core/Wire.php (485): WireHooks->runHooks()
#11 wire/modules/PageRender.module (571): Wire->__call()
#12 wire/core/Wire.php (417): PageRender->___renderPage()
#13 wire/core/WireHooks.php (951): Wire->_callMethod()
#14 wire/core/Wire.php (485): WireHooks->runHooks()
#15 wire/core/WireHooks.php (1059): Wire->__call()
#16 wire/core/Wire.php (485): WireHooks->runHooks()
#17 wire/modules/Process/ProcessPageView.module (183): Wire->__call()
#18 wire/modules/Process/ProcessPageView.module (114): ProcessPageView->renderPage()
#19 wire/core/Wire.php (417): ProcessPageView->___execute()
#20 wire/core/WireHooks.php (951): Wire->_callMethod()
#21 wire/core/Wire.php (485): WireHooks->runHooks()
#22 index.php (55): Wire->__call()
#23 {main}

I do understand that we’re not paying you big bucks to troubleshoot our code — but I’m at a complete loss as to why the changes included in 3.0.192 are causing these problems for (apparently!) only my site. Of course, there probably aren’t a lot of us using custom classes, but still....

Please let me know if there’s any further information I can provide or if you have any more ideas. I’d hate to be stuck forever at 3.0.191!

Many thanks!

[ryan]

@ErikMH Thanks for the additional info. I'm not yet sure what the issue could be, as I also use custom page classes here, but I I think by getting yours working we might find closer where to look. And I think to do that, some additional checks are needed in your code, which I'll try to describe below. 

The error message you've got appearing (that there is no getTitle method on NullPage) is a valid error message, as it is true that NullPage has no getTitle() method. NullPage is a valid return value from any Page method that can return a Page object. So we know at least that there is a line of code somewhere that is calling a getTitle() method before checking if it has a Page that would have that method. You can check for a NullPage by: if($p instanceof NullPage) { ... } or more commonly you can do: if(!$p->id) { ... }. That works because NullPage objects have an id of 0. 

In the debug backtrace we can see that home.php line 95 calls IssuePage::getEntry(). And then IssuePage.php line 43 is likely making a call that is returning a NullPage. I would add a NullPage check before calling getEntry() (home.php line 95) and then another on IssuePage line 43. That should prevent the error from occurring, and is something you'd want to have whether you were seeing this error in the first place or not. And by identifying specifically what change seems to fix the issue, that should point us in the direction of what method call might be returning something potentially incorrect (since you indicated it worked in earlier versions but not in the current). 

Once you identify the culprit, it would be helpful for us to know what that condition is where it's coming across the unexpected NullPage. So let's say $p is the page you are calling something on (like your getTitle), you might do something like this:

$title = '';
if($p->id) {
  if(method_exists($p, 'getTitle')) {
    $title = $p->getTitle();
  } else {
    bd("Page $p has no getTitle method (called from page $this)");
  }
} else {
  bd("Unexpected NullPage received in page $this"); 
}

 

[ErikMH]

Thank you so much, @ryan! I’ll methodically add these today and see if I can’t pin this down....

[ErikMH]

Well, I have some answers, @ryan, though I do not understand them.

home.php

In my home.php file, I create a selector that looks for the most recent pages of any of a half-dozen different templates. It sorts first by date, and then by template. I then, of course, cycle through the resulting pages and create HTML for each.

I have now added checks for null (via the ID shortcut — thank you!) for each of the returned pages: no errors were reported.

In each case, I refer to the item’s parent. I have now also added checks for null for each of these parents: no errors were reported.

IssuePage.php custom class

It happens that the first item’s template is “issue,” so I began with IssuePage.php. I added a check to make sure that $this itself was not null, just to be thorough: no errors were reported.

Again, one of the first things I do then is find the page’s parent and set it to $parent. I’d already changed this logic a couple of days ago to do it properly as a method call:

$parent = $this->parent();

I then added a check to $parent to make sure it’s not null.

First, I loaded the home page in 3.0.184. $parent was not null, and the relevant information from the parent record was generated and displayed properly in the HTML.

Then, I loaded the home page in 3.0.192. $parent was null.

$parent should definitely not be null. Here is an image from the back side, showing the “February, 2022” issue whose parent is Beyond Bree.

And here is another image, showing the issue as one of Beyond Bree’s children from the editing panel:

There is nothing unusual about these records. If I delete them, I get the same null-parent-result on a PostPage class page whose parent is a BlogPage.

So, in short — there’s something about 3.0.192 that causes $this->parent() consistently to return NullPage instead of $this’s parent.

Thank you so much for walking me through the proper way to debug this! Is there anything else you’d like me to do?

[ErikMH]

OK, I’ve returned from business trips and have finally had some time to pursue this further.

I made a slight error in my last post here. As of 3.0.192 (and all subsequent versions through 3.0.196, at least), $this->parent() (in the context of page-class PHP files in the “Classes” directory) isn’t actually null; rather, it’s always empty, with an ID of 0.

It doesn’t matter what the class of $this is, and it doesn’t matter what class its parent really is within the system. $this->parent() always gives me an empty page with no template and an ID of zero.

Somehow, getting $this->parent() was broken with 3.0.192. I can build lots of checks into my code so that I can render a page without errors (and I am, in fact, doing that) — but I still need the original functionality restored.

Is there some alternative way I should be referring to the instance’s parent? Or is there some way we can restore the functionality that we had up through 3.0.191? I’d be very happy to help, but I’m utterly unable to pursue this any further alone.

[ErikMH]

I’ve adjusted my code, hoping to find that $person = $this->wire('page')->parent(); would work better than $person = $this->parent(); — but the result is (unsurprisingly) identical: both of these work perfectly in all cases in 3.0.191, but consistently return an empty page whose id = 0 in 3.0.192 and later, no matter what $this’s page class is and no matter what $this->parent()’s page class is.

[bernhard]

Hey @ErikMH I haven't read everything in detail and I don't know what's going on here but my first recommendation as always would be to install tracydebugger. Once you have tracy you can do this:

bd($this);
bd($this->parent());

Then see what is shown in your debug bar (right bottom corner). Can you share that output with us?

Are you maybe in a method that is called from a hook? Then $this would not refer to the current page so $this->parent() could lead to nowhere. Not sure why it would work on older versions of PW though, but at least that are some ideas.

[ErikMH]

Thank you for replying, @bernhard! I do always run Tracy Debugger [on my development server], though tbh I really haven’t figured out how to use it other than to be aware of the helpful execution time figure which helps me keep my code comparatively lean.

This is not called from a hook; rather, it’s a function in a class definition in the /classes/ directory. $this itself as a variable is working fine — referring to the instance of the subclass, which is of course a page.

I added the bd commands you listed into one of the class functions attempting to find $parent, and discovered the little orange shopping-cart icon. (This is how Tracy denotes dumps? Interesting.)

When loading my site’s home page in 3.0.184 I see 16 dumps, which makes perfect sense: I had added those bd commands to the “Post” page class, and currently eight posts are among the items listed on the home page. So each post dump is followed immediately by a dump of its parent. Though I’ve never seen this layout or used this portion of the tool, it all makes perfect sense and is exactly what I’d expect to see.

Now, if I upgrade to 3.0.196 and reload the same page, I again see 16 dumps. Eight of these are the same eight posts — and they look exactly the same. Their parents, however, all look like this:

ProcessWire\NullPage #???
id: 0
name: ''
parent: ''
template: ''

where ??? is different in all eight parent records. This number is not the record’s ID — I really don’t know what it represents. It is not the same number that Tracy Debugger reports along with the good-looking parent data in 3.0.184. If I click on the disclosure triangle, there is lots more data — but almost everything is blank or 0 or null.

I’m thrilled that I now know a little more about running Tracy Debugger — thank you for that! But I don’t think it’s telling me anything new: $this->parent() is null (or empty or something) instead of $this’s parent. Is there more sleuthing I can do?

[bernhard]

I think the next step for debugging this would be to setup a new project without any modules other than tracydebugger and see if you can come up with a reproducable example. You can then share this custom page class with us and we can see if we get the same results and can help debugging.

[kongondo]

Very wild guess here. I'm just wondering what major thing changed between 3.0.184 and 3.0.192? When I read about the lazy loading issues here, I am just wondering if there is a connection. Just a very wild guess. @ErikMH, are you able to upload the code that is not working to some gist or here for us to play with? I haven't followed the whole of this thread so apologies if I have missed it.

[ErikMH]

Thanks for your interest, @kongondo! In fact, I was able right from the get-go to pin it down to the difference between 3.0.191 and 3.0.192; I mentioned 3.0.184 recently, though, because that’s the last master release before things break for me. Here are the 3.0.192 commits on GitHub, which I linked to above.

@bernhard, I decided to go all in on your suggestion of a new project:

• I created a new server (“Ori”) running 3.0.191.
• There, I created two templates (“Parent” and “Child”), and set them up in their family tabs so that only “Child” could be the child of “Parent” and only “Parent” could be the parent of “Child.”
• I turned on page classes, and created ParentPage.php and ChildPage.php files in the site/classes/ directory, setting each up as a subclass of Page.
• I created a public function in each (identify()) which returns a small definition list that includes the template and the ID of $this.
• I then created a page of template type Parent, and gave it a child of template type Child; in each case, the template calls the page’s identify() function and echoes it into the HTML, and it checks whether its parent record has an identify() function and echoes its results out, too.

As expected, when I load the parent page on the front-end, I see that its template is Parent and its ID is 43 — and no information is provided about its parent (which would be the home page, which doesn’t have an identify() function).

Also as expected, when I load the child page on the front-end, I see that its template is Child and its ID is 44, and that its parent template is Parent with an ID of 43.

So much for the “control” — it worked as expected.

So then I cloned that entire “Ori” set-up as “Nori,” which I then upgraded (3.0.191 → 3.0.192), and loaded the same two pages. I had expected to see the same result for the Parent page, but only the Child information for the Child.

Unfortunately for me (but probably fortunately for @ryan!), nothing broke in 3.0.192 on Nori: the Child page also (properly!) showed its parent’s information.

So then I began installing each of the modules that I’m using one by one on Nori, and testing the results (still in 3.0.192). I have more modules than I thought! But none of them caused my 3.0.192 test to break the way it does to my system IRL.

I guess my next step at this point would be to gradually change the config.php file to match my system, with tests after each change. And then, gosh, I guess gradually re-create the whole system until something breaks. I think I‘ll take this evening off before embarking on that tomorrow.

I have no idea how I could create a gist to show this, but I‘d be very happy to give any of you access to a copy of my development system where everything works perfectly in 3.0.191 but not in 3.0.192. Please PM me if you‘d be willing; I‘ll treat you to a couple of beers if you can help me make headway on this!

[ErikMH]

Well, I’ve revisited all the modules and made sure that even the core modules’ settings are all identical.

And I’ve made the config.php file essentially the same.

But I cannot reproduce the problem in the purpose-built “Nori” test environment.

So to reiterate briefly in one place:

• on my development server, in page-class files in /classes/ in 3.0.191, $this->parent() properly points to $this’s parent page, and the parent property of $this also properly points to its parent page;
• upgrading to 3.0.192 causes no problems, except that in page-class files in /classes/, $this->parent() is a NullPage, and the parent property of $this is empty.

 

I have found an inefficient but effective workaround, however — and given that no one else is seeing this problem and that I’ve easily spent 40 hours trying fruitlessly to track it down, I think I’ll just need to say “good enough” and move on:

Awkward work-around

Rather than refer to $this->parent(), I’ll instead use $this->wire('pages')->findOne("child=$this"). This works just fine, and @ryan’s code is so efficient that I see no appreciable difference in speed. Sometimes you just have to move on....

[adrian]

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:

[ErikMH]

@adrian, thanks for trying. It really seems to be something unique to my development/production setup. Even when I try to re-create my own setup, I can’t re-create the problem! Most vexing....

[ErikMH]

Ah. Well, my workaround doesn’t work around everything. It turns out that not only is $this->parent() a NullPage, but in fact $this->url and $this->httpURL don’t include the parent’s node of the URL. So, for example, if page “Parent” has a child page “Child”, the child’s URL ought to be https://example.tld/parent/child/, but as of 3.0.192 it’s instead giving me https://example.tld/child/.

I could probably work around this too (finding the parent via the workaround I posted this morning, getting its URL, and appending the child’s URL node to it), but I suspect that I’d then just find something else that doesn’t work because my page’s parent isn’t identified.

So I’m back to analyzing the problem....

[adrian]

@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 :)

 

[adrian]

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]

22 minutes ago, adrian said:

@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’ve never run across that before! It looked likely, but has no effect.

[ErikMH]

26 minutes ago, adrian said:

Maybe also try to run optimize on all of the DB tables? Adminer (within Tracy) makes this easy.

No effect. ?

BTW, I saw no way to “select all” the tables, so I clicked on each (there are 95) manually to select them all. Is there a better way? My future self thanks you!

[adrian]

3 minutes ago, ErikMH said:

Is there a better way?

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

[ErikMH]

27 minutes ago, adrian said:

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.

I’m not sure what you’re suggesting? I’ve backed up, made changes, tested, restored from backups countless times over the past eight weeks on my development installation.

Whenever I need to update data in the live site, I’ve restored the development site to the last master release, added my new data, and then cloned everything over to the live site.

[ErikMH]

2 minutes ago, adrian said:

Wow, I don’t see anything like this at all. Here’s the top of my screen:

 

and here’s the bottom:

 

 

[I’m also unsure as to why my posted images keep being magnified so much larger than everyone else’s. I apologize!]