[#17438] - com_content category view + email cloak plugin = very slow
- Closed
- 8 Aug 2017
- Medium
- Build: staging
- # 17438
Steps to reproduce the issue
With the joomle core plugin emailcloak enabled, load a com_content category view page where there are > 50 items in the category.
Expected result
The page loads quickly.
Actual result
CPU load spikes, page times out.
System information (as much as possible)
j3.7.4, aws t2.medium instance
Additional comments
My tests show onContentPrepare being called for each category item. I'm not sure what the proper solution to this case is, but I patched it by ignoring the category view in the plugin.
if (isset($_REQUEST['view']) && $_REQUEST['view'] == 'category')
{
return true;
}
joomla-cms-bot
- | Labels |
Added:
?
|
||
franz-wohlkoenig
- | Category | ⇒ | com_categories com_plugins |
| Title |
|
||||||
How big (about how many characters) is the description text of your articles ?
| Status | New | ⇒ | Discussion |
My average article length in this category is 70k. I didn't realize that onContentPrepare was getting the full text for every article in the category. That explains why cloak hitting preg_match/substr_replace as many as 17 times per article slows things down. It loads much faster when I disable the email cloak plugin.
So, this isn't actually bug, sorry. I suppose the fact that it doesn't work well for my case means that I should stop doing it.
Im not quite sure why the core plugin is a content o it plugin to be honest.
Please see this alternative:
https://extensions.joomla.org/extension/email-protector/
On 8 Aug 2017, 18:47 +0100, schaferdave notifications@github.com, wrote:
My average article length in this category is 70k. I didn't realize that onContentPrepare was getting the full text for every article in the category. That explains why cloak hitting preg_match/substr_replace as many as 17 times per article slows things down. It loads much faster when I disable the email cloak plugin.
So, this isn't actually bug, sorry. I suppose the fact that it doesn't work well for my case means that I should stop doing it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
| Status | Discussion | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-08-08 20:48:39 |
| Closed_By | ⇒ | schaferdave |
Email Protector is much faster, thx.
Im not quite sure why the core plugin is a content o it plugin to be honest.
Email protector is covering only 1 case, core is covering a lot more
I'd like to see the reasoning as calling it on every content prepare is heavy in comparison to passing through the whole prepared contented before rendering which is a single page.
On 8 Aug 2017, 21:53 +0100, Dimitri Grammatikogianni notifications@github.com, wrote:
Im not quite sure why the core plugin is a content o it plugin to be honest.
Email protector is covering only 1 case, core is covering a lot more
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
Regex are expensive wherever you calling them. All I saw by a quick comparison was that the 3rd PD solution was checking only <a> tags but core is checking a gazillion more possible tags
It shouldn't be slow just calling 50 categories through onContentPrepare unless you have a lot going on with onContentPrepare already.
Can you disable all non core content plugins and try again?