By default, WebSVN does not display line numbers when looking at the contents of a single file (i.e. URL’s containing filedetails.php). Fortunately, this is easily corrected if you enable Geshi syntax highlighting. It’s enabled by default, but double-check the contents of include/config.php, making sure that the line $config->useGeshi(); is present and not commented out.

With that done, open include/svnlook.php and go to line 806, which looks like this:

$this->geshi->set_tab_width($this->repConfig->getExpandTabsBy());

Create a new line and insert the following immediately after it:

$this->geshi->enable_line_numbers(GESHI_NORMAL_LINE_NUMBERS);

Save your changes and reload the file detail view, and Geshi should now display line numbers along the left-hand margin. With this simple change, I use WebSVN to effectively conduct group code reviews.

Note that WebSVN can still choose not to use Geshi if there’s no support for the language in question, in which case there won’t be any line numbers.

Print, hang outside your office or cubicle. Your goblin-slaying co-workers will thank you.

It assumes you will place each set of SSL files under a directory assigned per domain; at the end you will have a directory that contains the newly created .host, .key, .pem and .info files.

mkdir /etc/ssl/subdomain.domain.com

cd /etc/ssl/subdomain.domain.com

openssl genrsa 2048 > host.key

openssl req -new -x509 -nodes -sha1 -days 3650 -key host.key > host.cert

# Enter subdomain.domain.com for Common Name. It's the 6th option in the dialog.
# All other options can be left blank for defaults
# For wildcard SSL, enter *.domain.com

openssl x509 -noout -fingerprint -text < host.cert > host.info

cat host.cert host.key > host.pem

chmod 400 host.key host.pem

A signed SSL certificate is necessary for all your public-facing domains. But you can save yourself a lot of time and money by using self-signed certificates on sites that have a limited or more technical audience. For example, I use self-signed certificates for all the installations of phpMyAdmin that I set up.

The protection you get from a self-signed certificate is exactly the same as one you pay for; the browser warning that pops up is the only difference. Click through it and you’re good to go.

The list of prefixes, which most people started using with the term “kilobyte,” are collectively called the SI Prefixes. SI prefixes are defined under the International System of Units (“SI” for short), which is maintained by the International Bureau of Weights and Measures.

But there’s a problem; currently the list has 5 more prefixes past giga: tera, peta, exa, zetta, and yotta. Translation: we’re out of prefixes in just a few more generations, probably faster if Moore’s Law has anything to say about it. Indeed, you may have noticed how much quicker the public dialog went from megabyte to gigabyte than it did to make the same transition from kilobyte to megabyte. What to do?

One answer is to draw from existing lists of unofficial prefixes, currently used mostly by theoretical mathematicians. But given the speed at which we are advancing, it is safe to assume that we’re going to speed through individual prefixes quickly, resulting in more terminology overlap in common vernacular. For example, data centers are already discussing their capacity in the petabyte and exabyte range, and we haven’t even seen those hit mainstream yet.

Therefore I posit that it’s worth considering using a system that has inherent ordering, i.e. an existing list that we can repurpose. This speeds adoption, eliminates confusion, and solidifies the naming convention for a much longer period with minimal effort.

Looking at the problem in this light, I quickly identified the Greek Alphabet as very viable candidate:

• Current SI prefixes match mnemonically with Greek letters (you can hear the similarity between “gigabyte” and “thetabyte”).
• The list is universal, eliminating the need to debate on future prefix selection and ordering. Anyone who’s suffered “death by committee” knows what I’m talking about.
• It can instantly extend the SI prefix list another 24 levels.
• The Greeks themselves attached numerical values to each letter.
• There is some precedent: The National Weather Service names tropical storms after Greek letters once the A-Z naming list is exhausted.

Best of all, the doomsayers of the future might point to the Omegabyte as a sign of the end times. I think I know what the Mayan’s were thinking:

Additional reading and sources:

• Wikipedia: SI prefix list
• Wikipedia: Greek Alphabet
• Wikipedia: Non-SI unit prefixes
• NOAA Worldwide Tropical Cyclone Names

Head over hackertyper.com and just start pushing buttons.

As long as you avoid mashing your palms against the keyboard, your non-techie friends will look at you like this.

Equal parts hilarious and badass!

(Apologies for the gif format, the NFL gestapo makes it hard to find real video clips.)

Fatal error: Allowed memory size of 33554432 bytes exhausted 
(tried to allocate XX bytes) in /some/file on line XX

This is a general PHP error, but the exact amount (33554432 bytes) occurs very frequently on WordPress sites. Here’s what’s happening, and how to fix it.

Every installation of PHP has an ini value called memory_limit, which hardcaps how much memory PHP may use on any given request. There are other ini settings that dictate the memory usage for specific actions, like post_max_size, but this one is universally applied; you can’t load anymore than what this value dictates.

I do a lot of stuff with files in PHP, so I blow this value out from it’s default of 128 MB up to 2 GB. I set this globally in my php.ini file like so:

memory_limit = 2G

I could also set this value from inside an .htaccess file:

php_value memory_limit 2G

Since this value was set before the site even loads, imagine my surprise when PHP is telling me that the limit is now 33554432 bytes, or 32 MB. The limit was changed by a define in WordPress called WP_MEMORY_LIMIT.

Here’s where things go awry. WordPress tries to check the existing memory_limit before applying it’s own terms, however the value must be set in terms of MB. Look back at my example settings; the PHP memory shorthand allows me to set in gigabytes using a “G“. But WordPress does a straight integer comparison to figure out if the existing setting is more/less than 32 MB. Here’s the offending code, a portion of an if statement on line 42 in wp-includes/default-constants.php

( (int) @ini_get('memory_limit') < abs(intval(WP_MEMORY_LIMIT)) ) )

What you end with in that sample is essentially if (2 < 32), which resolves true and thus WordPress applies it's own default limits.

You have three options to rectify the situation: two easy fixes, plus one badass "server-baller" fix. First the easy ones. As WordPress outlines in the article on increasing memory, simply define WP_MEMORY_LIMIT in wp-config.php using MB syntax. If I wanted to set it to 2 GB, it would look like this:

define('WP_MEMORY_LIMIT', '2048M');

Your value will be honored as long as it is an integer value greater than 32, but could break if WordPress changes it's memory size comparison calculation.

Alternatively, I could change my the memory_limit setting directly in php.ini or .htaccess to use MB syntax:

memory_limit = 2048M

[.htaccess]
php_value memory_limit 2048M

Realistically I would probably edit php.ini. Well, that is, I would, if I didn't know about the badass server-baller third option, which overrides php.ini AND prevents WordPress (or any other site for that matter) from making any changes to the value.

Look back at my .htaccess setting, and notice that I set the value using the command php_value. PHP has a similar command called php_admin_value, which you can use for setting all the same stuff as php_value.

The difference: php_admin_value can only be set within Apache configurations, i.e. it cannot be used inside of .htaccess files. Furthermore, any value set using php_admin_value cannot be overridden by any later calls to php_value or ini_set. You can override php.ini defaults, and lock that value in for the remainder of the request.

So back to our WordPress example, I opened the VirtualHost for frankkoehl.com and entered this line:

php_admin_value memory_limit 2G

Now the site will always allow a memory limit of 2 GB, no matter what. WordPress can try and set whatever value it likes, it will never be recognized.

Note that this function requires that you have access to Apache configurations, at least the ones running your site. Most shared hosting packages won't offer this level of access.

It's worth mentioning that WordPress sets a default value of 32 MB, lower than PHP's own default of 128 MB. I disagree that such a low limit is necessary, but they are trying to be good stewards to servers everywhere, so I can see where they're coming from.

I still have no idea why this memory issue popped up in the first place, but it gave me an excuse to share a cool configuration option that has saved me from having to scour code on several bloated, crappy sites to find obscure ini settings. I have a recent real-world example you can read about on Stack Overflow.

(Sidebar: they can plead ignorance all they want, I’m certain the MS overlords are using every back-alley approach they can find to break the Google stranglehold.)

The toolbar was easy enough to remove, find it in the addons and push the “Remove” button. Changing my keyword search engine back proved a little more difficult.

A little background: the keyword search engine is the site that comes up when you type a word or phrase (not a URL) into the address bar (not the search bar). For example, if you open Firefox, enter “hot koehl”, and click go, you’ll likely end up on a Google search results page. I disable the search box entirely and use this method for almost all my searching. Very handy.

These asshats modified the Firefox configuration to send me to Bing without any warning or consent. To change it back, open a new tab and type about:config in the address bar. Enter the phrase keyword.url in the search bar that appears near the top.

The default is Google, so we can simply reset it by right-clicking the line and choosing the “Reset” option. Restart your browser and you should be good to go.

This type of adware typically modifies the search bar as well, so you should have a look at the config settings for browser.search while you’re at it. Config entries appear in bold if they’ve been modified from the default value.

Further reading on Firefox’s keyword functionality found over at mozillaZine.

However, by default Apache rewrites will escape the hash (#) symbol, converting to its hexcode equivalent %23.

So this rewrite…

RewriteRule ^/foobar/?$ /some/other/url#foobar/ [R=301,L]

will produce this URL…

http://example.com/some/other/url%23foobar

In order to make this rewrite work, we must prevent Apache from escaping the hash mark by using the noescape flag. A little tweak to the rewrite, and we’re good to go…

RewriteRule ^/foobar/?$ /some/other/url#foobar/ [R=301,L,NE]

See that little NE on the end? That’s all we need to make rewrite anchors work.

Documentation on all the rewrite flags can be found in the Apache docs for the RewriteRule Directive.

This problem always drove me nuts when creating MySQL database backups. I want to make a tar backup of /var/lib/mysql/database_name and call it database_name.tar.gz. If I then unpack the tar under /root, I’ll have a bunch of worthless subfolders to drill down through: /root/var/lib/mysql/database_name. All I really want is the database_name folder, the /var/lib/mysql/ parent directories can all go away.

Here’s how to get rid of those pesky parent folders once and for all. Before running your tar command, you must first use cd to move into the parent directory that contains the folder you want. Then, within your call to tar, leave the parent folders off your target files/folders.

Here’s the command sequence for previous example:

cd /var/lib/mysql
tar -czf /any/folder/you/want/database_name.tar.gz database_name

The resulting file will unpack directly into a single subfolder called database_name.

If you run your tar process as part of a larger scripting event, your script might not run/maintain a shell interface. In these cases, the cd command will be executed in a vacuum, and won’t have any effect. I run into this problem when I try to perform shell magic inside of PHP scripts.

Fortunately, there’s an easy workaround: you can append multiple shell commands together using &&. With &&, each command will be executed and completed before the next one begins, mimicking a person typing out commands one line at a time.

Here’s what our MySQL example looks like as a single line:

cd /var/lib/mysql && tar -czf /any/folder/you/want/database_name.tar.gz database_name

Enjoy your tar backups sans worthless parent directories!