First of all, thanks for the new version. It really adds up new functions. Here are a few ideasheme that I wonder if they would make a new install less intimidating for the lambda user and/or would add flexibility for the next version(s).

[b]Setup problem with zpmobile theme[/b]
I have added details in the bugtracker as I closed another error regarding 1.4.3 setup. Files for the zpmobile setup are missing from the trunk nightly build (1.4.3-BETA [10049] (Version officielle)), yet setup complains about it.
BTW, the theme appeared in the previous dev nightly [9995] and does not appear in the current 10049, even once I activated the plugin.

[b]2 or 3 log files?[/b]
Why is it that some installations show only the security and setup logs, while others also show the debug log? I haven't been able to find a consistent pattern.

[b]IDEAS FOR THE FUTURE[/b]

[b]Clone installation?[/b]
I see that it disappeared from the 1.4.3 beta...

[b]Keep setup files on the server?[/b]
I think it would be a good idea if one were to "clone the installation". Yet, I wonder how to do it safely. Maybe by keeping a setup folder called "setup_cb324" where the "extension" would be hashed from the password or user name, for example.

[b]Take Pages and News outside the Gallery?[/b]
I haven't dug seriously into the issue, but I'm thinking about this for a the church and especially for the office gallery:
– Use the photo gallery at http://mysite.com/photos
– Use the Pages and News feature to upload articles. They generally need to be related to the photo gallery because these articles will use photos and videos that are in the gallery. However, I would prefer to call the "pages" something like "http://mysite.com/innovations" and the "news" something like "http://mysite.com/articles". Then, once I call "http://mysite.com/innovations/new-platform-for-tires", the .htaccess file will transform it into "http://mysite.com/photos/page..."
I'm able to do the part that goes into the main .htaccess file, but I'm not confident on how to modify the menu system and .htaccess file [i]inside the Zenphoto folder[/i].
[i]Maybe I'm the only one with such a weird idea![/i]

[b]Administrative panel: Upload –> Files[/b]
I wonder if the "files" tab shouldn't be hidden when the "ajaxFilemanager" plugin is disabled.

[b]Administrative panel: Album and Image Descriptions[/b]

The Album Title and Image Title sections should be slightly higher. Currently, it's really crowded when the gallery is a multi-lingual one.

I know that one may personalize a theme ad lib. There seems to remain one problem, especially when many people are allowed to upload contents: it's not always obvious how fields are named. Ideally, there should be a "master page" that would define the following terms for albums and images:
– Custom data
– Codeblock 0...
So, for example, if I want to use "custom data" for a detailed description that would appear only to registered users and Codeblock 0 for a link to a colour-separated psd file, all my uploaders would see that descriptive field instead of "Custom data" and "Codeblock 0"

[b]Administrative panel: Choice of default theme[/b]
I'm a bit torn in selecting what should be the default theme for a brand-new gallery. On one hand, I find that the "defaut" theme is the nicest general-purpose theme (especially in light or sterile-light flavours). On the other hand, it's very hard to customize because it has first been defined as a dark theme, and it does not support the Zenpage plugin which is one of the major extensions of Zenphoto.

[b]Administrative panel: Plugins page[/b]
Text at the top might be upgraded to show that "greyed plugins are those currently loaded and that checked ones are those that will be loaded once "applied" is depressed".

[i]Documentation[/i]. At some point, we will need to guide users in selecting the proper plugins. For example, should I select "seo_cleanup", "seo_zephoto" or "seo_null" if some users upload photos with accented letters or the ".JPG" extension? Am I better with the zenphoto_sendmail plugin (which seems to be selected by default) or the PHP_mailer plugin? I'm willing to include that in my long-term documentation project, but I will need more input on those points.

[b]Stylesheets for the Themes[/b]
I don't know how many people try to integrate Zenphoto in an existing website. Calling the main stylesheet(s) of the website in the customized theme is a good starting point. However, there are sometimes issues with conflicting style names. Would it be a good idea to rename all styles with the "zp-" prefix? (for example: zp-images and so on?)

Thanks for your extensive comments! I will respond to them quickly and roughly. My colleagues surely will add up something later as well.

1. zpmobile got lost somehow with the svn repository switch. It will return.

2. Debug log: That only appears on debug occasions (dev versions) and needs to be enabled via the debug function (sbillard may correct me).

3. Cloning is a plugin and your server must support symlinks for it

4. It is general practice on lots of cms to urge the user to delete setup files. Even if renamed they are there and hackable. Don't forget the ones who want to exploit are clever.

5. Renaming pages/news in the url; You have to do that via htaccess rewriting. We once had it as an option but it always caused problems if it was forgotten somewhere to make those names dynamic. And it was rarely used as there were not much complaints. You had to edit htaccess back then as well as that could not know about the options. The "pages" and "News" are therefore reserved names so they are not mistaken as albums (yourdomaim.com/ is otherwise an album named ).

6. The file upload tab should actually be hidden...

7. You can write a filter plugin to even split the custom field into several one (they are still one field but seralized as the codeblocks). Then you could also name them as you like.
   A master or template page to rename items could probably be made but think of the support problems that could cause if these users with these custom names come here (if the person who set it up is gone or unavailble).

8. Default theme. All themes are a suggestions to use out of the box.. I can only say if none of them fits for you you have to modify or do your own. Btw, the name of the default theme is that it is indeed the oldest and first theme! We kept this and stoppdesign without Zenpage support because a lot of people need simple plain gallery ones to start with.

9. [i]Administrative panel: Plugins page
   Text at the top might be upgraded to show that "greyed plugins are those currently loaded and that checked ones are those that will be loaded once "applied" is depressed".[/i]
   Hm, I find it really obvious from software experience (offline and online) generally that things need to be applied first. It is that way on all admin pages.

10. [i]For example, should I select "seo_cleanup", "seo_zephoto" or "seo_null" if some users upload photos with accented letters or the ".JPG" extension?[/i]
    The extension has nothing to do with SEO actually. The text on the plugins actually explains what it is for. I really think people need to know a few things about general webstuff and we cannot tell everything. I fear we cannot do it right for any type of user.

[i]Am I better with the zenphoto_sendmail plugin (which seems to be selected by default) or the PHP_mailer plugin? [/i]
We cannot tell as every server is different. On some the PHP sendmail functionality is not configureed and some mail provider don't allow mailing over them. People need to try.

Thanks for the feedback. Here are a few comments on your comments.

1. I saw Vincent's message and your comment on zpmobile afterwards. I thought it wasn't ready yet. My apologies.

2. Cloning. I did not remember it was a plugin. I tried it for the first time and would offer a few suggestions in the order they appear during the process:
   – Select destination: it would be wonderful to be able to create the destination folder during the process. It would be similar to the "upload images in a new folder" dialog and would look like:
   Type Gallery Name ... in (select destination folder)  
   – Setup files: I just see the apparent contradiction between easy cloning and the need to find original setup files and upload them. Not sure if there is an "easy trick" that would be safe...
   – During the setup process (on the setup screen, after I had entered all relevant database information), the system warns me that I don't have the proper files (wrong date... please upload again). Yet, those files were taken from the same 1.4.3 version I had used this morning and uploaded in the proper "clone/zp-core" directory.
   – Once the process is successfully completed, the setup doesn't offer me to erase the setup files, but rather tells me to find and erase them both in the "clone" and "source" installations.
   – Once the setup process is successfully completed, it comes back to the "Clone" introductory screen. Shouldn't it go back to the administrative overview screen?

3. I see the support issues with custom names...

P.S. These were mere suggestions and ideas. I'm NOT saying that I'm right, by the way!

Keep up the good work!

My input:

Sorry about that. My SVN client has changed and does not show un-versioned folders when expected, so I missed that the theme was not included. I think acrylian has an even worse problem with his client since he had to ask me to make the commit when we added the theme to the DEV branch.

Logs will show up if they exist and only if they exist. So if no debug log is showing it means there is none. BTW, logs are not restricted to the three you mention. Other logs are possible. The log tab will show all logs found.

We do not wish to make Zenphoto into a file manager. Since you also have setup your albums and perhaps domain names (and you had to make the folder for the original insatllation) it seems little to ask that you also make the folders where you intend to produce other galleries.

Setup warns when the file times from the file system differ from a reasonable expected variance. We have tried to find a better means for identifying mismatched files as when they occur bad things really happen. Unfortunately nothing seems to work, usually due to operating system and processor architecture differences in the various environments where Zenphoto might run.. Usually the issue you describe happens when you are running directly form a repository since the in nightly builds, etc. I believe, all files are set to the same date/time. Of course if you upload the setup files at a later date then they will not match with the existing fileset. But since you did upload them, presumably you know why the dates mismatch.

Setup does not offer you to delete the files if the install was a clone as those files do not "belong" to the clone. But there is a button on the admin overview page of the master install to delete the files. Note also that if you are installing from a SVN base rather than a nightly build setup also does not automatically delete setup files (because that makes our testing, etc. a nightmare--test a setup change and the process erases your changed!)

I disagree. The [i]files[/i] tab should show otherwise there is no indication of why it might be missing.

What you describe for custom data is really theme dependent so not really much that can be done specifically on the admin pages. Of couse you can, as acrylian has said, create a plugin that filters the custom data. If you have a filter for custom data the default custom data field does not appear. I do not understand you comment about "support issues with custom names". Certainly plugins must insure that options they create are unique (These may be normal options or may be stored in the "plugin data" table. In either case things must be unique.) The ones we create typically include the plugin name as part of the option identification. Of course, the names of plugins must also be unique. That is, unfortunately, up to the creators of the plugin.

Really, what is needed here is a "style guide" for the installation. If you have many people with the ability to make changes then unless there is a style guide they will certainly not make consistent changes.

Just a quick comment on the 'file discrepancies' noted when I cloned the gallery.

1. I uploaded the zip file 1.4.3-BETA [10049], decompressed it and installed it, then deleted setup files as suggested.

2. I then wanted to clone, so I created (manually) the folder "clone" and requested to clone it there. When the procedure requested setup files, I uploaded them from the zip file I had on my computer, into "clone/zp-core", like it was asked by the cloning procedure. So yes, I had to upload them again because they were deleted and it was a new upload, but the source zip file I used was the [i]same file[/i] I had used to install the master gallery.

A last quick question regarding clones: could a clone manage the same "album" as the master gallery?

Source dates hardly matter if your FTP client does not propegate them to the website (which I doubt it can.) It is, of course, the timestamp on the server files that gets checked.

I am not exactly sure about your other question. But if you mean can it use the same album folder then the answer is yes. You can do this either by changing the album folder location stuff in the config file (the Zenphoto way) or by making a symlink to one album as the album folder in the other install. This latter is how I run my various test installs.

Of course the database is different. You could even share the database by using the same database name and table prefix, but that might get you into trouble as both installs could make changes and they would propegate to the other install.

Individual album folders could also be symlinked so that two installs could share "some" albums.

Thanks.

Setup dates: I cannot check that installation anymore, but the setup files upload was done with Filezilla which, upon upload, sets the time at its current value. So mystery solved.

Album folder: yes, you understood correctly. I was thinking that it might be a better way to develop my "innovations" pages totally independently of the photo gallery.

@sbillard [i]. I do not understand you comment about "support issues with custom names". [/i]
That comment refers to the question of renaming the default names of "news" and "pages" in the url (which we once had but abandoned for convenience).

I'll add on to this thread rather than starting another. I am evaluating zenphoto with a view to it hosting my imminent "take and publish a photo every day for a year" project. Having nothing to lose I upgraded from 1.4.2.3 to the nightly trunk.

The upgrade was IMHO too smooth (Centos 6, in a parallels VM on an iMac), a message flashed by on initial access which I am guessing was the "deleting setup files" notice. Consequently I spend a lot of time figuring what I was running and where the setup files had gone. In the logfile there were these lines I did not understand

warnVersion 5.0.0 or greater is required. Version 5.5.0 or greater is preferred. Use a lower version at your own risk.
Other log lines indicate that there should be a space after the 'warn', I have no clue what is at the incorrect version, (mysql? I am on 5.1).

I would also not have been aware of this had I not looked at the log files on the command line (yes, I know you should after install or ugrade but ...).

The spacing issue is, alas, easy to understand. Translation requirements mean that most of these messages are built by chunks crammed together. Forget a space after "Warn" and that's what you get.

The requirements are explained here: http://www.zenphoto.org/news/installation-and-upgrading
Testing is done with MySQL 5.5 + and PHP 5.2 + (or is it now 5.3 +?). Even though it uses functions that exist in PHP 5.1, I have heard of differences in implementation between various decimal versions, so that other scripts that run perfectly well in 5.0 won't run on 5.2, and the same problem happens between 5.2 and 5.4.

I run 3 servers with PHP 5.2.17 and MySQL 5.1.56 and they work well with one minor problem which may not even be linked to that issue. So maybe the message is a bit too intimidating. But at least it is effective and to the point.

We generally test on PHP 5.3.x only by now. Locally I use MySQL 5.5 but my live server has still 5.0.51 (although it has PHP 5.3.12) and that seems to work fine.

I'm on php 5.3.3, but the error message isn't only missing a space, it is forgetting to tell me what I should upgrade, so it's not as 'effective' as it could be.

You should first have seen that warning (it is not an error) when running setup.

The log messages are indeed not complete. That will be fixed. The upgrade does not "stop" for warnings not considered significant. Among those are the PHP and MySQL versions if they meet the requirements but are lower than the recommendations.

The recommendations are simply because we cannot test all these older versions, so we are sure only of the ones we test and recommend. However we do expect things to work with the older allowed versions.