I have tested this item ✅ successfully on 19e0d03

I have tested this item ✅ successfully on 19e0d03

@SharkyKZ the same method is in the API application as well

RTC

This one's a bit different to the api because we can check whether the application implements CMSApplicationInterface instead of CMSWebApplicationInterface (although in truth obviously would be better if the api didn't have that dummy getTemplate method).

This one's a bit different to the api because we can check whether the application implements CMSApplicationInterface instead of CMSWebApplicationInterface (although in truth obviously would be better if the api didn't have that dummy getTemplate method).

@wilsonge So should I revert RTC and the PR needs to be changed or replaced by a new one?

I'm not sure. it depends how intrenched the usage is. Like I don't see PluginHelper::getLayoutPath being called by the finder plugins themselves. So what is actually calling this function and what's the effect of it looking for the system template?

This is a general issue in our override system, which is require Template (it not only about Finder).
Plugin may want to render some tmpl or layout in CLI/API Application context.

Defaulting to 'system' template will work, but it just hide the issue.
The fix is okay, as long as we do not have a better idea what to do here :)

@wilsonge this is the call stack

OK So comes from this #36747 PR which is a new 4.2 feature. So first of all that's caused a regression. Is this CLI working in 4.1?

Second of all that PR is setting prepareValue to true. But this is presumably going to index different based on whether it's frontend or backend driven edits causing the index because the active template will be different. Seems like that entire feature is very broken to me? Beyond just the CLI.

Tagging @Hackwar for insight as he wrote the code and might be able to give an understanding and @roland-d because looks like 4.2 currently is causing a regression.

I haven't written the CLI part here. I would have to look into this more deeply.

It not a Finder issue, it "Template Override" issue.
The same will happen if call LayoutHelper::render('foo.bar') in CLI context.
If we fix it, then a rest will work automatically :)

I haven't written the CLI part here. I would have to look into this more deeply.

This isn't a purely CLI issue. Your rendering the custom field on index - which uses the active template. Not the frontend template. In the CLI that crashes but even if that update comes from the backend seems dodgy to me

@wilsonge Thanks for the heads-up.

So first of all that's caused a regression. Is this CLI working in 4.1?

It is not a regression I guess because it fails with the same error on Joomla 4.1.5 for me.

$ php cli/joomla.php finder:index
Finder Indexer
==========================

 Starting Indexer
 Setting up Smart Search plugins
PHP Notice:  Undefined index: HTTP_HOST in .../j4/libraries/src/Uri/Uri.php on line 103
 Setup 127 items in 0.177 seconds.

In image.php line 57:
                                                                                     
  Call to undefined method Joomla\CMS\Application\ConsoleApplication::getTemplate()  

$ php cli/joomla.php 
Joomla! 4.1.5 (debug: Yes)

Regression or not, this is something we should fix, ideally before the last beta 3 release tomorrow.

@Hackwar Do you have time to look into this?

OK So sat down with the dev laptop tonight and actually tried doing some reproduction steps and debugging. First of all - with latest 4.2-dev and the test data set installed I can index from CLI just fine.

If I then create a custom field and make it searchable it fails. So i'm very confident in 4.2-dev it's related to that fields PR (at least for now - if it fails in 4.1-dev then possible there might be other scenarios we have to look at too). I can't install the same dataset there (because I run 8.1 locally and 4.1.5 doesn't have the PHP8.1 fixes for the test sample set)

4.2-dev:

4.1.5:

I think that PR needs reverting if it's not fixed because:

1. Your going to get different results depending on if you are frontend or backend editing (because it may or may not load the correct template overrides for a custom field).
2. I don't think it should work (searchable) for things like the media field. It certainly doesn't at the moment anyhow and I'm not sure we should show people the option
3. If you make a subform field searchable (not such a totally crazy thing to do) then it hard crashes the index process.

@roland-d with 4.1.5 stable it works well for me under the same settings for 4.2 (blog sample data)

Thank you @wilsonge for your detailed response. I agree, at this point we should revert this PR and take some time to further polish it.

@alikon Perhaps it comes from 3PD custom fields, I did not check why it fails, just that it fails.

This PR can be closed I guess and the final solution should be in the new PR for indexing custom fields.

so you will be reverting #36747 and closing this and waiting for a new pr

@brianteeman That is correct, a new PR needs to be made and give @Hackwar some time to look into this.

Thanks everybody for your work on this.