[4.x] Custom fields cannot be set to only display on the item vs in the intro/preview

[crystalenka]

Steps to reproduce the issue

1. Create a custom field.
2. Set 'display automatically' to anything besides "do not display automatically".

Expected result

There should be an option to display the field only in the article view or only in the preview/introtext/etc.

Actual result

Custom fields are shown in both places always unless set to "do not display automatically"

System information (as much as possible)

4.2.2
PHP 8.0.8

Additional comments

This is more of a new feature, but it FEELS like a bug. The display of custom fields is tied to the content plugin events which are always fired. I can get around it as a developer but others can't. It also means that if it's set to show automatically but I manually remove the event from, say, a module, the custom fields still go through the rendering engine to prepare their content etc which is not very performant if it's not shown.

Quick solution - add two new plugin events (only with introtext, only with full text) or similar so that people can decide easily where it shows up.

Better (more complex, maybe impossible?) solution - keep the current selection, but add checkboxes so people can decide whether it shows in the category/module or in the main article view or both.

Best (probably impossible) solution - allow people to set which event it gets shown with depending on whether it's in the category view or item view. (For example, with title if it's in the category or a module, but after content if in the item view)

Plugin events are beyond my skill level so I can't attempt to do this myself. :(

[brianteeman]

This is not a solution but it should point you in the correct direction.

There are three default positions

• before display content
• After Title
• After display content

If you look at the category blog layout you will see that "After Title" is not present there - its only in the full article

Unless the article is set not to show the intro text

(no idea why this is set up this way) Hopefully this will point you to the simple php if statements you can use to achieve your goal (assuming I understood it correctly)

[crystalenka]

Yes, but it still has the same trouble as manually removing the plugin event from a layout—it runs the custom field through the renderer, as all three of those events get prepared in the category view.

If it's a custom field that has a specific/complex render layout (like a 3rd party custom field, thinking of Tassos' gallery field) and that layout adds JS or something to the web asset manager, the page starts loading assets that don't actually get used.

[brianteeman]

Came back to say - I get it now. Not sure how it can be fixed (other than an override) without causing b/c issues

[crystalenka]

I made some suggestions in my initial post, but I don't know whether they are realistic.

[brianteeman]

For my own site I have done the following

• Set fields to be displyed after content
• Removed <?php echo $this->item->event->afterDisplayContent; ?> from the blog_item
• And finally swapped the order of navigation and afterDisplayContent in the article (makes no sense at all to have page navigation above the fieldss imho)

But making those changes in core would possibly have unpleasant side-effects for existing sites

Perhaps another approach would be to ADD a new event to the existing three that fields can be displayed with and only echo that event in full articles. That way existing sites won't be disturbed by the change ?

[crystalenka]

Adding for context a post on Facebook asking about this same thing.

https://www.facebook.com/groups/joomlanospam/permalink/10158744097080997/?app=fbl

Still not sure of the best approach forward.

[PMWilliams123]

Thanks @crystalenka, the limitation certainly make fields less useful that they should be, for me anyway.

[crystalenka]

I agree! Thanks for adding your voice, it helps to know that there are others who need this capability too. :)

[brianteeman]

of your three suggestions

1. quick - not b/c
2. better - definitely possible and relatively easy to achieve and fully b/c
3. best - seems to just be a variant of 2 but at the field level instead of the view (if i understand correctly)

[brianteeman]

slight correction to comment above - it might be an issue if there are other plugins firing on the same events

[JacquesR]

Stumbled upon this thread while searching for an answer to the same problem. It would be great if there were 2 sets of Automatic Display options for fields (for blog and full article layout views) or even 2 full sets of Display Options, one for each type of view.