cannot access page from within hook for 'renderRepeaterLabel'

[thei]

i 'm writing a hook for repeater labels

$this->addHookAfter('InputfieldRepeater::renderRepeaterLabel', function(HookEvent $event) {
  // Get the object the event occurred on, if needed
  $InputfieldRepeater = $event->object;


  // An 'after' hook can retrieve and/or modify the return value
  $return = $event->return;

  // Get values of arguments sent to hook (if needed)
  $label = $event->arguments(0);
  $cnt = $event->arguments(1);
  $page = $event->arguments(2);

  // Your code here, perhaps modifying the return value
  // just a simple test:
  $return = "LABEL " . $page->getForPage()->template();

  // Populate back return value, if you have modified it
  $event->return = $return;
});

this hook function works (e.g. if i return a constant string)  as long as i don't use '->getForPage()'

the error message is '...... Page::getForPage does not exist or is not callable in this context'

The hook is in 'ready.php'. it seems the events setting especially "$page" property is not complete within context?

i want to set the repeater labels only if the parent of pages has a special template.

(i m using Version 3.0.210)

What i am doing wrong?   Who can help?

Thank You

[da²]

Hello,

There isn't a getForPage() method on Page class. To access parent template it's simple: $page->parent->template->name.

[thei]

but for a repeater field the page object is of class RepeaterPage. Using   ->template  returns 'repeater_....' which is not the name of the embedding page.

The documentation of RepeaterPage describes a getForPage

[da²]

Oh ok I see, so getForPage() works on my side (PW 3.0.228):

/** @var RepeaterMatrixPage  $page */
$page = $event->arguments(2);
$templateName = $page->getForPage()->template->name;

 

[thei]

hm. if i download the latest stable i get a 3.0.227 (cannot find a 228)

with 3.0.227 still the same behavior. OK found 229.  same problem.

[da²]

In my test I did an exit(), if I remove it it throws an error. 😆

$this->addHookAfter('InputfieldRepeater::renderRepeaterLabel', function(HookEvent $event) {
    $page = $event->arguments(2);
    $page->getForPage(); // Comment this line and there's no more error
    // exit(); // Or uncomment this
});

Error comes after our call to getForPage():

Quote

ProcessWire: ProcessPageEdit: Method NullPage::getForPage does not exist or is not callable in this context

It seems that calling getForPage() triggers an error later in PW code... Looks like a bug to report.

In getForPage() source code we can see:

// this probably can't occur, but here just in case
$this->forPage = $this->wire('pages')->newNullPage();

Looks like it occurs @ryan 🙂

[thei]

what is the procedure now? should i write a bug report?

i guess here https://github.com/processwire/processwire-issues/issues ?

Thank you for your help  🙂

[BitPoet]

To me it looks like renderRepeaterLabel is also called for a dummy repeater item (see the call with a NullPage here). That one doesn't have a page associated yet, as it hasn't been saved. It's just used to render the form for adding a new one. So the calls for the existing items succeed, but that last one fails and throws the error.

This can be cured easily by adding a check for $page in the hook:

  // Get values of arguments sent to hook (if needed)
  $label = $event->arguments(0);
  $cnt = $event->arguments(1);
  $page = $event->arguments(2);

  // Only execute the hook for actual repeater items,
  // not for blank placeholders
  if($page instanceof NullPage)
    return;

  // Your code here, perhaps modifying the return value
  // just a simple test:
  $return = "LABEL " . $page->getForPage()->template();

In a short test, this worked like expected.

[thei]

Hi BitPoet,

YES indeed it works. Thank you very much!!

Nevertheless this case should be handled inside PW rather than checking for $page in the user defined hook.

 

HM... what is the further procedure here. Should i report a bug?  Where? Otherwise: the guideline here in this forum says, i should mark this as 'soved' by clicking  the 'mark-as-solved' button. BUT there is no 'solved-button' displayed here   😞

Edited December 27, 2023 by thei
further procedure

[BitPoet]

On 12/27/2023 at 11:04 AM, thei said:

Nevertheless this case should be handled inside PW rather than checking for $page in the user defined hook.

I'm a bit of two minds on that, as there might be a use case for empty repeater items. Nevertheless, it wouldn't hurt to point this out in the API docs. Perhaps open an issue in processwire-requests?