Support » Plugin: Akismet Anti-Spam » akismet blocking initial admin experience

  • Resolved diablodale


    On an initial install of wordpress
    with an initial install of Akismet
    on the first time to /wp-admin/
    Akismet blocks the initial WP admin experience and instead supersedes it with an Akismet-only experience.
    Naturally, no plugin should block the first-time experiences, and not consume the entire right pane.

    Ubuntu 18.04
    WP 5.2.4
    Akismet 4.1.3

    Repo as I wrote above:
    1. Install WP
    2. Install Akismet (via wp-cli, multiset, plugin directory, etc.)
    3. visit http://myserver/wp-admin/
    4. login

    The entire right pane is consumed by Akismet

    Akismet to not consume the entire right pane. On the first-time admin experience, the most important thing is WP itself (not a plugin).

    This was found in CI/CD pipeline testing. The initial admin experience was no longer WP because Akismet is overriding. Broke testing.

    • This topic was modified 2 months, 2 weeks ago by .
Viewing 11 replies - 1 through 11 (of 11 total)
    • This reply was modified 2 months, 2 weeks ago by .
    Plugin Author Christopher Finke


    Can you post a screenshot of what you’re seeing? I just followed your steps, and this is what /wp-admin/ looks like to me on the first load for a brand-new WP install with Akismet activated:

    Sure. In the repo, there are no hits to any URL on the webserver unless I describe.
    I use docker/compose to destroy/create fresh every time. I’m currently developing at home and the pipeline creates a self-signed cert for TLS on the apache2 server in a container.

    I open a blank tab in chrome. Type in the servername/wp-admin/ then…

    redirects to
    I turn on chrome developer tools (disabled cache, preserve log).
    I fill out form with username and password, click to submit
    The html posts to /wp-login.php
    immediate 302 redirect to…
    immediate 302 redirect to…

    Here is redacted screenshot

    And the raw response header that did the immediate 302 redirect to akismet:

    HTTP/1.1 302 Found
    Date: Wed, 06 Nov 2019 21:18:46 GMT
    Server: Apache/2.4.38
    Strict-Transport-Security: max-age=63072000
    Expires: Wed, 11 Jan 1984 05:00:00 GMT
    Cache-Control: no-transform, no-cache, no-store, must-revalidate
    X-Frame-Options: SAMEORIGIN
    Location: https://home-nas/wp-admin/options-general.php?page=akismet-key-config&view=start
    Referrer-Policy: strict-origin-when-cross-origin
    Set-Cookie: wp-settings-1=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; secure
    Set-Cookie: wp-settings-time-1=1573075129; expires=Thu, 05-Nov-2020 21:18:49 GMT; Max-Age=31536000; path=/; secure
    Keep-Alive: timeout=5, max=99
    Connection: Keep-Alive
    Transfer-Encoding: chunked
    Content-Type: text/html; charset=UTF-8

    • This reply was modified 2 months, 2 weeks ago by .

    Hi there,

    As you realized above, it’s not Akismet taking over the screen, but a one-time redirect as the result of your having installed and activated Akismet via wpcli.

    That redirect on plugin activation is meant to make it easier for people to get setup with their API key once they activate Akismet (since the plugin does nothing until it has that key setup), and only happens once. Normally, one couldn’t activate the plugin without having first visited wp-admin, but the wpcli workflow bypasses that indeed.

    In your very case, though, I’m wondering why you install the plugin in step 2 of your workflow, since Akismet is bundled with WP. It sounds like you could do without step 2 altogether (which would then mean it’s not activated via wpcli, and get you out of that conundrum).

    We follow the approach of using containers with a known and fixed set of files; the file systems of the container are read-only when running (with a small set of specific tmpfs mounts). During build stage of the containers, specific versions of everything are included; specific WP, specific akismet, specific Woocommerce, etc. This facilitates a tested known infrastructure which can be deployed as a single unit; rolled forward as a unit, rolled back as a unit.
    These containers can be connected to an empty db for a new WP install. Other times it is an existing WP db. On container spinup, we configure/migrate using wp-cli (e.g. de/activating plugins, settings, database work, etc.). Then launch apache2 as PID=1 in the foreground ready for traffic.
    I’m confident you know there are UI mechanisms to call attention to config needs using non-dismissible card notices that appear on the top of the screen; they leave the main content unaltered under it. Your peers at Automattic like WooCommerce use such an approach with a card that writes “Welcome to WooCommerce – Youβ€˜re almost ready to start selling :)” with a “Run the setup wizard” action button.
    Curious…your redirect is blocking this Woo setup card of your own peer. Unintended sibling fighting. πŸ₯Š In my screenshot MonsterInsights uses the card approach…they were able to somehow still appear. I smell a race condition 🏎

    I’ve reproduced a related behavior with this page-takeover of akismet. I saw it yesterday but couldn’t reproduce it. I just now did.

    Same software everywhere, just a new instance of the same.
    Open chrome browser
    visit WPsite/wp-admin/
    enter user, password
    forever 302 redirect loop by akismet (see screenshot)
    chrome halts forever loop


    Naturally, I cleared cookies. No affect, forever 302 loop still occurs.
    Since this is a change in behavior yet no software change, this lends a bit more evidence that the method akismet is using the force this UI is part of a race condition and some tiny difference has occurred in this instance which is exposing this forever loop bug.

    So there are two related issues:
    1) the takeover UI is intrusive and kills the OOBE/first-run WP experience
    2) there is likely a race condition with this takeover that sometimes it kills peers like Woocommerce, and other times it gets into a forever 302 loop with itself.

    • This reply was modified 2 months, 2 weeks ago by .

    Hi again,

    Since your case is so completely out of the norm, it’s fairly possible we’re not going to change the plugin code for it (though I’m still looking into a painless way to).

    On the other hand, one extremely simple thing you could add to your workflow is to delete the Activated_Akismet option, which would stop that redirect from happening altogether.

    delete_option( 'Activated_Akismet' );

    You can achieve that by leveraging the following wpcli command:

    I’ll update this thread if we find a way to accommodate your special requirements in the plugin itself, but the above should get you out of that issue pretty easily.

    Note that you’ll have to delete the option after activating Akismet, and before loading wp-admin.

    Hi again,

    So, here’s what I just committed to Akismet’s trunk (dev version):

    That should ensure we only do the redirect dance if the plugin was manually activated from within wp-admin, as we intended all along.

    That’ll stop the redirect from happening in your case, since $_SERVER['SCRIPT_NAME'] is set to /usr/local/bin/wp (or similar) when wpcli is running.

    That’ll be available in the stable version of Akismet when we release the next version (no ETA at this point), but is immediately available to you if you use trunk instead.

    Confirm deleting the ‘Activated_Akismet’ wp option prevents the UI takeover.

    I appreciate the code refinement also. After it moves into a release, I will be able to verify if it works as intended.

    These two possibilities facilitate pipelines for building known infrastructure/containers, automated testing of them, and deployment. πŸ™‚

    Always happy to help.


Viewing 11 replies - 1 through 11 (of 11 total)
  • You must be logged in to reply to this topic.