Blobfolio

Yup! The Look-See database is always updated within 24 hours of a new WordPress release. (3.8.2 was officially announced a couple hours ago.) Look-see 14.04 has been pushed to the plugin archives, so you should be able to update your installation in the next few minutes or so. Thanks.

Sure, I’d love to take a look at what you’ve done! Please e-mail a zip of the modified plugin (or a diff file) to the e-mail address listed near the top of index.php. Thanks!

Here is the corresponding PHP error, which is what is derailing the AJAX request to build the media library:

PHP message: PHP Warning: Missing argument 2 for AjaxThumbnailRebuild::addRebuildSingle() in /xxx/httpdocs/wp-content/plugins/ajax-thumbnail-rebuild/ajax-thumbnail-rebuild.php on line 45

But so far I’ve only noticed this happening on a single site; others with similar configurations are working just fine. The issue must be rather specific. ?? For reference, the site is on a Debian Wheezy server with the following:

• SSL forced for wp-admin;
• php5-fpm (5.4.4-14+deb7u8)
• nginx (1.2.1-2.2+wheezy2)
• mariadb (5.5.36+maria-1~wheezy)
• WP (3.8.1)

I’ll let you know if I come across any other site with this issue, and maybe find a common thread.

Hi there,

Just to make sure I understand you correctly: on your web site, people can log-in using their e-mail address instead of a username? And you would like to modify Apocalypse Meow so that it records the e-mail address used to log-in with?

If so, there are two places you will need to change, both of which are located in “index.php” on lines 892 and 904. For reference, they look like:
return meow_login_log(0, trim(strtolower(stripslashes_deep($_REQUEST["log"]))));

The second argument ($_REQUEST[“log”]) is the normal username variable and is what is sent to the logging function. What you will need to do is change that to the variable containing the e-mail address, or better still, do a test to see which was used (e-mail or username) and send the correct entry.

I hope this helps!

Hi Clive,

An updated version of the plugin (0.8.0) is now available. It contains a new excessive link test, which rejects comments containing more than five links. Thanks again for the suggestion!

For the time being, there are no plans to incorporate any sort of language detection or word/phrase blacklist features. Sock’Em SPAMbots is meant to function as a drop-in, first-pass SPAM control system. The focus is on conservative, generalized tests that can be combined to block the first 98-99% of SPAM, while strictly minimizing the potential for false positives (catching humans by mistake) or the need for administrative intervention. Language detection and word/phrase blacklists are excellent features, but ones which require a level of specificity and fine-tuning more appropriate for plugins providing second-pass screening.

Hi Clive,

Thanks for the feedback!

I like the idea of limiting the number of links per post. The feature wasn’t included originally because it is part of the widely-used Akismet plugin (no sense in duplicating features), however I see your point: it is annoying to have a ton of super-spammy-linky posts sitting in the moderation queue!

I’ll add a link-limit field in the next release!

Yay! Thanks again for raising the issue and helping to improve this plugin!

(I’m closing this issue since there has been no follow-up for a month. If you do want to help debug this plugin, though, please feel free to reply with error log information and I’d be happy to investigate further.)

I just pushed through an updated version, 13.11. If MySQL was the source of your bottleneck, this update should resolve it; the scan status updates are now grouped into a single query, resulting in 2x performance on my test machine. There is also now an option to skip cache files (which are kinda pointless to scan), which can further speed things up.

I also updated the SSL analysis. Thanks for your suggestion on that.

That is strange. I too have always found Linux to be much faster than Windows, except on really bad shared hosts (of which there are too many, haha).

To help narrow it down further:
When a scan is first started, there is a pre-scan of sorts, where the plugin crawls the directories and compiles a list of files to later scan. This pre-scan is completed once you first see the progress bar. Is this portion slow on the Linux server too, or does it complete in a comparable time (shouldn’t be more than a second or two) to the Windows version?

The scan itself is pretty simple:

1. An AJAX query is submitted to WP.
2. Look-See queries the database for up to 250 file paths to scan. This uses the WP database wrappers, and so shouldn’t itself be a point of slowness if WP queries are normally speedy.
3. For each file, it first checks to see if it exists (if not, the db is updated to note this);
4. Assuming the file exists, it then checks the file size to see if it is larger than the allowed limit (if larger, the db is updated to note this).
5. If the file exists and is within the allowed size range, it computes an MD5 checksum of the file and saves this value to the db.
6. Once every file is checked, it returns a couple totals, and if there are more files to check, the process is repeated.

From the above, there are three good candidates for slowness:

A) Checking the file size has a performance penalty, but usually this is greatly outweighed by the savings of not MD5ing massive files.

B) MD5 computations take a bit of time to perform. Less than stronger checksums, but more than something like CRC32. Overall it seemed the sanest choice of checksum algorithms.

C) 250 separate update queries, though small in size (we aren’t transmitting Moby Dick…), might still be more than MySQL wants to be bombarded with. A future version of the program will allow this value to be easily toggled, but if you wanted to quickly change it yourself, it is set at the top of the plugin’s index.php file: define('LOOKSEE_SCAN_INTERVAL', 250); A smaller size will result in more AJAX queries to the server, but lighter loads per query.

Thanks a bunch of helping me debug/improve the plugin!

Thank you for clarifying. I see your point! I’ll update the program so it doesn’t worry about FORCE_SSL_LOGIN if FORCE_SSL_ADMIN is enabled. ??

That’s interesting, thank you for sharing!

I assume your two set ups contain different user content (uploads and such)? A good way to quickly get a head-to-head comparison would be to do core-only scans on each system; that way it will scan the same files on each system.

If the core-only scan performance is more or less the same for both, then the performance issue comes down to user content. Setting a reasonable upper file size limit should address this (try setting a limit of 1MB; most scripts will be much less than this). This way the scanner will not struggle generating a checksum on large images or video or whatever.

If the core-only scans are still completing at very different rates, then there must be something unfortunate in the Linux set up. You might need to adjust the memory and cache settings in PHP, MySQL, and/or Apache (or NginX or whatever server software you’re using). Benchmarking and monitoring software might help you locate areas of strength and weakness in the set up.

Hi ec5774,

Look-See actually checks for both FORCE_SSL_ADMIN and FORCE_SSL_LOGIN, and issues the general warning if either is missing. It is, of course, up to you whether or not you want to follow up any of its recommendations, but I’ve found that FORCE_SSL_LOGIN happens to foil the majority of brute-force login scripts, as they don’t bother to follow the redirect to HTTPS.

Thank you for the suggestion! We’ll consider doing so in a future release.

Sock’Em SPAMbots is now out of BETA. Woo! But of course, if you see any issues, please let us know!