Blobfolio

Apocalypse Meow hasn’t been specifically tested with WPS Hide Login, but it should work as long as WPS doesn’t interfere with the login “hooks” that are normally triggered.

But if you do find yourself suddenly unable to login, simply delete the plugins/apocalypse-meow folder via FTP, and you should be good as new.

I was able to reduce the memory footprint a little bit in 15.09-4, particularly in cases where a lot of files have permissions other than the defined target.

Does this fix things for you?

If not, can you please deactivate and uninstall the plugin (through the WP plugins interface, which will remove the settings in addition to the files), then try installing a fresh copy?

After a reinstall, go to the scan settings, and enter “0” for the File Permissions (if you see the option), check “Skip Cache” (if you see the option), uncheck “Analyze Content”, and save. This combination is lightest on the server, so let’s start with that!

Then try a “Core Scan Only”. Did that work?

Then try a regular scan. Did that work?

I went ahead and released 15.09-3, which contains the performance improvements I mentioned regarding the building of the obsolete core file database. Can you give the new version a shot? If your server was struggling to build the list before, it should be good now.

If the scan results still aren’t working, though, please let me know if you’re getting any Javascript errors or if there is anything pertinent in your server logs.

Thanks for taking the time to help debug the plugin!

Do you remember, were you previously running 15.09 or 15.08?

The only change from 15.09 to 15.09-2 was a bit of JavaScript. Can you tell me if there are any JavaScript errors when running a scan? You can press Command + Option + J (Mac) or Control + Shift + J (Windows/Linux) to pull up the js console in your browser.

From 15.08 to 15.09, there were a lot more changes. The two things I can think of that might hold up the results are the new file permission scanning or the building of the list of old core files (which can take a lot of time). I’m working on a way to make the latter more efficient in the next release, but in the meantime it will at least cache each old version as it is fetched, so if the results time out, you might be able to reload the page to have it work through the rest.

Do you have any errors in the server log?

Actually, I know roughly where the problem is, just not what the problem is. Would you please give version 15.09-2 a shot? Instead of the “undefined” progress message, it should tell you that the server response was bad and give you a link to try and reset it.

That link may or may not help you if the server response keeps being bad. ??

In the event bad data is received, the scanner will also print some debug information to the Javascript console. In most browsers, you can view the console by clicking Command + Option + J (Mac) or Control + Shift + J (Windows/Linux). Would you please do that on the scan page if you are still getting an error, and paste the response here? The relevant line will begin “Look-See Response”.

Hey Clive,

Sorry for the very tardy response! My WordPress notifications got disabled somehow, so I missed your post.

The last release, 0.9.0, has a new max length feature, which should help. If a human being can’t say what they want in under a couple thousand characters, there is something wrong. ??

Look-See 15.09 now has a basic file permission checker capability. You tell it your target value, and it will let you know if any files have different access.

I’m not sure how well this particular feature will work across different environments, so please let me know if you run into any issues.

Hey Brad,

I’m sorry for not getting back to you sooner; I didn’t get a notification of your post.

Can you let me know more about the type of environment you’re running the plugin on? I’d be interested in things like:

• The operating system
• MySQL version, database engine, charset
• PHP version and interpreter (e.g. mod_php, hhvm, fpm, etc.)
• Did the Looksee database table get created? Are there file paths listed there?
• Is the experience the same when using a different web browser (or even a Private/Incognito session of the same browser)?
• Do you see an Abort button under the “undefined” scan progress? Does clicking that do anything?

Thanks itiab!

I love the idea about storing file permissions! I think I’ll build that into our Look-See plugin.

Do you think it is worth asking the user for their desired baseline permissions, or just assume a typical 644/755?

That’s a great idea about the version numbers. I’ll include that in the next release. ??

To be honest, I’m still on the fence about this feature. On some test environments, the number of (false positive) results returned was so large as to render the whole search meaningless.

The speed and memory issues are still a concern as well. I ended up limiting scans to non-core PHP files, which helps, but also means the scan will miss code hidden in arbitrarily named files.

But maybe it will be helpful. I released an updated version, 15.08, with the additional test. It is optional and disabled by default, so hopefully it won’t adversely affect anyone.

Thanks for your feedback.

Thank you for the suggestion!

Unfortunately, tests like these are quite expensive to run. I actually benchmarked some similar operations a while back and found that it takes about 100x longer to analyze the content of a text file than it does to generate its MD5 checksum. The memory requirements are also quite a bit higher.

Most instances of Look-see are installed on horrifically slow shared servers, barely capable of running the scan as-is. I don’t want to add features that would make the scan even slower without a compelling reason to do so. ?? Searching for base64-encoded content or blacklisted functions would likely trigger a boatload of warnings, virtually all of which would be false positives. I don’t think such a feature is quite helpful enough for inclusion here.

Such is my answer for PHP, anyway.

If you have command line access to your server, you can run this sort of operation much more efficiently with a simple Bash command:

grep -E -r "\b(exec|shell_exec|eval|base64_decode|passthru|unserialize|pcntl_alarm|pcntl_fork|pcntl_waitpid|pcntl_wait|pcntl_wifexited|pcntl_wifstopped|pcntl_wifsignaled|pcntl_wexitstatus|pcntl_wtermsig|pcntl_wstopsig|pcntl_signal|pcntl_signal_dispatch|pcntl_get_last_error|pcntl_strerror|pcntl_sigprocmask|pcntl_sigwaitinfo|pcntl_sigtimedwait|pcntl_exec|pcntl_getpriority|pcntl_setpriority)\s?\(" --include "*.php" /path/to/wp-content/

Hi there,

Some sites require more than the basic sitemap functionality offered by this plugin. This warning should only be displayed when Yoast’s sitemap functionality has been enabled by the site administrator (via the Check this box to enable XML sitemap functionality toggle). Otherwise it just confuses people.

Thanks!

Woo! If only all bug fixes could go so smoothly!

Thanks again for taking the time to open the issue.

Hi Mark,

Thanks for opening the bug report!

Would you please give the latest version (2.0.1) a shot and let me know if that helps?

I suspect in your case another plugin or theme might have been manipulating the raw form value (of the username) before Apocalypse Meow could get its hands on it. Now, the plugin uses the lightly-processed version of the username passed to it by WordPress. I’m hoping this approach will be more consistently available. ??