dcnz

Same thing happening for me as well. And it’s a real pain because 3.23.4 has a XSS vulnerability and needs to be updated but 3.24.1 breaks the website. So either we wait for another fix, or update and then rollback to 3.24.0. And that’s not something I want to do on 100+ websites. Come on Elementor, figure it out.

@qriouslad – The latest version has now resolved my issue. Thanks for your help!

@qriouslad it was on a client site using Astra, Astra Pro & Elementor. It was happening on a product page that has product addons using the WooCommerce Product Addons Ultimate plugin (https://pluginrepublic.com/wordpress-plugins/woocommerce-product-add-ons-ultimate/).

When clicking the add to cart button it would try to load an Astra JS file but would get a 404 and not work.

Also have WP Rocket installed and it would fail to load a JS file from that on the product page.

I’m not in my office so can’t look up the exact details right now but can tomorrow.

Yeah, this isn’t any issue with the plugins we both mentioned. It’s an issue with the menu slug that Elementor is using for the settings page as it obviously conflicts with other plugins that use the same (or similar) slug.

Elementor is using a generic menu slug for the settings page – /wp-admin/admin.php?page=settings

To stop conflicts (and potential future conflicts) with other plugins, you should be using something like ?page=elementor_settings which then follows a similar naming convention as your other menu items. A pretty major oversight on your end if you ask me.

So far so good ??

Ok I just set up a test site to try replicate it myself.

I’ve worked out that if I edit the page in Elementor via the back end it wouldn’t trigger a fatal error.

But if I view the page normally on the front end and then click Edit with Elementor from the admin bar at the top, I will get the ‘Your Site is Experiencing a Technical Issue’ email. And that’s without editing anything on the page and only opening it in Elementor.

But it doesn’t seem to do it every time. Only if it’s the first time editing a page via the front end after updating the Instant Images plugin. I’ve tried editing other pages after the fact, but it doesn’t trigger the fatal error.

I tried the same method on another website that’s running Elementor 3.10.2 / Elementor Pro 3.10.3 and updated the Instant Images plugin to the latest version. Then edited a page in Elementor via the front end and it triggered the same fatal error. After that, I tried editing other pages and didn’t get the fatal error.

But it doesn’t stop me from editing that page or others or even viewing the website normally.

Instant Images 5.2.0.1, Elementor 3.11.5 and Elementor Pro 3.11.7.

PHP version 8.0.28 if that helps.

Is this on a standard front-end editor screen when using the Image module? – I wasn’t accessing Instant Images as per your screenshot. I edited some text on the page in Elementor, updated the page, and then received the Your Site is Experiencing a Technical Issue email.

Are there fatal errors on frontend or is this in the debug logs? – For this particular site I didn’t have a visual fatal error and could still edit the page. But on another site I’ve had it where I had the white screen of death on the front end.

I get the same error with Elementor too. Hopefully this helps:

Error Details
=============
An error of type E_ERROR was caused in line 180 of the file /container/application/public/wp-content/plugins/instant-images/instant-images.php. Error message: Uncaught Error: Call to undefined function get_current_screen() in /container/application/public/wp-content/plugins/instant-images/instant-images.php:180
Stack trace:
#0 /container/application/public/wp-includes/class-wp-hook.php(308): InstantImages->instant_img_wp_media_enqueue('')
#1 /container/application/public/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters('', Array)
#2 /container/application/public/wp-includes/plugin.php(517): WP_Hook->do_action(Array)
#3 /container/application/public/wp-includes/media.php(4747): do_action('wp_enqueue_medi...')
#4 /container/application/public/wp-content/plugins/elementor/app/modules/onboarding/module.php(460): wp_enqueue_media()
#5 /container/application/public/wp-includes/class-wp-hook.php(308): Elementor\App\Modules\Onboarding\Module->Elementor\App\Modules\Onboarding\{closure}('')
#6 /container/application/public/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters(NULL, Array)
#7 /container/application/public/wp-includes/plugin.php(517): WP_Hook->do_action(Array)
#8 /container/application/public/wp-content/plugins/elementor/includes/plugin.php(652): do_action('elementor/init')
#9 /container/application/public/wp-includes/class-wp-hook.php(308): Elementor\Plugin->init('')
#10 /container/application/public/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters(NULL, Array)
#11 /container/application/public/wp-includes/plugin.php(517): WP_Hook->do_action(Array)
#12 /container/application/public/wp-settings.php(617): do_action('init')
#13 /container/application/public/wp-config.php(97): require_once('/container/appl...')
#14 /container/application/public/wp-load.php(50): require_once('/container/appl...')
#15 /container/application/public/wp-admin/admin.php(34): require_once('/container/appl...')
#16 {main}
  thrown

@merdman2 – Thank you! That saved a client site. I did extensive troubleshooting and narrowed down the problem to WooCommerce itself. All I had active was the Twenty Twenty theme and WooCommerce and I couldn’t access wp-admin. It would time out or not load at all and narrowed it down to this:

An error of type E_ERROR was caused in line 315 of the file /wp-content/plugins/woocommerce/packages/woocommerce-admin/src/API/Reports/TimeInterval.php. Error message: Maximum execution time of 90 seconds exceeded

But when I changed to PHP 8, wp-admin loaded fine. But then other WooCommerce plugins would break and have fatal errors on the front end so I had to change back to PHP 7.4.

So your snippet worked a treat!

@bitseven I used a plugin called WP Rollback to downgrade both plugins. But the zip files are downloadable from each plugin page. In the right sidebar of the home page for the plugin, click on Advanced View. Then scroll down to the bottom of the page and you can select an old version to download.

Same thing happened for me. I had to rollback this plugin back to 1.0.5 and the main Download Manager plugin back to 3.1.28.

You really need to make sure your add-ons are working 100% before releasing the updates.

It’s not working with 4.7.5 either. We have about 70+ websites and 90% are running 4.8 and the rest 4.7.5 and it’s not working in either version. I’ve deauthorised & reset the plugin on a few sites but it doesn’t fix it.

Maybe something has changed with the Google API?

Hope it’s fixed soon as I don’t feel like changing to a different plugin.

Best way to probably do it is change the dropdown options in the backend from ‘Rent’,’Sale’ to ‘For Rent’,’For Sale’.

Then to output that field correctly you would use:

<?php if( !empty( $property['rentsale'] ) ): ?>
   <div class="rent_sale"><?php echo $property['rentsale']; ?></div>
<?php else: ?>
   <?php echo "See More"; //Not sure why you need this ?>
<?php endif; ?>

Hope that helps.

Ok so I found the solution myself. After trying many different things, the answer was actually quite simple. And that was to use wpautop https://codex.www.ads-software.com/Function_Reference/wpautop

And here’s the code to output the post content and keep the P tags intact:

<?php if( !empty( $property['post_content'] ) ): ?>
<div class="property_content"><?php echo wpautop( $property['post_content'] ); ?></div>
<?php endif; ?>

That’s cool.

Do you think it could be added as a feature in the future?