breckf
Forum Replies Created
-
Hi Kousik,
My sincere apologies.
I’ve just realised that I made a mistake in my issue tracking spreadsheet. I cross-referenced the error above, with grep results for “bv-order-status” from within the error against your plugin due to the company name BlogVault “BV”. The issue is, as you’ve suggested, another plugin. In this case it’s where the authoring company has changed their name from a “BV” abbreviation to “BP” but not updated their plugin legacy artefacts inline to reflect the rebrand.
My fault for not checking my work twice after pasting.
Again, apologies, I’ve now checked their support forum and others have raised this same issue, still awaiting a fix.
Thanks for looking into this.
Breck
Morning Kousik,
Only the client’s staging site has been updated at his time, https://staging.suncoasttruckspares.com.au while we assessed any issues arising from the major version updates on their site.
regards
Breck
Hi Kousik,
Thanks for the fast response. I’ve left the office for the weekend. It’s not a plugin conflict, it’s a wordpress change as of …either version 6.7.2 or 6.8.1, I forget. I’ll say the majority of plugins out there have probably had to adjust for it as it caught most unaware.
I’ve raised similar tickets with a number of other plugins myself as we encounter it after updating the our clients’ site wordpress version. All of those have now been actioned. This site was the first we’ve encountered with your plugin.
If you google, or even search this WordPress support site, for the error or just _load_textdomain_just_in_time you’ll find many cases and perhaps some guidance to assist the update in your plugin.
The impact is only noticed when running in debug mode, which we do when maintaining or updating sites. Effectively it spams that php notice into the debug log. The problem is that spams about every second or so.
cheers
Breck
*bump*
Any word of a fix for this issue?
Hi @aamiribsf,
Thanks for letting me know. I’ve just updated the site with the problem with the new version and I can confirm this issue has stopped for your plugin.
Thanks very much for the fast turnaround. I’ve installed the update and can confirm that the debug log notice spam has stopped immediately.
Too early to advise if any other issues may have arisen with the new version but if anything pops up I’ll let you know.
This issue can now be considered resolved.
Thank you
Thank you
Thanks very much for getting back to me so quickly with that detail. I’ve passed it on to the client.
Definitely would be worth adding that detail above to the KB as even within the KB, all examples show a gap.
Forum: Plugins
In reply to: [WP Crontrol] Run Now… Sometimes does, sometimes doesn’tThanks John. I’ll look into that timeout and the spawn job on the client sites.
Irritatingly I know the site I was working on today has the croon set to run every minute and it spawns immediately. So I assume it’s not that.
But I had wondered previously if there was something like that in place as on other sites when I would try to manually trigger the cron from shell on some sites it would not allow it to trigger for a seeming period. I had wondered if doing_cron or some such was still set and preventing a new spawn.
Forum: Plugins
In reply to: [WP Crontrol] Run Now… Sometimes does, sometimes doesn’tI just noticed that in the latest version 1.15.0 there is also now another action type on the backdated event that gets scheduled to run. Not sure if this was always there but I don’t recall seeing it.
The extra action is Delete All 2.
Forum: Plugins
In reply to: [WP Crontrol] Feat. Req: Show current site time on Add New pageJust checking in to confirm the site time displays on the Add New event page in 1.15.0
Thought it hadn’t as only the timezone was still displaying under the Next Run section. However, it displays at bottom of page as
Site time when page loaded: 2022-12-14 08:11:54 (UTC+10)
which ticks the necessary boxes.
Thanks for that.
Figured it might be something like that. Either way, I’m happy.
Whoops. I responded to the wrong topic. (facepalm)
Will update on the correct one for completeness.
Just checking in to confirm the site time displays on the Add New event page in 1.15.0
Thought it hadn’t as only the timezone was still displaying under the Next Run section. However, it displays at bottom of page as
Site time when page loaded: 2022-12-14 08:11:54 (UTC+10)
which ticks the necessary boxes.
Thanks for that.
Update: Problem found, but exact cause may be environmental.
Thanks for your feedback, John. After spending a day debugging and researching yesterday, I contacted our host this morning and found out two things from them.
1. That the host ModSecurity logs page is not displaying any log messages. Sigh… So much time spent. Anyhow, that’s now been raised with them to resolve.
2. That it was indeed triggering a ModSecurity rule. Specifically, the LDAP Injection Attack rule 211030 :
[Rule: ‘&ARGS:newspost.add’ ‘@eq 0′] [id “211030”] [rev “3”] [msg “COMODO WAF: LDAP Injection Attack”] [logdata “Matched Data: ) && ( ” ! found within if( isset( $item->category ) && ( ” != $item->category ) ) return;: if( isset( $item->category ) && ( ” != $item->category ) ) return;”] [severity “CRITICAL”] [tag “CWAF”] [tag “Other”]Adding a whitelist for this rule to .htaccess resolves the problem.
I believe that this is a false positive being returned here. But I’m not yet aware of what exactly is causing it as it only occurs on a couple of our clients’ websites, on the same hosted shared server. So, potentially something about their package, configuration or plugin/themes may be causing this.
For now, the site resolution is a whitelist. Soon, I’ll evolve our plugin further to actually call our regular scripting via hook only, thereby bypassing the potential for this issue entirely.
Cheers