Panel hooks from loop fails

i took debugging inspriation from here: Debugging hooks?

but my problem seems to be with update in general. once i create a hook for panel.page.update the panel progress bar goes into a crawl. the hooked function can even be totally empty.

i am using most current kirby installation (CLI). mac, mamp pro.

tried pushing to webserver. still slow progressbar for panel.page hooks groupe. even tried clean kirby CLI installation with just adding these lines to config.php

function hook_log ($obj) {
   file_put_contents('test8.log', 'hello');
}
kirby()->hook('panel.page.update', 'hook_log');

progressbar goes to a grind.

no problems with file and user hooks btw.

writing to folder outside the /panel from hook is possible like @jenstornell did. so this does not seem to be the issue here.

 file_put_contents(kirby()->roots()->index().'/test11.log', 'hello');

i tried the clean kirby install and revisions no issue with the hooks there. i do not understand why my simple code block it.

tried same code as revisions did. no luck still slow progress bar.

$mycallback = function( $page ) {
	file_put_contents(kirby()->roots()->index().'/test14.log', 'hello');
};
kirby()->hook('panel.page.update', $mycallback );

does not seem to be a problem of file_put_contents, since copy() is slow too. even with error suppersion @.

$mycallback = function( $page ) {
   //file_put_contents(kirby()->roots()->index().'/test14.log', 'hello');
   @copy( $page->content()->root(), kirby()->roots()->index().DS.'acopy.txt' );
};

kirby()->hook('panel.page.update', $mycallback );

i think i found it.

its caused if there are two or more hooks on the same type like ‘panel.page.update’. in my original case it was autoid and my hook. in my clean install it was revisions and my hook. once there is only one hook it works fine, both of them. i created a plugin from my config.php hook but same problem.

maybe @texnixe can verify this based on her old post ?

i see why autoid from @helllicht might cause a panel.page.update loop. the plugin calls $page->update() here.

but revisions plugin does not, neither did my hook. why did there two not work well together?

It’s a bug that’s fixed on the development branch. I can’t find but it’s on Github somewhere.

this? https://github.com/getkirby/kirby/issues/451

1 Like

thx @texnixe. this fixed the issue with panel.page.update. i will search github issues next time before spending hours myself. :neutral_face:

but i still get slow progress if renaming a file. both panel.file.update and panel.file.rename are triggered. i can skip rename hook if needed but i am curious why it fails.

my logging creates a slow progress for panel.page.create too because the panel.page.update is called along with it. is writing the logfile taking to long? how are hooks triggered?
i am writing to different files for each hook so it should not be a locking issue there, right?

panel.user.create does not trigger panel.user.update. why? if panel.page.create does trigger panel.page.update, so should user.

@bnomei: I don’t quite understand what you mean. When a page/user/file etc. is created, only the panel.xxx.create hook is triggered, not the update hook?

Maybe you can add the same functions in both create and update hooks? I do something like that in my Revisions plugin.

silly me. i used a template with blueprint having an autoid field. thats why update is called on create.

so now i have the following issue using autoid. autoid registers a panel.page.create hook. on create it will call $page->update() to write the autoid. so far so good.
but i also have a custom hook listening to panel.page.update. so this one gets triggered causing the slow progressbar. a basic hook like this works fine.

kirby()->hook('panel.page.create', function($page) { file_put_contents(kirby()->roots()->index().'/testcreate.log', 'hello'); });

but once i use my plugin in fails. in all other cases it works just when create is causing an update.

kirby()->hook('panel.page.create', function($page) use ($plugin) { $plugin->log($page, 'panel.page.create'); });

so my guess is that my plugin fails to process the update because its still processing the create. a nested call of the same plugin. any ideas how to fix this?

i check revisions from @jenstornell again. he uses only static functions and no issue in combination with autoid. good job. :clap:

but i refuse the idea to make my plugin static since its not causing the loop. autoid form @helllicht is causing it. so i can create an github issue there (which would require them to go static) or i find a workaround myself.

any ideas how to track if my class is called nested?

haha. it always helps writing to the forum. explaining a problem is half way of solving it.

i just added a static ‘lock’ to my own class blocking the main function to be called nested.

private static $lock;
public function main() {
  if(MyClass::$lock) return;
  MyClass::$lock = true;
  
  try {
     // do work
  } catch(Exception $ex) {
    // maybe echo ex
  }
  finally {
      MyClass::$lock = false;
  }
}
3 Likes