making a random page on your wordpress website

here’s my own solution to this:

step one: make a file in your template directory and add this as the content:

'post_status' => 'publish',
'posts_per_page' => 1,
'orderby' => 'rand',
'post__not_in' => get_option("sticky_posts"),

// It's time! Go someplace random
$my_random_post = new WP_Query ( $args );

while ( $my_random_post->have_posts () ) {
$my_random_post->the_post ();

// redirect to the random post
wp_redirect ( get_permalink () );

Step two: Create a page and select the custom template you created above.

Step three: Go to your “reading” settings page at and select the “static page” option to use the page you created above.

Word of caution though, having this on your front page may cause some pretty big server spikes if you don’t have caching turned up to 11.

A word of caution and frustration when using media_sideload_image

media_sideload_image details.

Currently the support docs for this function read:

Parameters Parameters


(string) (Required) The URL of the image to download.


(int) (Required) The post ID the media is to be associated with.


(string) (Optional) Description of the image.

Default value: null


(string) (Optional) Accepts ‘html’ (image tag html) or ‘src’ (URL), or ‘id’ (attachment ID).

Default value: ‘html’

Unfortunately when they say “Description” they really mean “title” of the attachment, and not the field named “description” that’s on every attachment page. There is no way that I can tell to add a description to your attachments when using media_sideload_image.

Where does WordPress store image resolution in the MySQL database?

A full year later and I’ve discovered that the image resolution IS stored in a very poor manner, as custom fields on the attachment. I’m still not clear on exactly how that works and I think I can write a plugin that will convert that crummy method to a custom taxonomy that would allow searching and easy display on sites.

Previously in 2017:

TL;DR: WordPress does not store image resolution in the database.  Nor does it store any information on the difference sizes of the image that it automatically creates.  Looks like the only interaction WP has with images and their resized versions is on initial load, after that it has no record of what’s available for use in posts.

Spent about an hour this morning searching for an answer for this, but there’s no indication that the image size is stored anywhere in the database.  Any time the image is referenced in full from WP, getimagesize is used to get the resolution. The rest of the the image attachment’s meta data is stored haphazardly in either wp_postmeta or wp_posts.  Oddly enough when using getimagesize outside of wp_get_attachment_image_src I seem to get different results (0x0 vs 9393×12500), which may have something to do with image size limits or memory limits in WP.

Here’s where you can find the data that’s stored for each image attachment:

post_content = description
post_title = image title
post_excerpt = image caption


If you’ve created a custom taxonomy for your attachments, they’ll be found in the expected taxonomy tables (wp_termmeta, wp_terms, wp_term_relationships, wp_term_taxonomy)


Fix Firefox’s broken search boxes

FFS, they disabled this too, wtf is going on over there Mozilla?

I’m not a fan of how Firefox has changed the search boxes, I always set the search box first, then hit enter, but with this new way, if you select it first, it’ll search on whatever’s in the search box, then will reset the search selection. dumb and counter intuitive, and wastes my time by being unreliable on which engine it’s going to search with.

Here’s how to disable the new search bar:

1. Go into the config by typing the following in the address bar and then hitting return (click “I’ll be careful, I promise!” if a dialogue comes up mentioning anything about dragons, if not just continue):


2. Paste the following in the wide “Search”-field that appears:

3. The value should be “true” by default, double-click on it so it says “false”

4. Restart firefox, the search bar should now have gone back to normal.

How to remove Emoji support from WordPress

The latest version of WordPress has some pretty stupid additions to it, namely the mandatory support of “emoji”, which are one of the greatest diseases on the internet. Why they thought adding more overhead to every WordPress installation just to add this little wanted feature was a good idea is beyond me, but if you’d like to remove it from your sites, add this bit of code either to your theme’s function.php file or your own custom fuction plugin that you’ve previously created:

remove_action( ‘wp_head’, ‘print_emoji_detection_script’, 7 );
remove_action( ‘wp_print_styles’, ‘print_emoji_styles’ );

thanks to for the heads up.

DC Cover Theme

“This January, we’re putting the focus squarely on the characters and iconic heroes of the DCU,” said DCU Co-Publisher Dan DiDio. “Not only will we tell new stories some of the more-deserving with special one-shots, but we’ll be giving every title in the line a unique treatment that puts the spotlight on the heroes and villains that populate the DC Universe.”

You can see the placeholder covers below, when the actual covers come out I’ll put them here.

via DC Blog