Image sizes lost

  • I’ve encountered a strange issue with galleries on a few of my WordPress blogs, and whilst a similar issue is mentioned in some other posts they seem to all refer to an issue with PodPress, a plugin which I am not using on any of the affected sites.

    Basically since we moved server a few of the 25 or so WP installs we have seem to have had images that were uploaded into a gallery on post/page have lost all info relating to image size and the fact that thumbnails have been generated for these images. I would have assumed this was totally related to moving server, but am unsure of this because of the fact that many of the WP installs with galleries haven’t been affected.

    So if you look at this post on my own blog (co-incidentally about wp’s gallery function).
    https://alex.leonard.ie/2008/06/03/wordpress-25-gallery-templating/

    you’ll notice that all of the images are loading as full sized images and hence overlap each other and so on.

    In the gallery screen of this post each image displays with no option on thumbnails etc, and the full size image is automatically selected and reports a size of 0x0. Screen shot below:

    https://alex.leonard.ie/misc-images/alexleonard-gallery-issue01.png

    So I’ve been investigating a few of the possible things that could cause this. I’ve looked closely at the uploaded file permissions, groups and ownership, and have been able to compare them against another gallery on a working site on the same server:

    https://www.invisibleagent.com/2007/04/15/hotel-ballymun-photos/

    As best as I can see the permissions and ownership shouldn’t be causing any issue.

    After this I’ve been looking closely at the wp_posts and wp_meta tables in the db containing these attachments, and, well, everything *looks* fine.

    So the above example has a photo called kerry-morning which is in wp_posts as:

    mysql> SELECT * FROM wp_posts WHERE guid LIKE "%kerry-morning%";

| ID | post_author | post_date           | post_date_gmt       | post_content                                                                                                                                                               | post_title         | post_category | post_excerpt              | post_status | comment_status | ping_status | post_password | post_name          | to_ping | pinged | post_modified       | post_modified_gmt   | post_content_filtered | post_parent | guid                                                                     | menu_order | post_type  | post_mime_type | comment_count |

| 26 |           1 | 2008-06-03 16:28:58 | 2008-06-03 16:28:58 | This is taken down in Kerry when myself and a load of friends spent a weekend on Valentia Island. Needless to say, dawn was only captured having stayed up all night. | kerry-morning-mist |             0 | Beautiful mist at sunrise | inherit     | open           | open        |               | kerry-morning-mist |         |        | 2008-06-03 16:28:58 | 2008-06-03 16:28:58 |                       |          21 | https://alex.leonard.ie/wp-content/uploads/2008/06/kerry-morning-mist.jpg |          0 | attachment | image/jpeg     |             0 |

1 row in set (0.00 sec)

    I can then match this attachment up with it’s data in the wp_postmeta table thus:

    SELECT * FROM wp_postmeta WHERE post_id = 26;

| meta_id | post_id | meta_key  | meta_value    |

|      79 |      26 | _wp_attached_file       | /local/path/to/wp-content/uploads/2008/06/kerry-morning-mist.jpg                                                                                         |
|      80 |      26 | _wp_attachment_metadata | a:6:{s:5:"width";i:500;s:6:"height";i:335;s:14:"hwstring_small";s:23:"height='85' width='128'";s:4:"file";s:93:"/local/path/to/wp-content/uploads/2008/06/kerry-morning-mist.jpg";s:5:"sizes";a:2:{s:9:"thumbnail";a:3:{s:4:"file";s:30:"kerry-morning-mist-150x150.jpg";s:5:"width";i:150;s:6:"height";i:150;}s:6:"medium";a:3:{s:4:"file";s:30:"kerry-morning-mist-300x201.jpg";s:5:"width";i:300;s:6:"height";i:201;}}s:10:"image_meta";a:10:{s:8:"aperture";i:0;s:6:"credit";s:0:"";s:6:"camera";s:0:"";s:7:"caption";s:0:"";s:17:"created_timestamp";i:0;s:9:"copyright";s:0:"";s:12:"focal_length";i:0;s:3:"iso";i:0;s:13:"shutter_speed";i:0;s:5:"title";s:0:"";}} |

    So that *looks* alright, I think.

    I’ve compared the last files meta_key of _wp_attachment_metadata against one of the photos on Invisible Agent to see if there’s any difference, and that comes back as:

    | meta_id | post_id | meta_key                | meta_value|
|    3574 |     595 | _wp_attached_file       | 2009/01/070415-hotel-ballymun_07.jpg      

|    3575 |     595 | _wp_attachment_metadata | a:6:{s:5:"width";s:3:"600";s:6:"height";s:3:"450";s:14:"hwstring_small";s:23:"height='96' width='128'";s:4:"file";s:36:"2009/01/070415-hotel-ballymun_07.jpg";s:5:"sizes";a:2:{s:9:"thumbnail";a:3:{s:4:"file";s:36:"070415-hotel-ballymun_07-150x150.jpg";s:5:"width";s:3:"150";s:6:"height";s:3:"150";}s:6:"medium";a:3:{s:4:"file";s:36:"070415-hotel-ballymun_07-300x225.jpg";s:5:"width";s:3:"300";s:6:"height";s:3:"225";}}s:10:"image_meta";a:10:{s:8:"aperture";s:3:"2.8";s:6:"credit";s:0:"";s:6:"camera";s:19:"Canon PowerShot A95";s:7:"caption";s:14:"Serious Intent";s:17:"created_timestamp";s:10:"1176670075";s:9:"copyright";s:0:"";s:12:"focal_length";s:6:"7.8125";s:3:"iso";s:1:"0";s:13:"shutter_speed";s:3:"0.5";s:5:"title";s:0:"";}} |

    And boy is there a difference! Where? What? Looks like the broken galleries have the same thing in common – with in wp_postmeta both the _wp_attached_file and _wp_attachment_metadata are using the full local path (such as /home/virtualsites/domain/httpdocs/wp-content/etc) whereas the galleries which are working are loading the above meta_values as a relative path (relative to wp-content/uploads/).

    Now as my MySQL Fu is not very strong I’ve mailed our server admin about this and will hopefully go through doing some tests in the morning and confirming whether this is what is causing the issue.

    Is this a bug? Would other people whose image sizes have been lost find the same thing?

    Does this sound plausible? Has something changed in the core code recently which has changed the DB entries for _wp_attached_file and _wp_attachment_metadata to work off a relative path to the upload folder location rather than a full local path?

    If so is there a reason why WP version upgrades haven’t updated this data in the database?

    Or am I barking up the wrong tree?

    ??

    Cheers,

    Alex

Viewing 13 replies - 1 through 13 (of 13 total)
  • Thread Starter alexleonard

    (@alexleonard)

    So, since our server move we actually still have the old server stored locally with things in exactly the state they were in before we transferred.

    I have been able to access this and confirm that the gallery:
    https://alex.leonard.ie/2008/06/03/wordpress-25-gallery-templating/

    is displaying correctly, and in accessing the db and running the same commands found that the db uses the same local path designation in wp_postmeta as currently on the new server.

    The next plan is to incrementally update the WP install from it’s old version of 2.7.1 to 2.8.

    I completed this by ftp’ing the files to our local server and updating the site using the old wp-admin/upgrade.php method.

    After the upgrade I double checked the DB and the files are still using the local path instead of relative, and the gallery is still working. Which means I’m now extremely confused. I’m not sure why some wp installs would be utilising a local path in wp_postmeta for image location, and other ones would be using a relative path – I can only assume I’m missing a setting somewhere. Perhaps in wp_options.

    So looking at wp_options::option_id 60 (upload_path) in a number of db’s that doesn’t seem to provide any clean cut answer.

    On the current operating server, my own site has no option written into the upload_path option_value, a working site has it’s value set to wp-content/uploads (which made me think this was the issue) but then another broken site using local path’s in wp_postmeta also has it’s upload_path set to wp-content/uploads. So that doesn’t make any sense to me either.

    I think I’ve come to a dead end – not sure how to reconcile the differences and no idea why this is happening any more.

    For reference we did try what I thought might be the error in the previous post and changed one of the broken gallery entries in wp_postmeta so that it was only using a relative path (relative to the location of wp-content/uploads) instead of the local path, but no change occurred and the image is still loading the large version and within the post edit screen in the gallery tab of the image upload lightbox the image is still displaying the full size as 0x0 with no options on the thumbnail/medium/large versions.

    I am having the same issue. Few months ago this picture/gallery problem appeared and I really don’t know how to solve it.

    Thread Starter alexleonard

    (@alexleonard)

    Yeah, I’ve come no further on this one and it was starting to look very bad on how long things were taking to fix, so on the majority of sites I’ve just reuploaded the galleries which were broken and they’re working fine.

    Sort of frustrating knowing that there’s something funny going on and not having a clue how to fix it..

    This is really harsh because I’ve been having the EXACT same problem as alexleonard has been having and no matter where I look I cannot find a resolve. The worst problem is that this issue is causing me to do less blogging and making it increasingly difficult to keep my readers and traffic active.

    Any wordpress devs or gurus please advise on this thread/issue, we’re a very desperate kind here. ??

    Thread Starter alexleonard

    (@alexleonard)

    I really wish I could have worked it out, but I spent quite a long time trying to suss out a fix using every means I could think of, but in the end it was the only option to re-upload the galleries that were broken.

    Since then the issue hasn’t re-occurred – so I’m hoping it was just a temporary glitch..

    Is there any way we can escalate this problem, maybe even if just to get it looked at so they can call us idiots, that would be fine by me, I’ll take the heat for being stupid if it’s in fact something overlooked. hehe

    Ziyphr

    (@ziyphr)

    When trying to view/insert older images I noticed the thumbnails weren’t showing up in the admin area, and the file path it was inserting was the local one.

    I ran this query on the database to fix it:

    UPDATE wp_postmeta SET meta_value = REPLACE(meta_value,’/your/local/path/’,”) WHERE meta_key = ‘_wp_attached_file’

    Replace ‘your/local/path/’ with whatever is coming up in your database (see original post).

    I’m unsure if the “_wp_attachment_metadata” field value also needs amending. For me I’ve not run into a problem yet.

    omgitztrey

    (@omgitztrey)

    Has anyone tested @ziyphr’s fix yet?

    > Has anyone tested @ziyphr’s fix yet?

    Nope, but I’m just about to. Wish me luck!

    Well, nothing broke. It changed all the database entries to match the posts that worked – but it didn’t fix the problem. Must be something else to it too.

    same problem here and I’ve not yet resolved it.
    I’m debugging and I found that where everything works the array of the thumbnail is:
    Array ( [0] => https://localhost:8888/wp27/wp-content/uploads/acquario_1-150x99.jpg [1] => 150 [2] => 99 [3] => 1 )

    when is broken:

    Array ( [0] => https://localhost:8888/wp27/wp-content/uploads/img_0263.jpg [1] => 0 [2] => 0 [3] => )

    the thumbnails are created and on the server for img_0263.jpg

    I had the same issue for one of my wordpress installs.
    I solved it by updating wp_postmeta table like this:

    UPDATE wp_postmeta SET meta_value = REPLACE(meta_value,'/your/local/path/','')

    and then running regenerate-thumbnails plugin, so that _wp_attachment_metadata is updated as well (it should become corrupted in step 1, because when php serializes a string, it stores string length, which now has changed).

Viewing 13 replies - 1 through 13 (of 13 total)
  • The topic ‘Image sizes lost’ is closed to new replies.