Fatal error: $settings must not be accessed before initialization

  • Resolved Bogdan

    (@bogdanguenther)


    4 months, 3 weeks ago

    Plugin version 2.4.0:

    [13-Jan-2026 10:56:24 UTC] PHP Fatal error:  Uncaught Error: Typed property Legacy\EmailEncoderBundle\Email_Encoder_Settings::$settings must not be accessed before initialization in /wp-content/plugins/email-encoder-bundle/core/includes/classes/class-email-encoder-bundle-settings.php:459

Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author Ivan

    (@ooivan)

    4 months, 3 weeks ago

    Hi Bogdan

    Thanks for reporting this. I’m looking into it, but so far I haven’t been able to reproduce the issue.

    Could you please share a bit more information, along with your plugin settings? A screenshot would be perfect (feel free to blur or black out anything sensitive). That should help me track down what’s going on.

    Thank you!

    Thread Starter Bogdan

    (@bogdanguenther)

    4 months, 3 weeks ago

    Hi Ivan,

    I analyzed the whole WordPress install in regard of this error using Cursor and got this analysis:

    Root CauseThe error occurs in class-email-encoder-bundle-settings.php at line 459, which is the first line of the get_setting() method:class-email-encoder-bundle-settings.phpLines 90-93

    public function get_setting( $slug = ”, $single = false, $group = ” ) {

        $return = $this->settings;  // Line 459 – This accesses $settings
    <canvas width=”0″ height=”132″></canvas><canvas width=”0″ height=”132″></canvas>The issue is that the $settings property is declared as a typed property without a default value:class-email-encoder-bundle-settings.phpLines 46-46

    private array $settings;

    <canvas width=”0″ height=”60″></canvas><canvas width=”0″ height=”60″></canvas>In PHP 7.4+, typed properties without default values are in an “uninitialized” state until explicitly assigned. Accessing an uninitialized typed property throws a fatal error.Why This Happens on Your SiteThe load_settings() method that initializes $this->settings is hooked to WordPress’s init action at priority 10. However, other methods that call get_setting() are also hooked to init at the same priority:

    1. load_email_image_secret() – calls get_setting() on line 174
    2. Email_Encoder_Ajax::register_hooks() – calls get_setting() on line 29

    While hooks at the same priority usually execute in the order they were added, something on your specific site could be:

    • Interfering with hook execution order
    • Calling the singleton instance early
    • A plugin conflict (possibly with WP Rocket, Matomo, or one of the Crocoblock plugins)

    The FixThe solution is to initialize the $settings property with a default empty array:In wp-content/plugins/email-encoder-bundle/core/includes/classes/class-email-encoder-bundle-settings.php, change line 46 from:

    private array $settings;

    <canvas width=”0″ height=”60″></canvas><canvas width=”0″ height=”60″></canvas>To:

    private array $settings = [];
    <canvas width=”0″ height=”60″></canvas><canvas width=”0″ height=”60″></canvas>This ensures the property is always initialized, preventing the fatal error even if get_setting() is called before load_settings() runs.Why Other Sites Don’t Have This IssueYour other sites likely have:

    • Different plugin combinations that don’t interfere with hook timing
    • Different caching configurations
    • The error might only occur during specific scenarios (like cron jobs at 06:58 UTC when this error occurred)

    I hope this helps fixing the error.

    • This reply was modified 4 months, 3 weeks ago by Bogdan.
    Plugin Author Ivan

    (@ooivan)

    4 months, 3 weeks ago

    Hi @bogdanguenther

    Thanks for posting this, but the analysis doesn’t really help me diagnose the issue.

    The error is coming from a legacy part of the code where a lot of things were initialised in the constructor. That was fine at the time, but it’s not how the plugin is meant to be used in its current, more modern structure, mainly for reliability, performance and security reasons.

    What this error is actually doing is exposing a bug that occurs when something is used in a way I didn’t anticipate. To fix it properly, I need to understand the context in which it happens. The real problem is most likely somewhere else, not at the point where the error shows up.

    Can you tell me how you’re using the plugin? For example, are you using shortcodes, calling its functions directly from template files, or something else?

    If you can also share your plugin settings, I should be able to reproduce the issue and implement a proper fix.

    Plugin Author Ivan

    (@ooivan)

    4 months, 3 weeks ago

    Hi @bogdanguenther

    I’ve just pushed an update (v2.4.1) that should resolve the issue you’re seeing.
    Please let me know if it works as I had to implement the fix without being able to reproduce your exact scenario.

    To prevent this from happening again, it would really help to understand how you ended up in that state.
    If you can share the steps leading up to the error (even roughly), or details about your setup, that would be hugely appreciated.

    Thanks!

    Thread Starter Bogdan

    (@bogdanguenther)

    4 months, 3 weeks ago

    Hi Ivan,

    Thank you for the fast fix! I am using quite a lot of plugins on that site, here is what Cursor found out further, when I asked what plugin or code in my theme could trigger this problem:

    Most Likely Contributing Factors

    1. Crocoblock Plugins (JetEngine + Jet Smart Filters)Both plugins use extremely early init hook priorities:jet-smart-filters.phpLines 95-97

    add_action( ‘init’, array( $this, ‘lang’ ), -999 );

    add_action( ‘init’, array( $this, ‘init’ ), -999 );

    <canvas width=”0″ height=”96″></canvas><canvas width=”0″ height=”96″></canvas>jet-engine.phpLines 162-164

    add_action( ‘init’, array( $this, ‘lang’ ), -999 );

    add_action( ‘init’, array( $this, ‘init’ ), -999 );

    <canvas width=”0″ height=”96″></canvas><canvas width=”0″ height=”96″></canvas>These run way before email encoder’s hooks at priority 10. While they don’t directly call email encoder, their heavy early initialization (loading many classes, database queries, etc.) could potentially affect the WordPress action queue or hook execution timing.2. WP Rocket’s Cron JobsThe error occurred at 06:58:49 UTC (early morning), which is typical cron timing. WP Rocket runs multiple scheduled tasks every minute:

    • action_scheduler_run_queue
    • rocket_preload_process_pending
    • action_scheduler_run_queue_rucss

    During these background processes, plugins might initialize in a slightly different context than normal page loads.3. The Combination EffectYour site has a unique combination:

    • 30+ active plugins (including heavy ones like Elementor, JetEngine, Jet Smart Filters, Gravity Forms, Matomo)
    • Action Scheduler running from multiple plugins (WP Rocket, WP Mail SMTP, Sugar Calendar, Post Expirator)
    • Early priority hooks from Crocoblock plugins

    Why Other Sites WorkYour other sites likely have:

    • Different plugin combinations
    • Fewer or different caching/scheduling mechanisms
    • Different execution contexts for cron jobs

    Root CauseThe fundamental issue is in the email-encoder-bundle plugin itself – it declares a typed property without a default value:

    private array $settings;  // Should be: private array $settings = [];

    <canvas width=”0″ height=”60″></canvas><canvas width=”0″ height=”60″></canvas>This is a PHP 7.4+ bug in the plugin that only manifests under certain timing conditions that happen to occur on this specific site.

    I hope that helps,
    Bogdan

    Thread Starter Bogdan

    (@bogdanguenther)

    4 months, 3 weeks ago

    Regarding using the plugin:

    I don’t use shortcodes it is just active with this settings:

    https://share.medianotions.de/share/n5pbgka9nBbEn6QgOPKr

Viewing 6 replies - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.