Title: achthomas's Replies | WordPress.org

---

# achthomas

  [  ](https://wordpress.org/support/users/achthomas/)

 *   [Profile](https://wordpress.org/support/users/achthomas/)
 *   [Topics Started](https://wordpress.org/support/users/achthomas/topics/)
 *   [Replies Created](https://wordpress.org/support/users/achthomas/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/achthomas/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/achthomas/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/achthomas/engagements/)
 *   [Favorites](https://wordpress.org/support/users/achthomas/favorites/)

 Search replies:

## Forum Replies Created

Viewing 3 replies - 1 through 3 (of 3 total)

 *   Forum: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/)
   
   In reply to: [WordPress admin slow for editors, fast for admins](https://wordpress.org/support/topic/wordpress-admin-slow-for-editors-fast-for-admins/)
 *  Thread Starter [achthomas](https://wordpress.org/support/users/achthomas/)
 * (@achthomas)
 * [9 years ago](https://wordpress.org/support/topic/wordpress-admin-slow-for-editors-fast-for-admins/#post-9109919)
 * i have run into this issue again for another site, so i decided to have another
   look into it again. what i’ve overlooked last time was the HTTP requests that
   query monitor lists. those http request seem to check api.wordpress.org for updates
   and add 3-4 secs to a page load, but strangely only for non-admin roles. so i
   added a little code to a custom plugin which disable those checks for non-admins.
   they don’t need that, since the admin takes care of housekeeping.
 *     ```
       add_filter('pre_http_request', function() {
           if(!current_user_can('update_core')){
       		return;
       	}
       });
       ```
   
 * fixed the issue for me. if a non-admin logs in, the requests get circumvented
   by forcing (quick) timeouts.
 * hope this helps.
    -  This reply was modified 9 years ago by [achthomas](https://wordpress.org/support/users/achthomas/).
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Crop-Thumbnails] Plugin upscales images that are too small](https://wordpress.org/support/topic/plugin-upscales-images-that-are-too-small/)
 *  Thread Starter [achthomas](https://wordpress.org/support/users/achthomas/)
 * (@achthomas)
 * [10 years ago](https://wordpress.org/support/topic/plugin-upscales-images-that-are-too-small/#post-7271098)
 * ok, i get your point. in this case this may indeed be desirable. maybe you want
   to consider an optional switch for people who’d like to prevent upscaling in 
   a future update. that’d be really cool and make the plugin even more versatile.
   for now: thanks for the tool and your quick support!
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Crop-Thumbnails] Plugin upscales images that are too small](https://wordpress.org/support/topic/plugin-upscales-images-that-are-too-small/)
 *  Thread Starter [achthomas](https://wordpress.org/support/users/achthomas/)
 * (@achthomas)
 * [10 years, 1 month ago](https://wordpress.org/support/topic/plugin-upscales-images-that-are-too-small/#post-7270830)
 * Hi Volkmar,
 * thanks for you quick reply! I think you misunderstood, there’s no problem with
   the metadata, everything works correctly.
 * Here’s an example. I have registered additional image sizes, onbe of them is 
   900×450. Then I uploaded an image that’s only 520×347 and wanted to adjust the
   cropping area. Although the original image is too small, the plugin generates
   a file with dimensions 900×450. Here’s my `wp_get_attachment_metadata()` Array:
 *     ```
       Array
       (
           [width] => 520
           [height] => 347
           [file] => 2016/03/01/myfile.jpg
           [sizes] => Array
               (
                   [thumbnail] => Array
                       (
                           [file] => myfile-400x267.jpg
                           [width] => 400
                           [height] => 267
                           [mime-type] => image/jpeg
                       )
   
                   [feature_large] => Array
                       (
                           [file] => myfile-900x450.jpg
                           [width] => 900
                           [height] => 450
                           [crop] => 1
                       )
   
               )
   
           [image_meta] => Array
               (...)
       )
       ```
   
 * You see: the plugin creates an image which is larger than the original one, does
   all the metadata updating correctly. But: this puts low-quality images into the
   system since they’re larger than the uploaded original. You get what I mean?
 * Maybe my assumption is wrong that nobody would upscale an image beyond its original
   size (since this results in poor image quality), but I might be wrong.
 * In my code I can circumvent this, but if this really is a bug (and not a feature;)
   this might be worth some consideration in a future update. I’d appreciate that!
 * Thanks
    Thomas

Viewing 3 replies - 1 through 3 (of 3 total)