George Nagy

@geraltrivia The OP’s debug output does not contain a “Class not found” message. We are getting the same error after the latest update (4.30.0):

PHP Fatal error: Uncaught MailPoet\InvalidStateException: MailPoet version update is in progress, please refresh the page in a minute. in /wp-content/plugins/mailpoet/lib/Config/Activator.php:65 

Please review this in more detail and provide an update on a solution.

The path filter is working correctly for me. Here is how to implement:

Add the following to your functions.php file:

add_filter( 'acf-flexible-content-preview.images_path', 'get_acf_preview_path' );

function get_acf_preview_path() {
    return 'img/acf-previews';
}

The above would set the plugin to look for your preview images in /wp-content/themes/your-theme-folder/img/acf-previews/.

The images need to be in JPG format and underscores need to be changed to dashes. For example, if your layout name is “my_great_layout”, the preview image filename would be “my-great-layout.jpg”.

@jmbarroso84 Go into Google Tag Manager and setup a new trigger with the following details:

• Trigger type: Element visibility
• Selection method: CSS Selector
• Element selector: .mailpoet_validate_success (note the period in front of the class name)
• When to fire this trigger: Every time an element appears on screen
• Minimum Percent Visible: 100
• This trigger fires on: All visibility events

Use the trigger to fire a Google Analytics tag to send through an event.

• This reply was modified 5 years, 7 months ago by George Nagy.

This is an issue for me as well. Running WP v4.9.4, ACF Pro v5.6.8, and Yoast v6.3.

Overall this is a great plugin! The hard work put in by the developer to build this plugin is much appreciated. Looking forward to the next update for a fix.

Thanks for the follow-up Jeff. This thread references the same issue with the profile page redirect which seems to be a conflict with the All In One WP Security plugin which is active on my site as well.

https://www.ads-software.com/support/topic/conflict-with-all-in-on-wp-security-plugin/

Deactivating the AIOWPS plugin resolved the profile redirect conflict with TML.

Nothing jumping out in the AIOWPS changelog that would serve as a starting point for understanding what is going on. Next step will be to roll back to a previous version of AIOWPS plugin to see if the issue persists there which would help narrow down the issue.

@keneucker is correct in saying that WordPress core and plug-in files should not be altered, except by their respective authors. In this case however the issue with the plug-in is pretty clear, the author acknowledged the bug, and has indicated it will be fixed in the next release. The updated version of the plug-in will presumably have a fix similar to the one I outlined previously and everything should continue to function normally post-update.

Glad to hear that the hotfix is working for people.

These errors are showing up because there are classes defined that extend built-in WordPress classes. The extender classes need to have exactly the same parameters defined. For example, with the start_el error, the extender function should have these parameters (as of WordPress v4.2.2 – the parameters may be different for the version you’re using.)

function start_el( &$output, $page, $depth = 0, $args = array(), $current_page = 0 ) {

This article references a similar issue:
https://stackoverflow.com/questions/9734422/errors-when-trying-to-integrate-wordpress-on-my-existing-website

As Marius suggested, updating your site to the latest version of WordPress is always recommended. Running an old version opens you up to potential security vulnerabilities.

This is a pretty easy fix. The issue is in the Admin.class.php file which is found here:

/wp-content/plugins/exports-and-reports/wp-admin-ui/Admin.class.php

There is an attempt to utilize a WordPress constant (WP_CONTENT_DIR) before the WordPress environment is loaded. These lines:

if ( ! defined( 'WP_ADMIN_UI_EXPORT_DIR' ) ) {
    define( 'WP_ADMIN_UI_EXPORT_DIR', WP_CONTENT_DIR . '/exports' );
}

Should be moved below the wp-load.php block. The final code should look like this:

global $wpdb;
if(!is_object($wpdb))
{
    ob_start();
    if(file_exists(realpath('../../../../wp-load.php')))
        require_once(realpath('../../../../wp-load.php'));
    else
        require_once(realpath('../../../wp-load.php'));
    ob_end_clean();
}

if ( ! defined( 'WP_ADMIN_UI_EXPORT_DIR' ) ) {
    define( 'WP_ADMIN_UI_EXPORT_DIR', WP_CONTENT_DIR . '/exports' );
}

Glad to hear that MailPoet is still alive and well… although this adds to the confusion as to why, being a premium subscriber, I never heard back after submitting 3 support tickets over the course of 4 days. There was a confirmation message after each ticket submission on the MailPoet site indicating it was processed… but again, never got a reply. I saw replies from MailPoet on here, so thought I might have a better chance of getting a reply.

Regardless, the issue has been resolved. Thanks for the follow-up.

This has been resolved. It ended up being an issue with http versus https. When MailPoet Premium is setup to utilize MailPoet’s servers to trigger sending via wp-cron.php, apparently it only looks at http… so if requests for wp-cron.php are forwarding to https://domain.com/wp-cron.php, MailPoet’s servers will not be able to find the file to trigger it. Seems like something they should be checking for.

Also worth noting – despite being a premium customer, which guarantees a 24 hour response to support issues – I never heard back from MailPoet either via their support system or here on the forums. It’s possible they are no longer is business… something to keep in mind if you had planned on purchasing a premium license.