October 31, 2022
WordPress Again and Again
October 31, 2022
WordPress suffers from misguided ideology, bad programming, and arrogance, usually all at the same time. Case in point: image handling.
Image handling in WordPress is pure insanity. Left to its own devices, WordPress will create multiple copies of every image at many sizes. This creates a pile of garbage on the server, roughly doubling the disk space used, sometimes worse. And they are so sure they are right about this that there is no way to turn it off - not by settings, not by filters or hooks - no way.
You have to hack the core. So I did. The following code makes the necessary alterations in two core files to shut off all the idiocy. The result is that image files are used exactly as they are uploaded. If you want to upload 10MB raw images straight off your camera, go ahead. * Only small 200x200 thumbnails are created, which are necessary for the Media Gallery to work efficiently, and don't take up a lot of space or make a mess of the server.
* I don't recommend doing this - crop and resize your images appropriately.
function stop_image_insanity(){
$fn = ABSPATH . 'wp-includes/media.php' ;
$fnbak = $fn . '.backup' ;
if( ! file_exists( $fnbak ) ) { //// just once!
copy( $fn, $fnbak ) ;
$txt = file_get_contents( $fn );
$s1 = "function _wp_add_additional_image_sizes() {" ; //// ~ line 5250
$s1a = "function _wp_add_additional_image_sizes() {" ;
$s2 = $s1a . " return ; //// simple " ;
$txt = str_replace( $s1, $s2, $txt ) ;
file_put_contents( $fn, $txt );
}
$fn = ABSPATH . 'wp-admin/includes/image.php' ;
$fnbak = $fn . '.backup' ;
if( ! file_exists( $fnbak ) ) { //// just once!
copy( $fn, $fnbak ) ;
$txt = file_get_contents( $fn );
$s1 = 'if ( $threshold && ( $image_meta[\'width\']' ; //// ~ line 288
$s1a = 'if ( $threshold && ( $image_meta[\'width\']' ;
$s2 = "\n\n\$threshold = 0; //// simple\n\n" . $s1a ;
$txt = str_replace( $s1, $s2, $txt ) ;
//// shut off exif idiocy as well
$s1 = "function wp_read_image_metadata( \$file ) {" ; //// ~ line 736
$s2 = "function wp_read_image_metadata( \$file ) { return 0 ; //// simple" ;
$txt = str_replace( $s1, $s2, $txt ) ;
file_put_contents( $fn, $txt );
}
}
stop_image_insanity();
function stop_image_insanity_again( $upgrader, $options ){
if( $options['type'] != 'core' ) return ;
unlink( ABSPATH . 'wp-admin/includes/image.php.backup' );
unlink( ABSPATH . 'wp-includes/media.php.backup' );
kill_image_insanity();
}
add_action( 'upgrader_process_complete', 'stop_image_insanity_again', 10, 2 );
set_post_thumbnail_size( 200, 200, 0 ) ;
update_option( 'thumbnail_size_w', 200 ) ;
update_option( 'thumbnail_size_h', 200 ) ;
update_option( 'thumbnail_crop', false ) ;
update_option( 'medium_size_w', 0 ) ; //// small?
update_option( 'medium_size_h', 0 ) ; //// small?
update_option( 'medium_large_size_h', 0 ) ; //// medium? not in ui
update_option( 'medium_large_size_w', 0 ) ; //// medium? not in ui
update_option( 'large_size_w', 0 ) ; //// large
update_option( 'large_size_h', 0 ) ; //// large
update_option( 'uploads_use_yearmonth_folders', 1 ) ;
Paste this code into your functions.php, and all of WordPress' image idiocy will go away. The first function makes backup copies of the php files and then makes the necessary edits. The backup files are used as flags to avoid executing more than once. While I was at it, I also shut off the horrible stupid image 'EXIF' read, so your default image titles are the filename, not the camera model.
The second function is hooked into the upgrade process, and re-runs the first function after an upgrade may have un-done it. The first function should work even if new versions of WP are slightly changed.
The "update_options" lines turn off the extra image settings and make sure they stay that way, and set the thumbnail to an efficient but usable size. These are entirely independent of the two functions, you don't have to use them.
It would be better to put all this code where it will only run on the back end rather than in "functions.php". But if you are not a great php coder, that is easy and will work. It is very lightweight and has very little performance impact even if you run it all the time.
The final question is why is WordPress doing this in the first place? The answer is: to conserve bandwidth. And there's some really twisted logic that has to go into that, because networks get faster all the time, and more 'bandwith' is created every moment of the existence of the universe. The beknighted imbeciles at WordPress do this at the expense of processing time, disk space, and sanity. Disk space is not nearly as infinite as bandwidth, and neither is CPU time on a heavily-loaded server. And the awful mess they create …
It's not just the file system that they make a mess of, they overload the database with infinite backup entries and all sorts of other garbage. These lines will stop the post revision backup insanity and keep your database small and speedy:
remove_post_type_support( 'post', 'revisions' ) ;
remove_post_type_support( 'page', 'revisions' ) ;
I have added a ton of functionality to WordPress, but I have also turned off so much useless and worse-than-useless crap that my version actally runs noticeably faster than stock. My image uploads are now much much faster.
In summary - WordPress is a pig that shits where it lives - all over the file system and the database. But sadly, nothing else out there is better. WordPress has a lot of advantages too. It does most of the heavy lifting for you, and where it is badly behaved or outright stupid, it often takes just a line or two of code to fix it. Or a few thousand, in my case.
To undo this, remove the code from wherever you pasted it, and re-install WordPress.
Update:
Not only does WordPress resize your images without asking, it then discards the originals without telling you! This is the absolute worst most arrogant programming I have ever seen, and unfortunately, par for the course with the WP development clowns. I'll have to re-shoot a lot of things that WordPress got rid of for me.