Post really large images in WordPress

Note: this “fixit” may only apply to personally hosted WordPress installations where you are free to edit the source.

You may find that you have an image you’d like to embed in a WordPress post, but uploading the image results in either “HTTP Error” (if using the flash uploader) or some string of gobbledygook with a reference to some WordPress PHP file.

I was trying to upload larger versions of the images I use in my blog header for anyone who wanted to see them. The largest of the images had dimensions of 18618×3776. (Yes, that’s in pixels.) The problem, it turns out, had to do with dimensions or image size — more specifically, WordPress memory limits.

When you upload an image to your WordPress site — as of version 3.3.1 — WordPress will automatically attempt to generate common thumbnail sizes that you can insert into the post. While trying to upload this image, I found that WordPress was using > 400Mb of RAM during the resize operation. If you do the math on the image dimensions above, that’s a ~70 megapixel image it’s trying to manipulate.

By editing the file /wp-settings.php, I was able to get rid of the errors and the image was resized properly.

Look for the line: wp_initial_constants();

Immediately above this line, insert the following, save the file, and try your upload again.

define('WP_MEMORY_LIMIT', '256M');
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Naturally you should massage those limits to reflect your specific installation, but adding these should get rid of the error(s) and allow WP to generate thumbnails for embedding.

BIND9 tip – statistics

If you add zone-statistics yes; to your named.conf.options file (if you are using an options file that’s externally included in named.conf) and you’ll be able to spit out a pretty dizzying number of statistics about your server. run sudo rndc stats to have these statistics dumped to a file. The default location for this file on a fairly vanilla install of Ubuntu server 10.04 LTS is /var/cache/bind/named.stats

If you want to change the default location, be sure you edit the apparmor profile for bind or you will get permissions errors. I’m lazy, so I just keep the default.


One stop shop for all bind9 options and the contexts where they may be used.

Reading the contents of a bind9 statistics file.

Troubleshooting BIND logging on vanilla install on Ubuntu 10.04 LTS

Bind is a bitch. The default installation configuration of it on Ubuntu 10.04 LTS server has some bugs that make it difficult for anyone with mediocre or less than intermediate Linux administration skills to troubleshoot configuration or run-time issues. The single biggest thing that makes it so hard is actually finding log information that you can act on. It shouldn’t be this way.

I’m not going to cover everything since there’s an enormous number of potential configuration problems that can cause your particular instance to have problems, but here are a few helpful things, that, once I found them, helped me solve my BIND issues.

NOTE: many of these commands will require you to be root or sudo as root.


If you can’t see what the problem is, you’ll never be able to solve it. Again, vanilla Ubuntu installation, try this:

tail -f /var/log/daemon.log | grep named

This will print all BIND daemon startup, shutdown, and major configuration fails to the screen as they happen. This is one of several BIND default logging options that can’t be changed. This is the best log for tracking major configuration errors that stop BIND from starting.

2. Apparmor (more LOGS, LOGS, LOGS)

I guess this bit of Ubuntu tech has been around a while, but you will find very little information on the web when searching for a reason your custom logs are not being written to. Either you must put your custom logs in /var/log/named or you have to edit the apparmor settings for BIND, specifying a path the “bind” account can read and write.

sudo vi /etc/apparmor.d/usr.sbin.named

Once you either put your custom logs in the right place or edit the “named” apparmor profile so the bind account can RW to them, do this to see the logs in real time.

tail -f -q /path/to/custom1.log /path/to/custom2.log

Here are some of the eleventy places I found some answers:

Fast and easy way to install webmin on Ubuntu 10.04 LTS

This is the fastest and easiest way I’ve ever found to install webmin on a fresh Ubuntu 10.04 server.

UPDATE 12/8/2012: Confirmed that this method works for a vanilla Ubuntu 12.04.1 LTS server.

1. wget -c
File will be named “webmin-current.deb” in your current working directory as opposed to a filename containing the specific version number of webmin.

2. sudo dpkg -i webmin-current.deb
This command will generate a number of errors. Ignore them.

3. sudo apt-get -f install
This command will install the missing dependencies, recompile, and install webmin.

Now, login to your webmin server. https://[serverIP]:10000

This method works as of today on a vanilla install of Ubuntu server 10.04 LTS with webmin version 1.580 as the current version.