Forum Replies Created

Viewing 15 replies - 1 through 15 (of 36 total)
  • Thread Starter Steve McConnell

    (@mcstevem)

    Yes, at least it resolved the problem we were having.

    Thread Starter Steve McConnell

    (@mcstevem)

    This is what our developer did in the page template for the particular custom post type where we want to remove the Admin Bar:

    remove_all_filters ('show_admin_bar', 9223372036854775807);
    add_filter('show_admin_bar', '__return_false');

    The first line removes all filters being applied to the show_admin_bar hook. It needs to have that very large “priority” number, because Branda set their filter to that priority.

    Once that filter is gone, the second line removes the Admin Bar from that page.

    ~ Steve

    Thread Starter Steve McConnell

    (@mcstevem)

    That nailed it — Appearance tab is now gone again for Editors after plugin deactivation. Thanks for the speedy fix.

    Thanks, @renathoc. I had spotted and fixed that mixed-content error a couple of weeks ago in relation to a different problem. Regenerating thumbnails now is working properly again, so looks like that was the culprit there as well.

    I’m encountering the same error in multiple attempts with multiple images in both Firefox and Chrome (WP v5.5, Regenerate Thumbnails v3.1.3). FFox browser console showed no errors or warnings throughout the attempted regeneration process; here’s the Chrome console output:

    
    /wp-admin/tools.php?page=regenerate-thumbnails#/regenerate/20839:49 Mixed Content: The page at 'https://engineering.berkeley.edu/wp-admin/tools.php?page=regenerate-thumbnails#/regenerate/20839' was loaded over HTTPS, but requested an insecure stylesheet 'https://engineering.berkeley.edu/wp-content/plugins/publishpress-pro/vendor/alledia/wordpress-plugin-framework/src/assets/lib/font-awesome-v5.2.0/css/all.min.css?ver=0.6.8'. This request has been blocked; the content must be served over HTTPS.
    /wp-admin/tools.php?page=regenerate-thumbnails#/regenerate/20839:50 Mixed Content: The page at 'https://engineering.berkeley.edu/wp-admin/tools.php?page=regenerate-thumbnails#/regenerate/20839' was loaded over HTTPS, but requested an insecure stylesheet 'https://engineering.berkeley.edu/wp-content/plugins/publishpress-pro/vendor/alledia/wordpress-plugin-framework/src/assets/css/allex-grid.min.css?ver=0.6.8'. This request has been blocked; the content must be served over HTTPS.
    /wp-admin/tools.php?page=regenerate-thumbnails#/regenerate/20839:51 Mixed Content: The page at 'https://engineering.berkeley.edu/wp-admin/tools.php?page=regenerate-thumbnails#/regenerate/20839' was loaded over HTTPS, but requested an insecure stylesheet 'https://engineering.berkeley.edu/wp-content/plugins/publishpress-pro/vendor/alledia/wordpress-plugin-framework/src/assets/css/allex-admin.css?ver=0.6.8'. This request has been blocked; the content must be served over HTTPS.
    load-scripts.php?c=0&load[chunk_0]=hoverIntent,common,hoverintent-js,admin-bar,svg-painter,thickbox,jquery-ui-draggable,jquery-ui-button,jquery-ui-position,jquery-&load[chunk_1]=ui-dialog,wp-api-request&ver=5.5:4 Uncaught ReferenceError: wp is not defined
        at load-scripts.php?c=0&load[chunk_0]=hoverIntent,common,hoverintent-js,admin-bar,svg-painter,thickbox,jquery-ui-draggable,jquery-ui-button,jquery-ui-position,jquery-&load[chunk_1]=ui-dialog,wp-api-request&ver=5.5:4
        at load-scripts.php?c=0&load[chunk_0]=hoverIntent,common,hoverintent-js,admin-bar,svg-painter,thickbox,jquery-ui-draggable,jquery-ui-button,jquery-ui-position,jquery-&load[chunk_1]=ui-dialog,wp-api-request&ver=5.5:4
    (anonymous) @ load-scripts.php?c=0&load[chunk_0]=hoverIntent,common,hoverintent-js,admin-bar,svg-painter,thickbox,jquery-ui-draggable,jquery-ui-button,jquery-ui-position,jquery-&load[chunk_1]=ui-dialog,wp-api-request&ver=5.5:4
    (anonymous) @ load-scripts.php?c=0&load[chunk_0]=hoverIntent,common,hoverintent-js,admin-bar,svg-painter,thickbox,jquery-ui-draggable,jquery-ui-button,jquery-ui-position,jquery-&load[chunk_1]=ui-dialog,wp-api-request&ver=5.5:4
    build.js?ver=3.1.3:2 TypeError: wp.apiRequest is not a function
        at a.created (build.js?ver=3.1.3:2)
        at Ve (build.js?ver=3.1.3:2)
        at tn (build.js?ver=3.1.3:2)
        at a.e._init (build.js?ver=3.1.3:2)
        at new a (build.js?ver=3.1.3:2)
        at build.js?ver=3.1.3:2
        at init (build.js?ver=3.1.3:2)
        at n (build.js?ver=3.1.3:2)
        at build.js?ver=3.1.3:2
        at f (build.js?ver=3.1.3:2)
    We @ build.js?ver=3.1.3:2
    Je @ build.js?ver=3.1.3:2
    qe @ build.js?ver=3.1.3:2
    Ve @ build.js?ver=3.1.3:2
    tn @ build.js?ver=3.1.3:2
    e._init @ build.js?ver=3.1.3:2
    a @ build.js?ver=3.1.3:2
    (anonymous) @ build.js?ver=3.1.3:2
    init @ build.js?ver=3.1.3:2
    n @ build.js?ver=3.1.3:2
    (anonymous) @ build.js?ver=3.1.3:2
    f @ build.js?ver=3.1.3:2
    h @ build.js?ver=3.1.3:2
    f @ build.js?ver=3.1.3:2
    (anonymous) @ build.js?ver=3.1.3:2
    e._update @ build.js?ver=3.1.3:2
    r @ build.js?ver=3.1.3:2
    hn.get @ build.js?ver=3.1.3:2
    hn @ build.js?ver=3.1.3:2
    (anonymous) @ build.js?ver=3.1.3:2
    $n.$mount @ build.js?ver=3.1.3:2
    $n.$mount @ build.js?ver=3.1.3:2
    (anonymous) @ build.js?ver=3.1.3:2
    n @ build.js?ver=3.1.3:2
    (anonymous) @ build.js?ver=3.1.3:2
    (anonymous) @ build.js?ver=3.1.3:2
    quick-add.js?ver=3.3.4:1 Uncaught TypeError: t.dialog is not a function
        at HTMLDocument.<anonymous> (quick-add.js?ver=3.3.4:1)
        at i (load-scripts.php?c=0&load[chunk_0]=jquery,jquery-ui-core,utils&ver=5.5:2)
        at Object.fireWith [as resolveWith] (load-scripts.php?c=0&load[chunk_0]=jquery,jquery-ui-core,utils&ver=5.5:2)
        at Function.ready (load-scripts.php?c=0&load[chunk_0]=jquery,jquery-ui-core,utils&ver=5.5:2)
        at HTMLDocument.J (load-scripts.php?c=0&load[chunk_0]=jquery,jquery-ui-core,utils&ver=5.5:2)
    (anonymous) @ quick-add.js?ver=3.3.4:1
    i @ load-scripts.php?c=0&load[chunk_0]=jquery,jquery-ui-core,utils&ver=5.5:2
    fireWith @ load-scripts.php?c=0&load[chunk_0]=jquery,jquery-ui-core,utils&ver=5.5:2
    ready @ load-scripts.php?c=0&load[chunk_0]=jquery,jquery-ui-core,utils&ver=5.5:2
    J @ load-scripts.php?c=0&load[chunk_0]=jquery,jquery-ui-core,utils&ver=5.5:2
    tools.php?page=regenerate-thumbnails:1 Mixed Content: The page at 'https://engineering.berkeley.edu/wp-admin/tools.php?page=regenerate-thumbnails#/regenerate/20839' was loaded over HTTPS, but requested an insecure favicon 'https://engineering.berkeley.edu/wp-content/uploads/2020/02/cropped-En_Favicon_Gold-32x32.png'. This request has been blocked; the content must be served over HTTPS.
    tools.php?page=regenerate-thumbnails:1 Mixed Content: The page at 'https://engineering.berkeley.edu/wp-admin/tools.php?page=regenerate-thumbnails#/regenerate/20839' was loaded over HTTPS, but requested an insecure favicon 'https://engineering.berkeley.edu/wp-content/uploads/2020/02/cropped-En_Favicon_Gold-192x192.png'. This request has been blocked; the content must be served over HTTPS.
    
    • This reply was modified 4 years, 3 months ago by Yui.
    • This reply was modified 4 years, 3 months ago by Yui. Reason: please use CODE button for proper formatting

    I’ve tried extending the expiration time by adding that code to my site with the Code Snippets plugin, and by using the seemingly outdated Public Post Preview Configurator plugin. In both cases, a just-generated and successfully tested PPP link immediately expires as soon as I’ve activated either extension attempt, and then immediately functions properly again as soon as I deactivate the plugin being tested.

    Thread Starter Steve McConnell

    (@mcstevem)

    @stevejburge: I just tried that (twice), but keep receiving an Access Denied – Sucuri Website Firewall block warning of a cross-site scripting error. Is there some other way to get the info to you? You can email me direct at [email protected] if that will help.

    You could also refer the WP Engine support reps to the now-closed support request #812101 in their help system. And one of WPE’s last posts to that ticket said the plugin “can also be obtained from the MU-plugins directory via SFTP,” and that its content is as follows:

    $ cat x_disable_wpesec.php
    <?php
    
    add_action( 'widgets_init', 'wpe_remove_encourage_tls', 0 );
    function wpe_remove_encourage_tls() {
        remove_action( 'init', 'wpesec_encourage_tls' );
    }

    After going through six WPE support reps, I got confirmation that the problem was that “We recently pushed out some changes on our end to force all backend requests loaded over the WP Engine temporary URL to load over HTTPS,” which turns out to be incompatible with the current state of CAS Maestro. They provided us with a mu-plugin (x_disable_wpesec.php) that has solved the problem for existing sites, and that we’ll need to add to future clean installs (as opposed to copies from install templates that already include the fix).

    After much back and forth with WPE, they acknowledged today that “a slight platform change” at their end was implicated in the problem. They’ve made ” a tiny workaround” (details unspecified), which cleared up the problem for a new site that had been cloned from an older template site, but it still hasn’t solved the issue for a brand new, clean install.

    Thanks for the tip on wp-cassify, though with 100+ installs already using CAS Maestro, I’m hoping we can find a way to keep that plugin working for us.

    @dkirmis: We’ve just started running into the same port:80 error, but only on WP sites created since the beginning of 2017. We have many dozens of installs created in 2016 or earlier for which CAS Maestro continues to handle authentication properly. Bizarrely enough, if we clone one of those older sites, CAS authentication continues to work on the old site but fails on the new copy, even though the code ought to be identical. Our sites are all hosted by WP Engine, and we suspect there’s been some change there that’s causing the problem (though of course they point the finger of blame at the plugin). Are you hosted on WP Engine as well, or elsewhere?

    Is there a likely timetable for an update to solve this problem? We’re running into the issue in several spots on a new site, and are trying to decide whether to jump ship and try a different solution. Thanks.

    Checking back in belatedly to say that, after changing web hosts (to WP Engine) and cleaning up lots of bits and pieces as part of the migration, I am now able to successfully update wp-email to v2.60 without losing functionality as I did before.

    @lester: Production site (reverted to v2.52) is newscenter.berkeley.edu.

    Same story hereas well, though the error I consistently get after filling in the form and clicking Mail It! is “Failed To Verify Referrer

    Reverting back to 2.52 puts me back in business without any other changes.

Viewing 15 replies - 1 through 15 (of 36 total)