The behaviour changes by reducing the content of some modules. Therefore, we believe it is a matter of size. We have also tried the exclusion of some parts of the page and some components with no success. We are trying to understand this issue since several weeks now.
We incremented PHP memory limit from 128MB to 256MB with no success. We do not believe that this is the issue. Is there any way to debug and find out where the plugin finds an issue or has a bug. Any other idea?
Can you give me (super) admin and (s)ftp access so I can take a look?
You can use the 'Confidential information' button in the forum editor to hide sensitive information.
Yes, for privacy and GDPR reasons we shall give you access to a pseudonimyzed environment. We are setting up it and will give you access asap. Many thanks for support and kind regards. P.s. I will use the confidential button.
I can't do much with just the admin access.
Also, I seem to have admin and not super admin access. And therefore don't have access to the eventbooking component.
So I can't check much.
Are you able to reproduce the issue in normal articles?
I now provided super user privileges.
The issue is very "tricky", as it occurs only in some pages of the eventbooking component. Currently we have it in the page mentioned above. However, from a visits point of view, these are among the most immportant.
We don't use much normal articles.
Kind regards,
I am not too familiar with the eventbooking component.
How can I get to the events to change/test things? I don't see the component in the administrator side...
The pages are generated using the categories of the eventbooking component. You can access here
test-www.innovativelearning.eu/administr...king&view=categories
The html code is specific per language and you find it in the Description field.
However, the full page is composed using also other components (not only eventbooking).
We will start the authorization process with IT.. not immediate.
Are there specific requirements? To which paths do you need to access?
You should consider to enable some "tracing/debugging" capabilities in Quickindex.
Kind regards.
Meanwhile, our development has found where the issue is. It is in the feil and src/Replace.php. In particulare, the function RL_RegEx::matchAll($regex, $string, $matches). It is executed but there is too much text and it fails. Unfortunately, it does not report any error. As a consequence, the plugin does not match tags in code. We implemented a workaround eliminating our component with huge amount of text without any h header (we call it rotator) from the scope of the Quickindex and then adding the html content to the page. However, the issue could arise in any other type of page and needs some fixing from your side. I hope that it is clear enough as I am not a developer. Let me know if you need more information. Find below a screen with the modified code.
www.dropbox.com/s/g4kjo6xkvcmtyml/image_..._02_42_005Z.png?dl=0
Kind regards.
The content is a list of courses that is dynamically extracted by a query. Not easy to restructure the content that is dynamic and with no h tags (no need to parse by quickindex). I guess there can be many other situations like ours.
We have changed PHP memory limit from 128MB (working for all pages but these) to 256MB. It's quite a lot but with no success.
For now, we solved with a workaround but having more control on quickindex scope would be preferable.
May be an input for next releases.
Kind regards
You can only post on the extension support forum if you have an active subscription and you
log in