Stephane Daury (stephdau)
Forum Replies Created
-
Forum: Plugins
In reply to: [Akismet Anti-spam: Spam Protection] Buddypress activity and AkismetHi there.
First, let me apologize: I got sidetracked at the time, and this issue escaped me… Sorry about that.
This said, the changes I’ve made in https://plugins.trac.wordpress.org/changeset/2247472 will already alleviate the displaying of the errors/warnings.
The core reason is that you most likely have empty values in
wp_commentmetarecords that hold theakismet_historydata.We’ve identified that the WP Importer plugin (at least) might be having issues with that. Have you imported some of the data, by any chance? If not, it could be for similar reasons. We’re digging into it more.
- This reply was modified 6 years, 2 months ago by Stephane Daury (stephdau).
- This reply was modified 6 years, 2 months ago by Stephane Daury (stephdau).
Forum: Plugins
In reply to: [Akismet Anti-spam: Spam Protection] Buddypress activity and AkismetHi there,
I’m able to reproduce this in my BuddyPress test instance, but nothing has changed on the AKismet plugin side to lead to the issue. I’m looking into why BP is suddenly passing data in a format that’s no longer compatible.
- This reply was modified 6 years, 5 months ago by Stephane Daury (stephdau).
- This reply was modified 6 years, 5 months ago by Stephane Daury (stephdau).
Always happy to help.
Cheers!
Hi again,
So, here’s what I just committed to Akismet’s trunk (dev version): https://plugins.trac.wordpress.org/changeset/2187875
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
trunkinstead.- This reply was modified 6 years, 6 months ago by Stephane Daury (stephdau).
Note that you’ll have to delete the option after activating Akismet, and before loading wp-admin.
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_Akismetoption, which would stop that redirect from happening altogether.delete_option( 'Activated_Akismet' );You can achieve that by leveraging the following wpcli command: https://developer.wordpress.org/cli/commands/option/delete/
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.
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).
- This reply was modified 6 years, 6 months ago by Stephane Daury (stephdau).
Hi there,
Could you please reach out to us at https://akismet.com/contact/, so we can figure out what might be the issue together? We’ll likely have to ask you to share some admin level info that’s probably better shared in private.
Thanks.
@josiah-s-carberry : can you contact us via https://akismet.com/contact/, with your API key, site, etc. It’ll probably be better to talk about those details in private (what your site runs, etc). Thanks.
Hi there.
Hmmmm. My first thought was that that doesn’t sound like something Akismet would be involved in in any way, but your tests definitely seem to be pointing at the fact that it is. Let me address it with my fellow Akismet developers, and we’ll get back to you ASAP.
Forum: Plugins
In reply to: [Akismet Anti-spam: Spam Protection] Spam Attack@amreshkramar: it’s my pleasure. Glad to hear that you found a solution. Such attacks are definitely not fun. Good luck! 🙂
Forum: Plugins
In reply to: [Akismet Anti-spam: Spam Protection] Spam AttackHi there,
An increase in spam should not be leading to your error log files growing in size the way you describe. Have you inspected the content of said log files to see what the entries are?
We’ll be happy to look into the spam situation on your site, in case it is indeed related, but we’ll need you to contact us via https://akismet.com/contact/, with your API key, site details, etc, so we can do so effectively.
Forum: Plugins
In reply to: [Akismet Anti-spam: Spam Protection] Bug in 4.1.2 version?Hi there,
We’re going to need more information to be able to help you effectively, like what your site is, etc.
Can you please contact us at https://akismet.com/contact/, leaving as many details as you can, and we’ll be happy to look into it.
Stephane –– Akismet Developer
Forum: Plugins
In reply to: [Akismet Anti-spam: Spam Protection] “Silently Discard” … working!Thanks for having taken the time to write this, it made my day. 🙂
Hi there,
Unless I missed something in your report, I think there might be a misunderstanding as to what that CSS does, and how it might affect a user.
The
content: attr(href);parameter does not display the content of the site being linked to, it simply displays the URL that is being linked to, next to said link, as seen in https://cloudup.com/itp4rG2hcDy.The content that is shown as an overlay (like the 404 in https://cloudup.com/iWc_lALmpzA) is a screenshot/image that is being automatically generated on our servers, but the user’s browser (or server) never actually gets to the target site.
Based on the above, I cannot see a security vector for an attacker to take advantage of either, from a user’s perspective.