We’ve discovered some interesting things about Windows, and they never fail to cause some head-scratching. We had cause to go rooting through a customer’s wordpress installation recently to hunt down the cause of PHP errors, and discovered two WTFs here.
The first was the breakage of various scripts in the wp-admin directory. Through means unknown, every array definition was broken by the addition of a file path. If you grok PHP, you’ll recognise that this isn’t syntactically valid:
$defaults = array('show_option_all'../../../wordpress/wp-includes/ => '', 'show_option_none'../../../wordpress/wp-includes/ => '');
Python is our preferred in-house language, but breadth of knowledge is more important for a sysadmin. Cleaning up the PHP was a snap, but it’s a mystery as to how this happened in the first place; according to the customer it “just stopped working”. It looks a bit like someone got busy with a site-wide find-and-replace. This isn’t implausible, but it seems far less likely given that this is on a Windows machine.
Speaking of find and replace, just the finding dodgy strings proved to be more difficult than expected. Given that it was one customer’s site that was affected, it should be easy to search for all occurrences of ../../../wordpress/wp-includes/ and be done with it.
Certainly under linux you’d use grep, put it in recursive mode and ask it to list the relevant files.
grep -r -l '../../../wordpress/wp-includes/' /path/to/customers/site
Under Windows you’d use the usual file-search tool. Leave the filename field blank so we don’t limit it, then put the search string in the box below. Just to be really sure, we’ll open the Advanced Options and select “All Files and Folders”. Root the search at the customer’s site and fire it up, this is exactly what we need. Except that Windows won’t find the string in your PHP files.
As you may have guessed, this is when “all files” doesn’t actually mean all files. It even seems this is a known issue, and there’s a “fix” noted by someone else. The long and the short of it is that PHP files aren’t “recognised” by Windows, so it won’t try to search them; the latter page describes what you have to do to work around it.
In fairness, there’s a certain amount of logic to it. You probably don’t want to be searching for text in binary files like DLLs or video clips. That said, it badly breaks the expected behaviour of the search tool. If you’re searching for text in all files, it should (to our mind) be understood that you’re literally searching in every file.