joomla custom fields tags are not replaced in syndication feed

[Sukinoz]

Steps to reproduce the issue

Create a joomla custom field
Create a joomla article and add a value to the custom field.
Add the custom field tag {field-1} inside the article introtext
Create a Syndication Feeds Module.
Click in the syndication links you have created

Expected result

...
<description><![CDATA[<p>It's easy to get started creating your website. Knowing some of the basics will help.</p>
<p>custom field: CUSTOM FIELD VALUE</p>
<h3>What is a Content Management System?</h3>
....

Actual result

I can see the {field 1}, not the value.

...
<description><![CDATA[<p>It's easy to get started creating your website. Knowing some of the basics will help.</p>
<p>custom field: {field 1}</p>
<h3>What is a Content Management System?</h3>
...

System information (as much as possible)

3.8.12

Additional comments

[mbabker]

It's been an issue I've raised over the years that has never been addressed. The core plugin events are only triggered in HTML views and at this point it would almost be catastrophic to the plugin ecosystem to try and add the same triggers in non-HTML views. At this point I suggest the odds of it ever being addressed correctly are slim to none.

[Sukinoz]

Thanks for replaying.

I am not sure what you mean with "I suggest the odds of it ever being addressed correctly are slim to none."

Do you mean it have no solution? Also in Joomla 4?

[mbabker]

Every time I've raised an issue about the lack of plugin support in non-HTML views it gets no feedback. I am personally at a point in my life where I'm not going to waste my time contributing code to OSS projects unless there is interest in the work, and the silence on my past issues shows a lack of interest.

Likewise, even if we do fix core, the changes will be entirely disruptive to the plugin ecosystem (because right now plugins rightfully assume the bulk of their events are only being dispatched for HTML views) and the only way to do it would be to rename every core plugin event and deprecate the existing events (this way you could basically always guarantee onContentPrepare and other events triggered on frontend views are always coming from an HTML context but whatever the replacement would be would need to be something that checks against context and determine what, if anything, it would need to do in an HTML context, JSON context, RSS context, etc.).

And I don't foresee anyone putting in the time and effort to do all of that. It's not that there is "no solution", just personally I feel like there is no interest in implementing the solution.

[Sukinoz]

It's not that there is "no solution", just personally I feel like there is no interest in implementing the solution.

Now I have understood it perfectly ;-). Thanks for your sincerity

[Sukinoz]

Maybe this info is useful: Seems that Peter from Regular Labs have solved it, because with "Articles Anywhere" you can replace the {field-1} for something like {article}[custom-field]{/article} and you get a correct RSS Syndication.

[mbabker]

I don't use his code, but I wouldn't put it past him to have a creative workaround of having one of his plugins hook a system event after the component is run (probably onAfterDispatch) to do the replacement. Which works, but isn't as efficient as if the onContentXXX events were dispatched (those events already have the loaded article object, the system events kind of require you to reverse engineer the request and re-load the needed data to do things).

So with creative workarounds you can still make things work.

[Sukinoz]

Maybe this info is useful: Seems that Peter from Regular Labs have solved it, because with "Articles Anywhere" you can replace the {field-1} for something like {article}[custom-field]{/article} and you get a correct RSS Syndication.

Sorry, "Articles Anywhere" doesn't solve the problem either... Also tested "obRSS" and doesn't solve it either

"Seems the Joomla core category blog rss view does not pass the individual items through the content plugins. This means that no plugins can do article based stuff to the content."

[Sukinoz]

Now i have tested it in Joomla 4.x and it happens the same issue,

@brianteeman , Could be this issue labelled as "J4 issue" also?

[brianteeman]

@Sukinoz no - need to as if its fixed in J3 then it will be pushed up to j4 as well

[uglyeoin]

Could fields be removed from this if the plugin ecosphere would have a problem? Or if fields are to stay, then could the plugin ecosphere be informed of this new change, it sold as a feature/benefit, and then marked as J4? In which case a pull request could potentially be generated.

[mbabker]

Removing stuff processed by plugins requires dispatching plugin events or breaking the core architectural design and hardcoding plugin related functionality into components. The core software and ecosystem are not in a state where dispatching plugin events on non-HTML views will be received warmly, if at all, because it will in essence create major B/C breaks for basically every plugin subscribed to frontend display events (onContentPrepare, onContentAfterTitle, etc.).

[brianteeman]

Please retag as a J4 issue

[Sukinoz]

Please retag as a J4 issue

Sorry, I can not find where to change the label or tag

[alikon]

retagged j4 as requested

[Hackwar]

I've marked this both a bug and a new feature, because the necessary fix would require a B/C break.

[nicolas-geysse]

Ah...Too bad...