@laoneo which is the second Issue you wanted to link (you take #18016 twice)? Guess ##18065

Thanks for the hint, changed it in the description.

The issue with the double triggering of the onContentPrepare is fixed.
I have not tested if the custom fields plugin itself still works as it should.

Please mark it as success. Your code improvements suggestions should be done on a follow up pr as I don't want to get the risk of a new bug.

I have tested this item ✅ successfully on e8e0329

Article View that was opened via a link from Article Category List: Module loaded twice #18016

Plugin content pagebreak does not work for second page and next #17830

For clarity: I tested #18066 Fixes the double event firing
Joomla! 3.8.1-dev Development
PHP 7.0.15
Xampp

Fixed only some code styles. Guess this can be marked as RTC as we have two successful tests.

I have tested this item ✅ successfully on 366588c

@sandewt can you please test again?

@franz-wohlkoenig IMHO as 366588c add only dockblock we can set RTC with one good test from @nibra .

RTC after successful tests. As always Release Lead decide if it get merged.

@wojsmol Thanks for Hint.

Doesn't that mean that when the field content plugin is disabled, no events are processed anymore?
Doesn't look right to me.

@Bakual is right. Unless there is another point where onContentPrepare is called, this event won't be fired if the fields plugin is disabled

remove RTC?

Isn't the whole idea for this change to trigger the fields plugin over the required article data?
So it makes sense that this won't (have to) do anything in the fields plugin is not enabled.

The initial onContentPrepare trigger is still there.
So what events do you mean?
https://github.com/joomla/joomla-cms/pull/18066/files#diff-a2fbd25d7bac224516450abdd42cd57bL190

@regularlabs You're right, it only reverts the introtext part added in a previous PR.
Still looks a bit wrong to me to have com_content specific stuff in the fields plugin.

Well, that's a bit beyond this PR to discuss that.
But the way the onContentPrepare event (and other content triggers) work in Joomla pretty much forces plugins to check for com_content related stuff. This is because the full $item object is passed to the event, not a simple string. Not saying that is a bad thing, as it makes it a lot more flexible. But it does mean the plugins need to decide on what $item values it wants to do stuff on.
If you want to also be able to use the fields plugin in category descriptions - for instance - then the plugin would have to do its thing specifically on the $item->description value too.

True enough.

Great ?

@mbabker Just to throw this in perspective:
IMHO this is a very important fix that should be rolled out asap.
Without the fix, websites can potentially load a lot slower and even break (which is already happening to many).
So upgrading to Joomla 3.8 is currently detrimental for many websites.

Well aware of that. I'm trying to hold off though on a 3.8.1 until we at least have a grasp on everything that's being reported so I'm not spending 10-15 hours per week prepping and rolling releases until it's all sorted. Depending on how things go the rest of this week we can probably do 3.8.1 next week.

"@sandewt can you please test again?" Request from @franz-wohlkoenig

I see in the meantime that the code is merged.
I tested the issues #18016, #17830 and #17175 with success in the latest version of joomla-staging-cms.

But I see sometimes, by using some other content (!), that the menus in Protostar (position 7 - at the right) disappeared to the bottom !?
I can not explain this.

Is that a known or a new issue?

@sandewt can you please open a new Issue?

@franz-wohlkoenig

Some text in articles I used, were 'accidentally' embedded by div's. In combination with NOT 'show the intro text', causes that the menus disappeared to the bottom. So I can explain this behavior.

In my opinion, it is not a new issue.

its about getting Notice as this PR is merged.