Fear not, salvation is at hand! Although many Web 2.0 sites providing text-editing will save drafts and provide a reasonable text editor, nothing beats your favourite text editor of all time, Vim. Or Emacs. Or whatever you would prefer to use. Why shouldn’t you be able to use any text editor you like? It’s your computer and your time after all!

If you are using Firefox, your problems are over. Introducing It’s All Text. Install this handy plug-in to your Firefox, set the default editor to your liking and you are off and running! Now any text box on any webpage will show a small edit button on the bottom right corner allowing you to launch the editor of your choice. Edit to your heart’s content using the tools you are most familiar with, then save and exit the editor and have all your work sent back to the browser text box.

Even if the browser crashes mid-edit, your editor program will be unaffected and your work will be safe. You can save your work in the editor in addition to any swap or draft files it creates for even more safeguards.

It’sAllText works in Firefox 3.0. If you have older versions of Firefox you may wish to check out MozEX which is a similar plug-in.

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.

http://support.microsoft.com/?kbid=309173

http://cow.neondragon.net/index.php/72-Searching-Php-Files-With-Windows-Search

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.