Maybe I'm missing something obvious here, but haven't we always "only" prepared the "text" property (the combined introtext and fulltext), and not done any processing on those two fields individually?

Well we do it for the introtext already. (just a few lines above the new code)

I saw that, I just don't get why. Especially as introtext and fulltext are fields only in com_content's data schema. So basically why is com_fields processing these two fields when we don't process them anywhere else? I'm obviously either missing some valid reason or it was just decided on a whim to start doing it, and why only com_fields and no other plugin in that case?

Seams like it got introduced here #18066 by @laoneo mergedn by you as the other implementation caused an regression. Maybe @laoneo can give some insights here why it was added in the first place.

The big issue was the double event firing, which caused a lot of troubles for @regularlabs. Not sure if it would case the same problem. @regularlabs can you please test this patch with your extensions to prevent that we are introducing again double firing.

In some cases you might want to style the intro section different from the fulltext section and place it in a different container then the fulltext section. It's available separately, so you want to use it in the override. But you can't, because the Plugin does not get rendered.

The reason that the event firing on the introtext was introduced was not because there was double event firing. That was the result.

The "prepare introtext" thing got introduced here: #17175
Which was an attempt to solve this issue: #15751

So yes, I agree with @mbabker, and plugins shouldn't get separately triggered on intro and fulltext.
This PR will only cause yet another trigger.

If you need these separate triggers, I guess it is time for Joomla to rethink the whole text, introtext, fulltext approach and handling altogether!

I don't need seperate triggers... I need a trigger at all, because the field does not get rendered.
Can I trigger the plugin event on the override page somehow or not?

To add/correct my earlier response:
This current PR only triggers internal preparing of the separate strings to check for fields.
That is fine, as it doesn't trigger the onContentPrepare (or other events) via the dispatcher separately.
So I see no issue with this PR.

What I do in my extensions is do an extra check and only go over the introtext and fulltext if the $item->text and $item->title are different (saves resources).
So optionally add this before the introtext and fulltext code:

		if ( ! empty($item->text) &&  ! empty($item->title) && $item->text != $item->title)
		{
			return;
		}

Can I trigger the plugin event on the override page somehow or not?

<?php echo JHtml::_('content.prepare', $whateverText); ?>
https://github.com/joomla/joomla-cms/blob/3.8.12/libraries/cms/html/content.php#L30-L44

@ReLater - The exact problem is that the solution you suggest does not work on $this->item->fulltext;
That's the whole issue...

The exact problem is that the solution you suggest does not work on $this->item->fulltext;
That's the whole issue...

I don't understand. You can give over whatever STRING you want. The linked method creates a temporary $article->text out of it and passes over $article as $item to the plugins. As long as the plugins "prepare" $item->text everything should be fine. Just sometimes you have to add a $context

Ok,... look here:

My article:

Code:

Output on the page:

Same result with:

To be clear here this PR is fine for what it’s doing. I’m just trying to
make sure I’m clear on the fact we decided it’s OK to process the separated
introtext/fulltext properties for com_content items because as far as I
knew it was always best practice that the text property was the one that
would be processed and its contents would be rightfully set by whatever
source (usually component model or view), meaning the use of introtext and
fulltext in com_content layouts is strongly discouraged and doing so meant
you got unprocessed text without doing something like calling that JHtml
helper (which has the double event trigger penalty).

On Thu, Sep 27, 2018 at 6:21 AM ReLater notifications@github.com wrote:

The exact problem is that the solution you suggest does not work on
$this->item->fulltext;
That's the whole issue...

I don't understand. You can give over whatever string you want. The linked
method creates a temporary $article->text out of it and passes over
$article as $item to the plugins. As long as the plugins "prepare"
$item->text everything should be fine. Just sometimes you have to add an
$context

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#22392 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoVnNT78k1glxetj7bYxoGUa9bqD4ks5ufLTHgaJpZM4W7WlK
.

--

• Michael Please pardon any errors, this message was sent from my iPhone.

@coolcat-creations

Ok,... look here

Maybe because of missing/wrong $context parameter in your JHtml code. com_content.article (?)

@ReLater
Like that?

Does not work either....

@coolcat-creations
Missing $params in your code. So:
JHtml::_('content.prepare', $text, '', 'com_content.article')
See:
public static function prepare($text, $params = null, $context = 'text')

@ReLater with your suggested

JHtml::_('content.prepare', $text, '', 'com_content.article')

it renders the text but does not load the field at all...

I’m just trying to make sure I’m clear on the fact we decided it’s OK to process the separated introtext/fulltext properties for com_content items because as far as I knew it was always best practice that the text property was the one that would be processed and its contents would be rightfully set by whatever source (usually component model or view), meaning the use of introtext and fulltext in com_content layouts is strongly discouraged and doing so meant you got unprocessed text without doing something like calling that JHtml helper (which has the double event trigger penalty).

Yep, I agree. Issue is all sorts of extensions (plugins, templates, frameworks) go about this differently.
If the introtext and fulltext should not be separately touched by plugins along the way, until the view separates them for output, then they shouldn't be in the $article object to begin with, in my opinion.
Or have them there, but not a separate text property for articles.

But that should have been thought about when it first got implemented. We are now stuck with 3 text properties that are not force-linked in any way. Hence issues like the one discussed here.

If the introtext and fulltext should not be separately touched by plugins along the way, until the view separates them for output, then they shouldn't be in the $article object to begin with, in my opinion.
Or have them there, but not a separate text property for articles.

But that should have been thought about when it first got implemented. We are now stuck with 3 text properties that are not force-linked in any way. Hence issues like the one discussed here.

It's all a relic of when there were separated fields in the backend UI for introtext and fulltext. But instead of combining them in the database when we implemented a single editor, we continued to (IMO artificially) separate them based on the readmore <hr> element, and now we've got the current state of affairs where people can and do try to use those separated fields and it be considered a bug when plugins don't touch those fields. To me there's two options:

1. Combine them in the database, as painful of a B/C break as that's going to be
2. Drop the combined view property and process them as the two separate database fields they are, as painful of a B/C break as that's going to be

From a design perspective I'd rather would like to see the possibility to style intro and fulltext seperately, as it always was possible with full functionality.

Or option 3:
Have the text properties (text/introtext/fulltext) as private properties and only be able to get and set them with getter/setter method.
The text can then be combine from or split it to the introtext/fulltext when those exist. etc...
... as painful of a B/C break as that's going to be

(Above will make sure the text is always a combination of theintrotext and fulltext and any change to any will be reflected in the others.)

So is the consensus now that every plugin when in the com_content.article context should process both the individual introtext and fulltext fields as well as the text field (whatever it is assigned as based on the UI options)? Because I'm looking at the com_fields functionality and it is inconsistent with the rest of core, which means either core is wrong for trying to process all three fields or that the other plugins are wrong for not processing them.

I honestly have no issue with what this PR is doing. But we have in effect changed the expectations of content plugins by changing this behavior for com_fields, and I'm not a fan of this undocumented procedure change. I don't care why it was introduced, I don't care what other bug it was addressing (whether it be a legitimate bug or trying to use things in a way that we hadn't designed the code to support), but it needs to be consistent across the board. Because based on the change in this PR, I can log a bug report right now for all of the following:

• {loadmodule} shortcode is not replaced in introtext property
• Email cloaking plugin does not process the fulltext property
• etc. for every core content plugin

Previously, those reports could be closed as expected behavior because it was the accepted practice that only the text property should be processed within plugins, and in cases where you were using introtext and fulltext separately in com_content it was on you to get those fields prepared (i.e. use the JHtml helper and accept the performance penalty of onContentPrepare triggering multiple times). Now, based on what the fields plugin is doing, it can be rightfully assumed it is a bug that core doesn't process all fields.

I promise, contrary to what others might feel, I'm not trying to be difficult here. But we're establishing a new set of rules for what content plugins are expected to do here in a very undocumented way, and I don't like that this is just slipping through because "well, the plugin's already processing one field, it should do the other as well".

@coolcat-creations

it renders the text but does not load the field at all...

Then sorry for misleading you.

Well I'm not sure who can take that decision but IMO we need to ask that person / group to take on maybe something for @wilsonge in Joomla 4?

@zero-24 as ist for J3 i'm calling @HLeithner for a decision.

Could be unexpected if we change this in a patch level I would like to move this PR to J4. And make the behavior consistent over the core as @mbabker said. Maybe @wilsonge like to talk about this in the parameter sprint?

Any update from the parameter sprint? @HLeithner @wilsonge

Any update from the parameter sprint? @HLeithner @wilsonge or any suggestion how to move forward here?