Risks of using module init()?

[flydev]

@szabesz actually the bot do not contain all the data I want, there is something like 5k rows of data, and to achieve it I need to scrap almost all the forum. Even if the process is not resource consumming there might be something else, It doesn't hurt to ask first.

[MarkE]

On 5/31/2024 at 4:03 PM, flydev said:

Just played with a chatbot that will be soon publicly available

I use Github copilot but didn't think to use it on that occasion...

[MarkE]

On 5/20/2024 at 10:54 PM, MarkE said:

BTW I had done something similar with 'ready' - I'm not sure that caused the problems but I moved it all back into ready.php just in case

A bit of an update. Firstly, the problem was caused by ready(), not init(), so my comment above was incorrect.

What I did was

1. Moved all the code from init.php into a similar file in my module folder, then added include('init.php'); in the module's init() method. That seems to work OK.
2. Did a similar thing with ready.php (including it from the module's ready() method). That worked OK in the dev environment, but in the live environment gave the following error on viewing the page tree: You don't have access to list page /

So I put some hooks in ready.php to track the listable status:

wire()->addHookBefore('ProcessPageList::execute', function(HookEvent $event) {
	$process = $event->object;
	bd($process, 'process');
	bd(debug_backtrace(), 'backtrace in processPageList execute');
	bd($process->page->listable, 'listable');
	if(!$process->page->listable) bd(debug_backtrace(), 'backtrace not listable');
});

and 

wire()->addHookAfter('Page::listable', function(HookEvent $event) {
	$page = $event->object;
	$currentUser = $page->wire()->user;
	bd([$page->path, $currentUser->id], 'PagePath, UserId In listable hook');
	bd(Debug::backtrace(), 'backtrace in listable hook');
....

I then ran the code in two ways: (a) including the module ready.php from the site ready.php file (otherwise empty) and (b) including it in the module's ready() method. In the dev environment, both these work. In the live environment, (a) yields the following:

whereas, with (b), I get :

The only difference is that in (a), listable is true, whereas in (b) it is false. To repeat, this is running exactly the same ready.php code on exactly the same database - the only difference is in how it is called. The calls are made from ProcessWire.php (lines 664 to 676):

		// call any relevant internal methods
		if($status == self::statusInit) {
			$this->init();
		} else if($status == self::statusReady) {
			$config->admin = $this->isAdmin();
			$this->ready();
			if($this->debug) Debug::saveTimer('boot', 'includes all boot timers');
		} 
	
		// after status include file, names like 'init', 'ready', etc.
		$file = empty($files[$name]) ? null : $path . basename($files[$name]);
		if($file !== null) $this->includeFile($file, $data);

The only significant difference seems to be that the module ready is called earlier, but there is no processing between the calls.

GitHub copilot is completely stumped (as am I), so I am hoping that some expert humans might be able to shine a little light 🙂

 

[MarkE]

I have boiled this down even further and posted the findings here: 

 

[flydev]

Quote

The only significant difference seems to be that the module ready is called earlier

You didn’t told us what’s the result if you set / change your hook priority.

edit: and are you 100% x 3 sure that roles and permission are the same on both envs ?

edit2: (again 🙃) profiling your code will give you more skills than copilot, and loose less time on this whole thing.

edit3: you should read this issue to see  if it help about what are trying to achieve: https://github.com/ryancramerdesign/ProcessWire/issues/302

edit4: what the bot say:

The issue could be related to the priority of hooks and the sequence in which they are executed. In ProcessWire, hooks can be attached in different methods such as init()and ready(). The init() method is called before ProcessWire handles a web request, while the ready()method is called after ProcessWire determines what page is going to be viewed but before the page is rendered. If the module ready is called earlier, it might affect the sequence in which hooks are executed, potentially leading to the observed issue.

To solve this issue, you can try the following steps:

• Ensure that the hooks are attached in the correct method (init() or ready()) based on when they need to be executed.
• Adjust the priority of the hooks to control the order in which they are executed.

Additionally, you can use the standardized include/hook files provided by ProcessWire:

• /site/init.php: This file is included during ProcessWire's boot initialization, immediately after autoload modules have been loaded and had their init() methods called. This is an excellent place to attach hooks that don't need to know anything about the current page.
• /site/ready.php: This file is included immediately after the API is fully ready. It behaves the same as a ready() method in an autoload module. The current $page has been determined, but not yet rendered. This is an excellent place to attach hooks that may need to know something about the current page.

By ensuring that your hooks are placed in the appropriate files and adjusting their priorities, you should be able to resolve the issue with the listable status in the live environment.

[MarkE]

Thanks @flydev and I will follow up on the priority matter. I have been using profiling as well as AI, and it has been more helpful. As you can see from this other post

 I have boiled the issue down to one of purely where the hooks are called from - ready.php or the module ready(). So I am 99.99% certain it is nothing to do with roles and permissions.

[MarkE]

11 hours ago, flydev said:

you should read this issue to see  if it help about what are trying to achieve: https://github.com/ryancramerdesign/ProcessWire/issues/302

 

Thanks for that. Aside from the problem with calling the hook from the module ready(), the listable hook I am using works perfectly, with additional code I added to display the correct number of children.

[MarkE]

11 hours ago, flydev said:

Ensure that the hooks are attached in the correct method (init() or ready()) based on when they need to be executed.

The hooks are attached in ready(). They don't work at all in init() - it is too early.

11 hours ago, flydev said:

Adjust the priority of the hooks to control the order in which they are executed.

But there is no duplicate calling of the hooks, so how is priority relevant?

[flydev]

I just suggested priority in case there is another hook somewhere of even to not let the system decide when to call it as we have not a profiling report, just set a priority highter, it doesn't hurt to make a test. Also, the reason of why I posted the issue is because I am assuming from your screenshots that you are not making tests with root user id (#7815), so you should test with root user on both envs in order to tackle in first instance the permission issue you posted in your other thread, and post the results.

[MarkE]

1 minute ago, flydev said:

I just suggested priority in case there is another hook somewhere of even to not let the system decide when to call it, just set a priority highter

Only just saw this @flydev. Meanwhile I solved the problem as shown here: 

Your suggestion is absolutely spot on! But at least I worked out exactly why it is necessary. 

Many many thanks for your persistence in helping me to solve this problem. I have learned a whole lot more about ProcessWire along the way!

 

[flydev]

It was the goal by insisting a bit, glad it work and cheer on you for not surrendering 🫡