oakleystudio
Forum Replies Created
-
Me too. I’m reporting here the same issue with my own business website. If you’ve Resolved this issue, would you please post your recommendations here for the rest of us.
Here is what I see in the debug log (edited to remove file path details):
[11-May-2022 17:09:00 UTC] PHP Warning: Illegal offset type in isset or empty in /wp-includes/plugin.php on line 174 [11-May-2022 17:09:00 UTC] PHP Warning: Illegal offset type in isset or empty in /wp-includes/plugin.php on line 174 [11-May-2022 18:10:46 UTC] PHP Warning: Illegal offset type in isset or empty in /wp-includes/plugin.php on line 174 [11-May-2022 18:10:46 UTC] PHP Warning: Illegal offset type in isset or empty in /wp-includes/plugin.php on line 174 [11-May-2022 18:11:12 UTC] PHP Warning: Illegal offset type in isset or empty in /wp-includes/plugin.php on line 174 [11-May-2022 18:11:12 UTC] PHP Warning: Illegal offset type in isset or empty in /wp-includes/plugin.php on line 174 [11-May-2022 18:11:26 UTC] PHP Warning: Illegal offset type in isset or empty in /wp-includes/plugin.php on line 174And here is a chunk of the slow PHP log file:
[11-May-2022 12:26:23] [pool hikers] pid 12444 script_filename = /index.php [0x00007faf77013ec0] sleep() /wp-content/plugins/mailpoet/lib/Cron/DaemonHttpRunner.php:113 [0x00007faf77013e50] pauseExecution() /wp-content/plugins/mailpoet/lib/Cron/DaemonHttpRunner.php:101 [0x00007faf770139c0] run() /wp-content/plugins/mailpoet/lib/Router/Endpoints/CronDaemon.php:42 [0x00007faf77013940] run() /wp-content/plugins/mailpoet/lib/Router/Router.php:68 [0x00007faf770138d0] call_user_func() /wp-content/plugins/mailpoet/lib/Router/Router.php:68 [0x00007faf77013830] init() /wp-content/plugins/mailpoet/lib/Config/Initializer.php:369 [0x00007faf770137b0] postInitialize() /wp-includes/class-wp-hook.php:307 [0x00007faf770136d0] apply_filters() /wp-includes/class-wp-hook.php:331 [0x00007faf77013660] do_action() /wp-includes/plugin.php:474 [0x00007faf77013580] do_action() /wp-settings.php:609 [0x00007faf770133d0] [INCLUDE_OR_EVAL]() /wp-config.php:98 [0x00007faf770131a0] [INCLUDE_OR_EVAL]() /wp-load.php:50 [0x00007faf77013100] [INCLUDE_OR_EVAL]() /public/wp-blog-header.php:13 [0x00007faf77013070] [INCLUDE_OR_EVAL]() /index.php:17Does this tell you anything useful?
Forum: Plugins
In reply to: [Remove Dashboard Access] Conflict with MailPoet PluginThis may be relevant… the MailPoet “Manage Subscriptions” page is where subscribers can subscribe/unsubscribe to 10 different email newsletters. The form submits to:
/wp-admin/admin-post.php
And once MailPoet updates the users’ preferences, it redirects back to the “Manage Subcriptions” page, with a message saying preferences have been updated.
It appears that “Remove Dashboard Access” is preventing the form from being submitted to that Admin page.
A previous post had suggested that there should be a way to allow “exceptions” to the “Remove Dashboard Access” plugin so that Admins can specify specific URLs that should be allowed. Are we close to having an update that includes that functionality?
~ Pete O, webmaster
Forum: Plugins
In reply to: [Pods - Custom Content Types and Fields] Error when updating WP User accountsA “backtrace log” ? Please let me know what that is, and how to produce it, and I’ll be happy to get it for you.
~ Pete O
I’m probably not going to be sending you the database export from this site (no PHPadmin, and besides, no plugin devs have ever made such a request when I report an issue with their product.)
I asked a question in my previous post, maybe you missed it… Have you tested the current version of FileBird with the new WordPress v5.5 which is out now?
Ok, just so you know, this is on a website I have upgraded to WordPress v5.5. Have you tested FileBird on v5.5?
I’d be happy to send you whatever you need to resolve this. My client seems eager to have this working. But I am not sure what you mean by “please export the database to …” Is there something in the FileBird configuration/settings where I do this? Please give me some guidance.
Forum: Plugins
In reply to: [WP Activity Log] upgrade to 4.1.3.1 broke plugin and restrict acccessFYI: Here is the error message I am seeing in the Dashboard…
WordPress database error: [Table 'mrgwater-wp-eAWTZHDk.wp_235f16480d_wsal_options' doesn't exist] SELECT * FROM wp_235f16480d_wsal_options WHERE option_name = 'wsal-version'Following that error, there are other WordPress errors complaining that headers have already been sent. (Presumably by the database error from your plugin.)
Hope that helps you figure out how to fix this.
- This reply was modified 5 years, 10 months ago by oakleystudio. Reason: Additional info
Forum: Plugins
In reply to: [WP Activity Log] upgrade to 4.1.3.1 broke plugin and restrict acccessWill you be fixing this in an update to 4.1.3.1? Not many WordPress users will know how to edit their database table to accomplish this.
Thanks, the fix seems to work. No more error. I appreciate your quick response — thanks.
Here is the error:
Fatal error: require_once(): Failed opening required ‘webdados_invoicexpress_nag.php’ (include_path=‘.:/opt/sp/php7.1/lib/php’) in […]/public/wp-content/plugins/shop-as-client/shop-as-client.php on line 231
There has been a critical error on your website. Please check your site admin email inbox for instructions.I ran mysqlcheck on my site’s database tables and all were OK. What we discovered was that exporting Divi “Theme Options” from the working site and importing to the non-working site was able to get Awesome Support working properly with Divi. But why? To figure that out, I needed to compare all the settings in Theme Options, find all the differences, and see which specific setting was causing Awesome Support to stop working.
It was not at all obvious, but after much testing over the past 10 days, I’ve can reliably “flip a switch” in Divi Theme options and get Awesome Support to work properly or not work (ie: not display all replies to users.)
And the switch is (TA-DA!) “Grab the first post image” on the first “General” page of Divi Theme Options. This is Disabled by default. When Enabled (as it is on my Live site), it causes Awesome Support to not display ticket replies properly to support users.
Melliesou, thanks for hanging in there (for a few weeks!) while we were digging into this to arrive at a solution. Hope it helps you provide support for other Divi users in the future. As you encounter other Divi sites that have issues with Awesome Support, this is one possible solution. And I think it’s on Divi to fix this conflict in a future update.
Divi tech believes they have found a solution, related to Divi’s “Theme Options.” These options can be exported from one site and imported to another. We are now testing to see if that works reliably to solve this issue. It’s also possible that my site database has some corruption, so I will be looking into repairing, if that is called for. Will keep you posted.
Key differences: On my Staging site (copy of my Live site, where I first discovered this issue 8 days ago) Awesome Support displays only Ticket title and original support request — no buttons or form to add a new reply. While on the divi-test site, Awesome Support displays Tickets just fine.
Both sites have over a dozen other plugins installed, all TURNED OFF for testing. The Staging site had “Additional CSS” customization but that has been removed for testing. No customizations to the WordPress files themselves have been made to either site.
Divi technical support are focusing on how your Awesome Support form templates are supposed to load, and have a very specific question about that. (See their question in my first post from today.)
So before we go guessing at other possibilities, can you see if your developers have a response to Divi tech’s question?
Please do not mark this support test “Resolved” just yet.
Here is some info from Divi technical support…
“I checked all possible settings however they look the same as on another website that you have. And I also do not see any PHP or JS errors.”
“The template of the form is not loading on tickets. I am not sure how the template is loading exactly since it’s not our plugin. Please reach out the plugin developers and ask them to trace this, they know their plugin better and should be able to do that. Seems like there is a condition that return false and template is not loading, however I can’t tell for sure. This issue is not related to CSS and pseudo elements.”
“Also the ticket post type is loading page template which doesn’t look correct since custom post types should load single.php if it exist in the theme. I added the following code to check this:”
[ screenshot ]*
“Please verify with the plugin developers if this is intended behaviour. Let me know what they say!”
You can view the screenshot on my Staging website here:
https://staging.oakleystudio.com/wp-content/uploads/Divi-AS-Editor.pngAnd here is another screenshot of the User ticket, showing just Title and original support request, with no replies visible, and no form for a User to add their own reply.
https://staging.oakleystudio.com/wp-content/uploads/TicketTitleNoReplies.pngIt looks like this is back to you.
