All posts by tiki god

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:

Template Name: Random Post Redirector
Use on page to send viewer to random post optionally mod query

// set arguments for WP_Query on published posts to get 1 at random
$args = array(
'post_type' => 'post',
'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.

Optional Step three: If you want your front page to always show a random post, 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)


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.