midihead
Forum Replies Created
-
The issue doesn’t appear to be happening for me anymore. In my opinion, issues on YOUR server shouldn’t have the ability to cause OUR WordPress backends to be slow and timeout as they did. Please make changes to ensure that this doesn’t happen again to your users.
I am also now experiencing slowness and timeouts in the WordPress backend with Depicter active on WordPress 6.7.1 and Depicter 3.5.1. Here is a log that my hosting company shared which they said indicates that the slowness is caused by Depicter. Please fix this ASAP.
script_filename = /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-admin/admin-ajax.php
[0x00007f3b81a14e70] curl_exec() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-content/plugins/depicter/modules/GuzzleHttp/Handler/CurlHandler.php:44
[0x00007f3b81a14d00] __invoke() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-content/plugins/depicter/modules/GuzzleHttp/Handler/Proxy.php:28
[0x00007f3b81a14c20] Depicter\GuzzleHttp\Handler\{closure}() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-content/plugins/depicter/modules/GuzzleHttp/Handler/Proxy.php:48
[0x00007f3b81a14b50] Depicter\GuzzleHttp\Handler\{closure}() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-content/plugins/depicter/modules/GuzzleHttp/PrepareBodyMiddleware.php:64
[0x00007f3b81a14880] __invoke() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-content/plugins/depicter/modules/GuzzleHttp/Middleware.php:31
[0x00007f3b81a14710] Depicter\GuzzleHttp\{closure}() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-content/plugins/depicter/modules/GuzzleHttp/RedirectMiddleware.php:71
[0x00007f3b81a14540] __invoke() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-content/plugins/depicter/modules/GuzzleHttp/Middleware.php:66
[0x00007f3b81a14460] Depicter\GuzzleHttp\{closure}() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-content/plugins/depicter/modules/GuzzleHttp/HandlerStack.php:75
[0x00007f3b81a143b0] __invoke() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-content/plugins/depicter/modules/GuzzleHttp/Client.php:333
[0x00007f3b81a140e0] transfer() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-content/plugins/depicter/modules/GuzzleHttp/Client.php:169
[0x00007f3b81a13ee0] requestAsync() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-content/plugins/depicter/modules/GuzzleHttp/Client.php:189
[0x00007f3b81a13e20] request() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-content/plugins/depicter/modules/GuzzleHttp/ClientTrait.php:95
[0x00007f3b81a13da0] post() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-content/plugins/depicter/app/src/Services/RemoteAPIService.php:133
[0x00007f3b81a13b40] post() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-content/plugins/depicter/app/src/Services/ClientService.php:116
[0x00007f3b81a138f0] getAccessToken() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-content/plugins/depicter/app/src/Services/UserAPIService.php:83
[0x00007f3b81a13880] renewTokens() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-content/plugins/depicter/app/hooks.php:187
[0x00007f3b81a13800] depicter_renew_tokens() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-includes/class-wp-hook.php:324
[0x00007f3b81a13720] apply_filters() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-includes/class-wp-hook.php:348
[0x00007f3b81a136a0] do_action() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-includes/plugin.php:517
[0x00007f3b81a135c0] do_action() /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/wp-admin/admin-ajax.php:45My apologies for the misunderstanding. Seeing the “Edit Single Post”, “Edit Single Page”, etc. links pointing to
/wp-admin/admin.php?page=eos_dp_admin&paged=0gave me the impression that the plugins weren’t actually being disabled on those admin pages when in fact they were. Also, when I was previously viewing the page source on the admin pages, I was still seeing references to plugins that had been disabled but I now realize that this was because the admin menu items for those disabled plugins were still being displayed on the page. Thanks for explaining how to verify that plugins have been disabled using the Console.I’m not sure that linking the “Edit Single…” links to the last blog posts or pages is necessary. Making the “Edit Single…” links unclickable would probably make more sense to me.
Thanks!
Forum: Plugins
In reply to: [Depicter — Popup & Slider Builder] Depicter ignores no loop on video slideI am having the same issue with the videos on slides looping even though they are set not to loop. In my case, it seems to be causing an issue where the slide gets stuck and stops advancing to the next slide (even though I don’t have it set to pause on the video slide).
Forum: Plugins
In reply to: [GiveWP - Donation Plugin and Fundraising Platform] WP CLI broken with GiveAre you also running the Give PDF Receipts plugin? I have been getting the exact same error with it and WooCommerce for quite some time. My server crons also won’t run as they rely on wp-cli. If I deactivate Give PDF Receipts, then Give and Woocommerce don’t conflict for me and my crons work fine.
I reported this to Give Support back in November of 2023. If your issue is also related to using Give PDF Receipts, please consider going here (https://feedback.givewp.com/bug-reports/p/pdf-receipts-add-on-breaks-wp-cli-on-certain-servers) and upvote this issue so that hopefully they will fix it more quickly.
Yes, the beta version appears to have corrected the issue. I no longer see the page jumping happening on my staging site admin pages. Thanks!
@giuse,
The jumping happens only if you first scroll down on the main content on the right side of the admin page itself (not the sidebar) and then click any link on the page. If you scroll first and then click a link, you’ll see the jumping. I’m sorry that I missed clarifying this previously.I just sent you the credentials for my test staging site so that you can troubleshoot the issue. Thanks.
Jeff
Forum: Plugins
In reply to: [HEIC Support] Replace does not work because of file typeI can confirm the same issue and that the revised code by @marcguay temporarily fixes the replace issue. Looking forward to the permanent fix in the plugin. Thanks!
I’m also having the same issue. Making a slight change to a slide crops the images. Getting ready to ditch Depicter if they can’t recognize and fix the issue.
Forum: Plugins
In reply to: [Depicter — Popup & Slider Builder] Critical Error After Updating to PHP 8.0Thank you for pointing me in the right direction. It was indeed a server permissions issue. Cloudways fixed the server permissions and then added
define('FS_METHOD','direct');to my wp-config.php file which appears to have resolved the fatal error. Many thanks!Forum: Plugins
In reply to: [Depicter — Popup & Slider Builder] Critical Error After Updating to PHP 8.0The results in the error log when Depicter alone is active on a default WordPress theme:
Fatal error: Uncaught TypeError: ftp_nlist(): Argument #1 ($ftp) must be of type resource, null given in /home/xxxx.cloudwaysapps.com/xxxxx/public_html/staging-marlon/wp-admin/includes/class-wp-filesystem-ftpext.php:420 Stack trace: #0 /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/staging-marlon/wp-admin/includes/class-wp-filesystem-ftpext.php(420): ftp_nlist() #1 /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/staging-marlon/wp-content/plugins/depicter/modules/wpemerge-app-core/src/Assets/Assets.php(114): WP_Filesystem_FTPext->exists() #2 /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/staging-marlon/wp-content/plugins/depicter/modules/wpemerge-app-core/src/Assets/Assets.php(201): WPEmergeAppCore\Assets\Assets->generateFileVersion() #3 /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/staging-marlon/wp-content/plugins/depicter/app/src/WordPress/AssetsServiceProvider.php(36): WPEmergeAppCore\Assets\Assets->enqueueStyle() #4 /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/staging-marlon/wp-includes/class-wp-hook.php(308): Depicter\WordPress\AssetsServiceProvider->enqueueAdminAssets() #5 /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/staging-marlon/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters() #6 /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/staging-marlon/wp-includes/plugin.php(517): WP_Hook->do_action() #7 /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/staging-marlon/wp-admin/admin-header.php(118): do_action() #8 /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/staging-marlon/wp-admin/plugins.php(605): require_once('/home/xxxxx.cl…') #9 {main} thrown in /home/xxxxx.cloudwaysapps.com/xxxxx/public_html/staging-marlon/wp-admin/includes/class-wp-filesystem-ftpext.php on line 420So after some troubleshooting, I narrowed the issue down to a conflict between Profile Builder and the Party Propz extension in the ‘Ultimate Add-ons for Elementor’ plugin from Brainstorm Force. When the Party Propz extension is enabled, it causes the form to not be visible when using your Edit Profile Elementor widget. For now, I have disabled the Party Propz extension but it would be nice if this conflict could be resolved in case I ever want to use the Party Propz extension while Profile Builder is active.
Here is a short video demo showing the issue after creating a new page, adding the Elementor Edit Profile widget, saving, then going back later to try to edit the styling on the form:
