Member
1. Is there documentation of the format of the .zdb backup file?
2. Is there an option or a way to unpack it so it can be text edited?
3. Is there a recommended set of formats/options to backup/restore the database using ordinary MySQL commands?
I have a development site and a public site, and I'd like to be able to easily synchronize one with the other. The only material difference at the moment is the domain name (as far as I know), but a heads up on any other issues would be appreciated. Don't want to have to run setup every time I do a sync.
2. Is there an option or a way to unpack it so it can be text edited?
3. Is there a recommended set of formats/options to backup/restore the database using ordinary MySQL commands?
I have a development site and a public site, and I'd like to be able to easily synchronize one with the other. The only material difference at the moment is the domain name (as far as I know), but a heads up on any other issues would be appreciated. Don't want to have to run setup every time I do a sync.
Administrator
The format is really a special formatted one for Zenphoto's own database backup one.
This short tutorial is about moving an installation but it is what you need to do to sync the local and live one as well:
http://www.zenphoto.org/news/how-to-move-my-installation-to-a-new-server-
The special part to consider is the albums being filesystem based so it is not database only.
This short tutorial is about moving an installation but it is what you need to do to sync the local and live one as well:
http://www.zenphoto.org/news/how-to-move-my-installation-to-a-new-server-
The special part to consider is the albums being filesystem based so it is not database only.
Member
Thank you for this help and prompt reply. The first attempt at syncing worked almost perfectly, and I now realize I need to make sure the .htaccess file is handled properly.
I'm going to assume the cache folder can be emptied, and then re-built by rebuilding the database and metadata. (?)
I'm also a little concerned about the apparent complexity of the cache_management plugin, and the linkage between it and the theme. Once again, I cloned the zenpage theme, but have not yet made any changes to it. However, when I enabled cache_management, my cloned theme didn't show up on the cache_management config page, so I'm going to have to track down where the theme-specific caching parameters are located. (?)
It is apparent that image caching is pretty important, since absent that feature, I'm getting noticeable delays on images as 'small' as 300K-500K, every time the image is accessed. I wonder if that is to be expected, or perhaps I've overlooked some other factor that might be the cause. (?)
I also discovered that in some cases (but not all), it seems re-building the metadata can overwrite the description field for an image. I was supplying what I would call a 'caption' to the image using this field, and when I re-built metadata, one image (a Getty Images historical photo), erased my caption and implanted what I must assume is metadata they supplied for that image. However, for those images which don't have that particular field, my captions were left intact.
Also, in the sync-transition, my original thumbnail designations for each album appear to have been lost in favor of the first image in the album. (I would assume that linkage is part of the database.) I can't say that's what happened with certainty though, and will verify it in the next go around.
Bottom-line, there are a variety of synchronization issues relating to the filesystem-based album data which can easily be handled by external scripting, and because they tend to be very site-specific, are best left that way.
Thanks again for your help. I try very hard not to post help requests without prior due-diligence. I had read the article you referenced already, but, upon a second reading, was reminded of the .htaccess component.
After working with Zenp for several months now intensively, continue to be impressed by the quality of the engineering and the support. My practice is to build-in provisions for donations to key open-source suppliers in all my client-quotes, and Zenp is clearly a high-value resource. FBO other professionals who do what I do:
<i>I believe all professionals who earn their living customizing and re-packaging the work of open-source developers should commit to properly compensating them for their contributions. As I see it, that doesn't mean suggesting to the client that they make a donation, it means making an appropriately generous donation directly out of the proceeds of the project. In many cases, without a product like Zenphoto, there is no project, and no client.</i>
(Sorry to get on my soap-box about this, but the viability of the open-source collaborative business-model depends upon retail consulting professionals to properly recognize the contributions of their suppliers, each time they complete a project.)
I'm going to assume the cache folder can be emptied, and then re-built by rebuilding the database and metadata. (?)
I'm also a little concerned about the apparent complexity of the cache_management plugin, and the linkage between it and the theme. Once again, I cloned the zenpage theme, but have not yet made any changes to it. However, when I enabled cache_management, my cloned theme didn't show up on the cache_management config page, so I'm going to have to track down where the theme-specific caching parameters are located. (?)
It is apparent that image caching is pretty important, since absent that feature, I'm getting noticeable delays on images as 'small' as 300K-500K, every time the image is accessed. I wonder if that is to be expected, or perhaps I've overlooked some other factor that might be the cause. (?)
I also discovered that in some cases (but not all), it seems re-building the metadata can overwrite the description field for an image. I was supplying what I would call a 'caption' to the image using this field, and when I re-built metadata, one image (a Getty Images historical photo), erased my caption and implanted what I must assume is metadata they supplied for that image. However, for those images which don't have that particular field, my captions were left intact.
Also, in the sync-transition, my original thumbnail designations for each album appear to have been lost in favor of the first image in the album. (I would assume that linkage is part of the database.) I can't say that's what happened with certainty though, and will verify it in the next go around.
Bottom-line, there are a variety of synchronization issues relating to the filesystem-based album data which can easily be handled by external scripting, and because they tend to be very site-specific, are best left that way.
Thanks again for your help. I try very hard not to post help requests without prior due-diligence. I had read the article you referenced already, but, upon a second reading, was reminded of the .htaccess component.
After working with Zenp for several months now intensively, continue to be impressed by the quality of the engineering and the support. My practice is to build-in provisions for donations to key open-source suppliers in all my client-quotes, and Zenp is clearly a high-value resource. FBO other professionals who do what I do:
<i>I believe all professionals who earn their living customizing and re-packaging the work of open-source developers should commit to properly compensating them for their contributions. As I see it, that doesn't mean suggesting to the client that they make a donation, it means making an appropriately generous donation directly out of the proceeds of the project. In many cases, without a product like Zenphoto, there is no project, and no client.</i>
(Sorry to get on my soap-box about this, but the viability of the open-source collaborative business-model depends upon retail consulting professionals to properly recognize the contributions of their suppliers, each time they complete a project.)
Administrator
Thanks for that long post and the last paragraphs specifially.
On syncing a site it is really important that you first upload the /albums folder as on the local site. And then import the database stuff.
The cache can be uploaded as well. If not it is recreated. Zenphoto normally creates it automatically on request, meaning if no cached image exists. Precaching is not directly necessary. You see the delay only the first time. On large sites with hundreds to thousands images that even are quite big dimensionwise it can overload the server. That is why there is the cache manager.
Some info about image and how there dimensions eat memory:
http://www.zenphoto.org/news/why-are-some-of-my-thumbnails-sized-images-not-generated-why-does-zenphoto-make-my-server-crash-while-processing-images-
And about how caching works:
http://www.zenphoto.org/news/is-it-really-necessary-to-pre-cache-my-images-at-all-
http://www.zenphoto.org/news/how-does-zenphoto-cache-
I hope that helps.
On syncing a site it is really important that you first upload the /albums folder as on the local site. And then import the database stuff.
The cache can be uploaded as well. If not it is recreated. Zenphoto normally creates it automatically on request, meaning if no cached image exists. Precaching is not directly necessary. You see the delay only the first time. On large sites with hundreds to thousands images that even are quite big dimensionwise it can overload the server. That is why there is the cache manager.
Some info about image and how there dimensions eat memory:
http://www.zenphoto.org/news/why-are-some-of-my-thumbnails-sized-images-not-generated-why-does-zenphoto-make-my-server-crash-while-processing-images-
And about how caching works:
http://www.zenphoto.org/news/is-it-really-necessary-to-pre-cache-my-images-at-all-
http://www.zenphoto.org/news/how-does-zenphoto-cache-
I hope that helps.
Member
[b]database backup[/b]:
There is no documentation on the format. What the file contains is (possibly) data compressed and serialized table arrays from the database. The format is not documented because it would really be impractical to try to modify the data.
If you are not changing Zenphoto versions between backup and restore there is no reason that a typical MySQL backup restore would not work. But the caveats of the order of doing the migration will still apply.
I do synchronize my public site with a test version that I keep locally. To do that I keep a mirror of the albums locally and update that if there are new images. Then I use FTP to upload the new items.
Since I keep all the image related information in the metadata of the actual image I am not so concerned about keeping the database in exact sync. (See the discussion on metadata below.) I make changes on the public site and on occasion download the Zenphoto backup and restore it on my local copy. This process works flawlessly.
[b]cache manager:[/b]
Themes register image sizes with the cache manager so it can know what to cache. If you simply clone a theme it is likely that the clone will still register the sizes as if it were the original theme. You have to update the strings it uses to register the sizes to reflect the new name of the theme.
[b]metadata[/b]:
Rebuilding the metadata will normally update the description if the image has a description as part of its metadata. So if you have imbedded descriptions you should probably update your image to reflect what you want rather than update the Zenphoto database. Otherwise what you see will happen. It is presumed that the image data is correct.
[b]thumbnails[/b]:
Most likely this is caused by the sync thinking the album is "new". That should be alleviated by insuring that the full album structure is in place before you install the new site and restore from the backup.
Hope this helps your understanding.
There is no documentation on the format. What the file contains is (possibly) data compressed and serialized table arrays from the database. The format is not documented because it would really be impractical to try to modify the data.
If you are not changing Zenphoto versions between backup and restore there is no reason that a typical MySQL backup restore would not work. But the caveats of the order of doing the migration will still apply.
I do synchronize my public site with a test version that I keep locally. To do that I keep a mirror of the albums locally and update that if there are new images. Then I use FTP to upload the new items.
Since I keep all the image related information in the metadata of the actual image I am not so concerned about keeping the database in exact sync. (See the discussion on metadata below.) I make changes on the public site and on occasion download the Zenphoto backup and restore it on my local copy. This process works flawlessly.
[b]cache manager:[/b]
Themes register image sizes with the cache manager so it can know what to cache. If you simply clone a theme it is likely that the clone will still register the sizes as if it were the original theme. You have to update the strings it uses to register the sizes to reflect the new name of the theme.
[b]metadata[/b]:
Rebuilding the metadata will normally update the description if the image has a description as part of its metadata. So if you have imbedded descriptions you should probably update your image to reflect what you want rather than update the Zenphoto database. Otherwise what you see will happen. It is presumed that the image data is correct.
[b]thumbnails[/b]:
Most likely this is caused by the sync thinking the album is "new". That should be alleviated by insuring that the full album structure is in place before you install the new site and restore from the backup.
Hope this helps your understanding.