mrgrooves
Forum Replies Created
-
Forum: Plugins
In reply to: [Query Monitor] Plugin fails entirely in 4.0 and 4.0.1Alright! Thank you very much, @johnbillion . The issue is now fixed for me. You’ve done a marvelous job with the plugin overall. It is amazing. Thank you so much!
Forum: Plugins
In reply to: [Query Monitor] Plugin fails entirely in 4.0 and 4.0.1I have the same problem. The plugin worked perfectly until I updated it to v4.0. I can no longer access anything in it. It does not show up when clicking on the Query Monitor tab in the admin bar on top.
The URL appends #qm-overview and that’s it.
4.0.1 also doesn’t work for me.
The fields I was trying to remove formatting from are custom fields. I use custom fields for product descriptions. They are most definitely not getting cleaned up from formatting by default and there is no way to clean them up using your plugin settings.
I ended up having to create a new custom field, copy the content from the original formatted custom field into it, while stripping all formatting, then mapping the new format-free custom field in your plugin.
I mentioned above that I ran mine in troubleshooting mode (with a default theme and minimum plugins). The issue persisted and is not related to any incompatibility with any other plugin or theme. Your plugin has a major bug. That is further supported by others’ reports.
The existing feeds were empty and impossible to populate. The refresh would work for a few seconds, but nothing would update. Creating a new feed and trying to generate content for it would just spin indefinitely at 0% progress. I, too, reverted back to the previous version of the plugin and was able to refresh the feeds.
The plugin ruined our feeds and merchant center listings.
The plugin messed up all feeds I previously had created and as a result, I lost 90 products from the merchant center!
The feeds are empty. When trying to rebuild the feeds, it doesn’t do it. Creating a new feed just dwells on “processing 0%”, never completing the task. Otherwise great plugin in the past is now broken and useless.
I am running the plugin in troubleshooting mode to avoid any potential plugin conflicts and still no good.
What have you, developers done to it? This is terrible.
Thank you.
A number of things have changed as I have done a lot of optimizations.
I assume that the xml file is being read from the database and is not saved to the disk where I can manually edit it?
I guess the way to resolve it would be to run in troubleshooting mode and enable one plugin at the time until I discover the culprit?
Thank you.
Thank you, Emre!
You bet I will! 👍
Well, it worked, but with errors. The carts were getting recovered. I added an exclude condition now similar to your suggestion (no regex) and the cart recovery works.
Thank you very much for pointing me in the right direction with regards to the regex warning.
I can’t exclude it, as we have already confirmed this with 100% certainty to be the issue. Without that specific rule, all abandoned cart urls were defaulting to the homepage. Unless you implemented some changes to the plugin since July 11, 2023 that would automatically exclude all URLs with string queries, there is no reason why it would now work.
Did you implement any such change?
There is a need, I am afraid. The cart rebuilding was not working without it and it took us ages to figure out the issue. Once I added the exclusion rule, the function worked.
Done. I added the rule like this now. It should work the same, but without the error, right?
Here.
According to ChatGPT (if it is of any help):
Potential Solution:
- The problem might be caused by the contents of
$value->contentnot being a properly formatted regex pattern. It’s possible that$value->contentcontains special regex characters that need to be escaped, or it forms an invalid regex pattern. - To fix this, you can use
preg_quote()to escape any special regex characters in$value->content. Here’s the modified line of code:
if(preg_match("/".preg_quote($value->content, '/')."/i", $request_url)){preg_quote()will escape any regex special characters in$value->content, making it safe to use inpreg_match(). The second parameter'/‘ is to escape any slashes since your regex pattern is delimited by slashes.
- The problem might be caused by the contents of
