Related to the reported problem, this should be finally due to this:
https://toolset.com/documentation/user-guides/conditional-html-output-in-views/
When using very long content with the conditional shortcode you might encounter an error. Since Views uses native WordPress parsing for all shortcodes, this limitation does not come from the Views itself. In such cases, there is no alternative but to break up the content into smaller sections, which may mean having to repeat the conditional statements.
We are using native WordPress shortcodes parsing. If the content of the shortcode is too long like in this case, it can break in some versions of PHP7 (for our Developers it was 7.0.0 and 7.0.18, for others it was 7.0.13, for me and you 7.2).
To workaround this issue, you should even be able to proceed to have the View displaying that address since you have reasons to do so even it outputs just one post - which is technically not an issue - and instead split your Condition in 2, let's say.
So Instead of having one condition checking if the user is logged in, you will have the same condition with some content, twice.
Then, the parser will have exactly half the amount of data to process and should not fail anymore.
Please let me know if this solution works for you as well.
Related to the other issue, could you open a new ticket for that if still happening?
I can then look at it in the fresh thread.
Thanks 😀
Beda -
1. The good news is, we now know exactly what is causing the problem. I was able to split the code inside the "Logged-in" conditional by separating the left column and right column so they are each in their own conditional. Works fine.
I do however find this curious why this problem occurs. It is not really that much memory between the shortcodes. And I thought PHP 7.x was supposed to handle memory much better than 5.x.
2. I cannot easily upgrade to PHP 7.3 yet. I need to do some testing first. But, the solution of splitting up is good enough for now.
3. It would be good for Toolset to add a note about this limitation in the "Known Issues" section for Views.
Thank you for all of this help. I know this issue has taken quite a bit of your time, and I appreciate it very much.
Jeff
-------------
There was a thought in past to add this to the known issues, but it was dismissed as it will suggest a "bug" being solved at some time, which in fact will never happen. That is why it was added to the Documentation.
With PHP7 the chances are that when using Conditional HTML with large contents, a PREG_JIT_STACKLIMIT_ERROR error will be thrown in the code
(See hidden link for the error).
It's at the end due to the regular expression that handles this shortcode - and its performance cannot be greatly improved, our developers found.
This is not an issue introduced by Toolset, strictly speaking, it's a limitation set by PHP 7.0.
Increase the allowed memory size on the server may help, maybe by asking the host to do it for you, especially on shared hostings.
We've also seen reports that these kinds of issues can be solved by disabling the PCRE JIT via php.ini:
hidden link
hidden link
However, this is not what we directly suggest, if you can solve this by splitting the content you should go with that.
I will ask for an erratum set as won't fix, with a proper detailed explanation and link to the DOC and from there back to the erratum, and will update you here about this
I hope that with above information you can proceed with the site.
Beda -
"With PHP7 the chances are that when using Conditional HTML with large contents, a PREG_JIT_STACKLIMIT_ERROR error will be thrown in the code..."
I previously had an issue related to the pcre memory limit, but don't remember exactly the details. I will have to go back and look. But, I do remember it was on a site using Toolset.
I will see if I can get my host to increase to the next level of memory (yes, shared hosting - for now.)
I did split the content on that page into two (see my previous post) and it appears to work fine now.
I asked about posting this issue somewhere in Toolet Errata because, I initially spent about 4 hours looking at this before realizing I needed help from you guys (Support.) It would seem there should be a reasonable place to stick this somewhere on the Toolset website so that a search with related keywords will bring it up for the next developer, and save them some time and agonizing debugging.
Thanks once more for all your time and help.
You can close this issue now.
Cheers,
Jeff
---------------------
Hello Jeff, thanks for confirming the workaround.
I understand your reasoning for an erratum, I will for this purpose keep the ticket here open in the escalated state.
I'm discussing with my team how we could better explain this, not only more prominent but also more detailed eventually.
I'll share the outcome here as soon as I have it.
Beda -
Curious if anything further in documentation or errata has been added for this memory limit issue when using wpc-conditionals.
Have a great holiday!
Jeff Safire
-------------------
Yes, thank you for reminding me.
An erratum will be published today, along with the already existing DOC, completing the information which I received a good while ago but forgot to communicate.
I will then link it here, I have drafted it already - it just awaits review.
Basically we can not do anything about the pcre.jit limit, but we do have plans to allow large content inputs in Toolset Access ShortCodes that also allow conditional display - but for HTML conditions we cannot resolve this issue other than suggesting to use fewer characters in the output content.
This is a limit that is bound to the language and the limits of the machine where it all runs (usually your server).
