I have a problem..
I understand why its happening and cannot find a resolution to this problem.
Basically I had to restore a backup of the Gallery on jan 11th 2012 so now all the images metadata = the date I reuploaded the albums. Not the actual date they should be.. Although they are recorded as the date they was initially discovered which is stored in the database.. this is fine...
So all the album dates = the right date as of now..
So to get down to the actual problem.. The new albums are not creating dates unless I refresh the metadata for that album but the problem with this is... If I refresh metadata all my image dates will be set to jan 11th because that's the date on the images due to having to re-upload them..
This is the only way the albums will have a date on them..
Even if I create a new album and assign new images to the album It not give that album a date at all. Not even the creation date of the album.
So basically all new albums that are created will not have a date unless I specify one myself or refresh the metadata which will then reset all the images that was from the backup to the backup date. This is what I don't wanna do and its a good job I do have backups because I messed it up alot of times doing this, trying to figure out what the problem was.
So how come the albums are not finding the date of the last image that is recorded in the SQL database for the specific images in this album but only will get a date if I refresh the metadata which is not an option for me.
Is there anyway around this.. Is this a bug? Any help would be amazing and I hope I explained it well enough.
Thanks for reading.
Comments
There seems to be some major changes in the 1.4 releases.
http://www.zenphoto.org/trac/ticket/2084
What do you mean with latest builds? 1.4.2.1 or svn/nightly? Just so my colleague who is the expert on this can easier join later.
Non of my albums are creating dates, Not finding the date of the last image uploaded.. I have the publish option and set album date as lastest image date ticked also.
I think the reason you cannot recreate this is because my gallery is already an existing gallery that I create folders with and move existing images into the folder.
I think its a problem with existing galleries with existing dates as I think its only reading metadata and its confused because it not the same as the date registered in the database... Its the date from when I had to restore all my files.
If your testing this with new images and albums then it might not show the problems I am having.
The next release of Zenphoto does add a note to this effect in the description of the option.
Of course, Zenphoto cannot know what a date was supposed to be, it can only look at what is there. Either in the metadata of the image or lacking that the time stamp of the image. If those are not what you want then you will not get your desired result. Images are "new" if their timestamps do not match the value recorded in the database because this means the image has [possibly] changed since Zenphoto discovered it.
If by "moving images into it" you mean using the Zenphoto "move" function, then those are not new images by the above definition.
Generally if you have done restructuring of your gallery as you describe you probably should refresh the metadata to be sure everything is in sync.
Unfortunately refreshing the metadata is not enough when the albums are nested.
The album date where the image resides in will get updated correctly, but not his parent(s) album.
Is this fixed in 1.4.2.1?
I am still on 1.4.2 but first need to sort out my moded plugins.
But there are other good reasons to update to 1.4.2.1--see the announcement.
Can you tell me what the difference is between
`$_zp_current_album->getUpdatedDate()`
and
`getAlbumDate()`
The second gives you the "date" of the album. Depending on your options this is either the date it was created or the date of the most recent image as noted by image discovery.
Because of the restore I had todo to all the file all the dates will be reset to the date I re-uploaded them so I am stuck on this one..