E-Newsletter plugin conflict (get_current_screen not found)

I'm getting a conflict between the new E-Newsletter Editor and a plugin called Page Security by Contexture.

The error is Fatal error: Call to undefined function get_current_screen() in /opt/lampp/htdocs/canhc/wp-content/plugins/contexture-page-security/core/CTXPS_App.php on line 62

Basically, Email_Newsletter_Builder::construct_builder_head calls the admin_head action without including the Admin Screen API (wp-admin/includes/screen.php).

I believe any other plugin that hooks into admin_head and depends on the Admin Screen API will be similarly broken.

Steps to reproduce:
Install E-Newsletter 2
Install Page Security by Contexture
Try to create a newsletter

  • Vaughan
    • Support/SLS MockingJay

    hiya

    thanks for posting.

    I'm not so sure this is a problem with Apps+, but i'm no expert.

    I do see that page security by contexture is an out of date plugin though & hasn't been updated since 2012. this could also be a problem with that plugin.

    i will flag the developer so he can assess this and try & determine if apps+ is the plugin to blame, or whether it is indeed the page security plugin.

    thanks for the report, if you require any further assistance, please ask.

    thanks.

  • webrn
    • WPMU DEV Initiate

    The workaround, of course, would be for me to write a plugin that hooks into the builder_head action at a higher priority than construct_builder_head and load the missing screen API, but I'd rather not have to maintain a separate plugin just to make these two place nice together.

  • Maniu
    • Developer

    Hey @webrn

    I will probably fix it in next release(need to do bit more testing) but generally get_current_screen() should be called in admin_init action to make sure it works correctly... you can modify this for now as it looks like your plugin is not updated anymore.

    Thanks,
    Maniu

  • Maniu
    • Developer

    Hey @webrn

    Actually, if you are ok with it - please comment out line 99 of email-newsletter-files\builder\class.builder.php file so this:
    add_action( 'builder_head', array( &$this, 'construct_builder_head' ) );
    looks like this:
    //add_action( 'builder_head', array( &$this, 'construct_builder_head' ) );

    And report if everything is working ok for you with this change, i still need to do bit of testing to see if this change is save and then i plan to implement it in next version but i also want to add bit more features so it will take a few days.

    Thanks,
    Maniu

  • webrn
    • WPMU DEV Initiate

    @Maniu

    I saw there was a new version out so I updated without doing the code change.

    Now if I go to create a new newsletter, I get the editor controls showing up in the left frame and the preview just being blank.

    If I change anything (so the newsletter saves and reloads) I get the "Cheatin’ uh?" message. Likewise if I open (edit) an existing newsletter I get this message right away without the editor controls loading at all.

    Perhaps we can get a more informative message than this? I'm assuming somehow I'm getting in a state that the original developer felt was impossible to get into, hence the cheeky message.

    I disabled the page security plugin, but haven't tried disabling any of my other ones.

  • webrn
    • WPMU DEV Initiate

    Actually, it seems that the disallow file edit WP-Config setting isn't the problem. I'm getting strange intermittent behaviour in my testing. I've been starting with all plugins disabled and then adding them back in, and refreshing the editor page to try to determine which is the problem.

    I'm now finding that I'm getting all my plugins activated and am able to edit things for a short time after activation, then I'm either getting a blank page for the editor preview or the Cheatin' Uh message.

  • webrn
    • WPMU DEV Initiate

    It seem that if I replace all instances of
    global $current_user with
    $current_user = wp_get_current_user();

    in class.builder.php, things start behaving better. I found on the live site, the user global wasn't being set, although on my development site using the same mix of plugins, it was. Since I was having somewhat intermittent problems before, maybe there is a race condition in there somewhere. Anyway, aside from that being a bit alarming, adding the get current user function call seems to fix my problem in the short term.

    If your tests dont indicate this change introducing any regressions, can it make it into the next version?

  • Maniu
    • Developer

    Hey @webrn

    Actually i increased priority for function that gets current users data for the next version but considering your suggestion i will even take it to the next level to decrease possibility of something like this happening.

    Thanks!
    Maniu

    PS. I will mark this topic as resolved, new version should be out soon!

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.