I’m using this SQL until an update is available:
UPDATEwp_ngg_pictures`
Set imagedate =
Concat(
SUBSTRING(meta_data, LOCATE(‘”created_timestamp”;s:16:”‘,meta_data ) +32, 4 )
,”-“,SUBSTRING(meta_data, LOCATE(‘”created_timestamp”;s:16:”‘,meta_data ) +29, 2 )
,”-“,SUBSTRING(meta_data, LOCATE(‘”created_timestamp”;s:16:”‘,meta_data ) +26, 2 )
,” “,SUBSTRING(meta_data, LOCATE(‘”created_timestamp”;s:16:”‘,meta_data ) +37, 2 )
,”:”,SUBSTRING(meta_data, LOCATE(‘”created_timestamp”;s:16:”‘,meta_data ) +40, 2 )
,”:00″
)
WHERE imagedate < ‘1971-01-01’`
Unfortunately, importing the Metadata again is not enough – it shows the right data under “meta” but sorts the pictures by filedate or whatever – had to delete my pictures and upload them again with the older meta.php. Only then it worked. 🙁
there is one workarounod, try to upload the images without EXIF info (if exporting from lightroom use copyright only)
that worked for me… too bad I need to have the EXIF data in the pictures
Any ETA on getting this problem fixed? NextGen is a popular plugin and this is a very annoying problem!
Incidentally, I’ve tried Simon’s suggestion and replaced lib\meta.php with the one from 1.9.10 and I agree, the problem is fixed, for newly uploaded pictures anyways. Importing new meta data on a previously uploaded picture only changes the date to the upload date, which I suppose is better than 1 January 1970…
I await a real fix from NextGen.
I am having the same problem. The developers do not seem to be very interested in either fixing this problem or even responding to it. Why would anyone want to pay for any of their upgrades or themes if they will not even respond to this problem?
@wagnerbm01 – As stated in our last reply [here], we are planning on including a fix for this in the next upgrade. v2.0 Beta is right around the corner and will hopefully be available within the next few weeks. Included in the Beta is a solution for this issue.
@photocrati – could you please confirm whether this will fix retrospectively without the need to upload the images again?
I’m having the same issue as the previous posters. Any new info on when the next upgrade – with this fix – will be released, and if it will fix the dates for images already uploaded?
I’m having the same issues.
Any news on when it’s fixed?
@photocrati if it’s simply a matter of reverting lib\meta.php to the 1.9.10 state, wouldn’t that more than justify a 1.9.13 update? Rather than waiting 2+ months — or however long it will take for the new 2.0 to come out? Just saying, this is a documented issue that numerous users are experiencing, and developer relief would be appreciated sooner than later. Thanks for all you do!
And thanks @simon for all the helpful info!!
Just came across this… ugh. This is a stupid problem we have to deal with – give us an update. @photocrati
Hey all, we are currently discussing if we are able to do a 1.9.13, because v2.0 is right around the corner. We are currently testing this next upgrade and will be releasing it first as a Beta. v2.0 does include a fix for this, and you shouldn’t have to re-upload images. The meta should fix itself with the update. We may go ahead with v2.0 rather than do a v1.9.13, as they would be back to back updates. If we do v1.9.13, that would likely be available within the next week or two. v2.0 should hopefully be available within the next few weeks. We apologize for the inconvenience this meta bug has caused, and want to assure you that v2.0 does include a fix and we’ll get that out to all of you as soon as possible.
I certainly hope for a stable 2.0(.x)!
This issue is also causing a wrong date in (SEO) xml sitemaps for ngg-tags ánd the xml-file itself is dated 1-1-1970.
Prefer an small update now than larger update later. I would go for the simple solution to fix this bug but it up to you. .
