Please provide the full raw html for the content article as plain text file attached to this issue in github

Raw html of content article now attached at text. This is the article as it currently is. Any modification and attempt to save produces the problem.

I have run your text thought the unit tests for #15673 and they pass, meaning that your problem is nor related to that :(

Is there a reason you are running PHP 5.6.29? Can you upgrade to PHP 7?

I just tested on multiple systems using php 7.1.1 and php 5.6.30 and it saved with no problem at all

PHP portion is subject to the whims of our provider - short term answer is no, cannot upgrade at present. However it is possible to upgrade in the future.

PHP portion is subject to the whims of our provider

And you have the choice to use a provider that uses modern up to date PHP. Move.

So this means you are increasing the minimum requirements of Joomla 4.7.1 to php 5.6.30?

No that means that Phil was expressing his personal opinion

If I had my way Joomla 4 would be PHP 7.1 only as a minimum.

http://php.net/supported-versions.php

I also has no issue saving your text on 5.5.38

@brianteeman I accept @PhilETaylor opinion that backwards compatibility can suck.

my point is that your problem is probably not purely php version related

If I had my way Joomla 4 would be PHP 7.1 only as a minimum.

FWIW we left the door open to revisit this all the way up to 4.0 beta 1 being released, so there's a lot of time to revisit and rethink that. Personally, I don't see us keeping PHP 5.5 support given the way our numbers are moving, but dropping everything before 7.1 is borderline pushing our luck right now.

its all interesting but off topic

my point is that your problem is probably not purely php version related

Yes, it is the size of the article that has this effect.

in my not so old PC, it takes about 80 seconds to save the article
(plus a few seconds to reload the form)

Out of which the JFilterInput::cleanTags on the article text were about 75 seconds

• about 5 seconds were JFilterInput::escapeAttributes() called at the beginging of JFilter::cleanTags()
• and about 70 seconds were the main loop of JFilterInput::cleanTags() ...

Filtering code does not seem broken in this case,

• just new filtering code has gotten much slower than J3.6.5

maybe 2x or 3x slower or more ? (i do not know , i have not tested with J3.6.5 (maybe tomorrow),
maybe someone else can test performance difference with J3.6.5

Article text is about 300KBytes with a lot of tags (and tag attributes?), and server is probably a bit slow
try with a timeout of 90 seconds to 150 seconds,
and it will save ...

Having same issues, with something special:
Using a pagebreak within an article, containing special characters (in my case, germans like ÄÜÖ or ß ) the string validation runs into death:

PHP Fatal error: Maximum execution time of 180 seconds exceeded in ./libraries/vendor/joomla/string/src/phputf8/mbstring/core.php on line 94

Feedback of some editors:
Chrome / FF on Win10 are failing when trying to save the article
Cent browser (chromium based) is working well
Chrome / FF on Win7 are doing well, too.

It only appears when having special characters in the pagebreak content. Example:
<hr title="Äußerungen" class="system-pagebreak" alt="Äußerungen" />

When changing the special characters like this:
<hr title="Aeusserungen" class="system-pagebreak" alt="Aeusserungen" />
everthing's fine with saving.

Special characters in other parts of the article are no problem so far!

What's wrong there?

@PepeLopez Please confirm that you are using Joomla 3.7.1 as released on Wednesday.

@PhilETaylor
Yes, Joomla 3.7.1 is installed!

However, I found out:
The error only appears, when the editor is NOT "administrator". When the user is NOT admin, the problem occurs. If admin, no error appears.

my point is that your problem is probably not purely php version related

And you have the choice to use a provider that uses modern up to date PHP. Move.

No that means that Phil was expressing his personal opinion

My point is that SLOWNESS is a consideration with PHP version, an example is running

echo mb_strlen('<hr title="Äußerungen" class="system-pagebreak" alt="Äußerungen" />');

In multiple versions of PHP will give results like

Therefore I conclude that running PHP 7.1 will run mb_* functions faster than PHP 5.6.x

I agree its not purely PHP related, but the time required by older versions of PHP on large articles will be significantly different to later PHP versions.

I asked you (@lynnfredricks) to

Please provide the full raw html for the content article as plain text file attached to this issue in github

I see you did that, but now its been removed, can you add that again please, we cannot be expected to magic up test cases here.

The error only appears, when the editor is NOT "administrator". When the user is NOT admin, the problem occurs. If admin, no error appears.

IIRC different filters are applied depending on user group/acl

IIRC different filters are applied depending on user group/acl

Maybe, but it until update (from 3.6.5) there was no such problem!? However, what should I look for then? I mean, that specific call causes an 180s (and maybe "forever") endless loop for looking up the pagebreak thing.
Wrong group/acl or not: It shouldn't die this way!

@PepeLopez when Im back in the office I'll be running your example through some unit tests.

until update (from 3.6.5) there was no such problem

Right. Because in 3.7.0 an extra layer of code was added to our filtering system to better handle multibyte characters. Clearly this has come with performance issues, which we are trying to rectify. But we cannot simply just revert that change as it also had security implications.

@mbabker
I'm fine with improvements. I just see, that it needs around 8 seconds to save an article with administrator rights, and not-working as "Manager" or below.
The only fix for me in this case is obviously to grant all editors admin rights - which is a bad idea as you may know :D
So it's pretty strange about this effect... keep in mind: Only the pagebreak seems to be affected, and only non-admins.
@PhilETaylor consider that for your tests, please. It's ok if it needs more time, but my case is a dead end, it's not about performance here (joomla is running on 16cores with 192g ram).

@PhilETaylor I have added it back. Not sure what happened but I didn't remove it to begin with.

I have replicated an endless loop in PHP 7.1 with the <hr /> code provided, on my mac. It just never ends.

Extract it to a separate issue but we need test cases covering the
filtering library in at least every setup that the default ACL/filtering
config give. If we're only testing the defaults we're missing a lot.

On Fri, May 19, 2017 at 4:35 PM Phil Taylor notifications@github.com
wrote:

ok I give up at 4.5hours of debugging.

The problem is replicate-able by disabling editors, logging into the front
end as a PUBLISHER, and then using the string

---

attempt to save an article, the code gets into an endless loop - this is
NOT a performance thing, this is an endless loop.

[image: screen shot 2017-05-19 at 21 42 49]
https://cloud.githubusercontent.com/assets/400092/26267526/86cc93d4-3ce2-11e7-9e9f-d3ee4c708fd2.png

The problem is that the escapeAttributeValues method is meant to

• Escape < > and " inside attribute values

when in fact its wrongly interpreting the "" after some Äuß kind of text
as still being within the attribute value, instead of understanding
that the " is the closing tag.

It then goes into a loop.. until the php.ini max_execution_time is
reached. This is not a performance issue, PHP version issue, it is
replicate-able on a PHP 7.1/Joomla 3.7.1/Mac - Its a endless loop issue

It looks like some of the work done by @ggppdk https://github.com/ggppdk
in the escapeAttributeValues method is at play here. Maybe he would like
to comment on this and test it.

I cannot create a unit test to replicate the issue at the moment, as the
wrong filters run during unit testing, and not the filters a PUBLISHER has
when they save an article.

—
You are receiving this because you were mentioned.

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

--

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

I think I found a solution. Where put a unit test code? Which method?

Never mind, I created PR #16140

@PhilETaylor , thanks for ping me

It looks like some of the work done by @ggppdk https://github.com/ggppdk in the escapeAttributeValues method is at play here. Maybe he would like to comment on this and test it.

Wrong ! , my PR, besides fixing the meaningless addition
and besides renaming a variable and changing a comment

• changed none of the logic of the methods !
• and even if a fix for BUG 1 reveals a BUG 2 that does not mean the fix was invalid

PR #16140 made by @csthomas, proves my argument, the faulty code was not added by my PR, it prexisted, and PR #16140 does not revert any of my changes

I cannot create a unit test to replicate the issue at the moment, as the wrong filters run during unit testing, and not the filters a PUBLISHER has when they save an article.

Wrong again ! (see PR #16140 again) escapeAttributeValues() runs regardless of which TEXT filters you have, you can add a test case to the unit tests

• because escapeAttributeValues() is running before the loop to remove and check the Tags

and cleanTags that calls it , will run regardless if filtering for administrator or for publisher

It then goes into a loop.. until the php.ini max_execution_time is reached. This is not a performance issue, PHP version issue, it is replicate-able on a PHP 7.1/Joomla 3.7.1/Mac - Its a endless loop issue

I hope you are not confusing the performance issue with the parsing issue
just it sounded like this

I do confirm a huge difference when saving as a Manager or as a SuperAdmin even after merging #16140
See #16140 (comment)

Any further movement on this? Just in case, I saw that in another report that Jsitemap Pro Pingomatic was causing a problem. On this specific site, the only third party extensions are the two main Akeeba ones.

@lynnfredricks please have a Look and Test on #16201

I just tested with 3.7.2 and execution time is not improved enough. Error has changed through:
/libraries/vendor/joomla/string/src/phputf8/mbstring/core.php on line 94

Same article, just tried saving it.

@lynnfredricks can you please post comment on PR on PR #16201 itself?

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/16112

closed ashaving PR #16201