Hello,

first off: zenphoto is still my favourite gallery management system and I love how versatile it is. You're doing a great job!

One thing I would wish for though is some form of customization options for the backend. I come across computer unsavvy clients a lot. Most of them update their sites rarely and so the more intuitive the interface for them, the better.

Now the screens for album and image edit have a lot of fields that I find I don't use in my custom themes in most cases, so they unnecessarily clutter up the interface.

One easy solution I could think of would be adding explicit ids and/or classes to the backend tables' rows and columns so they could be styled with custom css and or js (e.g. via a plugin). Marking the necessary fields red or adding comments for what format to enter data in would really help a lot of people I've worked with a lot.

What would you think of something like this? Too hackish or a valid solution?

Another thing I've been working on that has been quite helpful is a plugin inspired by advanced custom fields for wordpress (http://www.advancedcustomfields.com/).
This allows for highly customizable fields to use in the backend that can be checked from the theme. In the backend the album edit might look like this: http://i.imgur.com/UvE9TA1.png (could be made prettier of course). Now the same thing could of course also be solved with code blocks, but again that's not a very intuitive solution.

Is there a plugin like that already that I don't know of? Do you think that could be interesting? The next step for me would be to allow the creation of fields from the backend plugin options, right now it has to be done manually.

Thanks for your feedback,
Philip

Thanks, we appreciate any. So let me answer quickly:

1. I did not encounter this yet and I have some clients that are far from computer savy as well :-) The backend respectively the underlying html/css code is scheduled to be reworked sometime (the well know time issue and we are not that big as WP naturally). When we do that, this could be considered. So you should open a ticket. But this will for sure not happen before 1.4.6.

2. You can already add your own fields. However not via existing options but there are several filters available to set that up.
   http://www.zenphoto.org/news/zenphoto-plugin-architecture

You can add to the custom fields and even to the boxes on the right. For custom field storage we provide the standard table "plugin_storage" so you neither have to create your own extra table or modify existing ones.

You for sure could write a plugin to provide options to enable fields either via plugin options or with some sophisitcated interface directly on each field. Just someone has to work it out :-) Here is a demo one to modify the custom field: http://www.zenphoto.org/news/filter-custom_data (hope it still works not tried in ages)

You can open a ticket for this as well or just start it yourself. We gladly try to help here as much as we can.

Hello acrylian,

thanks for your fast answer.

1. As you saw I replied on the general ticket on the backend html rework. I can make an own ticket as well though of course. Good news that you are working on an backend rework. Any idea yet on whether it will just be a markup update or are you going to introduce new features as well?
   The backend is working alright as it is I guess, I'm just a usability junkie and newer systems like http://koken.me/ offer a pretty nice workflow - though koken especially is sorely lacking when it comes to customization.

2. Thanks for the answer, though you misunderstood - I already have my own plugin for that up and running - the screenshot is from a working project. And it is indeed based on sbilliard's demo. The question was more whether it would be interesting for people to develop this into a full-fledged plugin that allows users to easily add their own filters. Or whether maybe I overlooked an already existing solution.

If I find the time (good old time issue) I'll code a more full-fledged version for people to try out and check the feedback.

1. I heard of but never used koken (I guess I will take a look now finally). Of course a fresh started script can, well, start fresh. No need for compatibility and such yet.

The ticket is just a long time plan and primarily to clean up the quite grown code. Sure there will be changes but I think overall it probably will generally stay as it is. But we will have to discuss that then first.

2. Sorry, missed the screenshot somehow! New plugins are always welcome and we alway encourage people to write them. The best motivation - as you know - is always if you actually need and want a feature yourself. Any open source project is dependent on such as we can't do it all.

I took a look at koken. Looks more like a desktop media management like Adobe Bridge, but some ideas are nice. (I don't understand why it is not open source though).

Yeah, koken is very app-like. Fancy looking and intuitive, but very limited once you want to do your own thing and the fact that it's not open source is reason enough for me to not use it. Also, their templating engine is extremely basic and doesn't even allow the use of php - so no object access or anything.

Anyways, I started to work on my advanced custom data plugin. Before I fully dive in it would be great if you more experienced developers could help me out with how to best approach the general structure. I have two ideas:

1. In the plugin storage table, save the existing fields with type acd_album/acd_image, name as aux, input type and additional settings as a serialized array in data.

In the album/image objects, save the field id, value and additional settings as a serialized array in custom data.

2. Save everything in the plugin storage table:
   Existing fields like above.
   Then for every image that has a field set to a non-default value, create a record in the plugin storage with type acd_entry, save the id of the relevant image in aux and save field id, value and additional settings in a serialized array in that records data field.

Pros and cons I can think of:

1. Would keep the data together - each image record has that image's custom data saved. The plugin storage wouldn't get filled up.

2. I have an instinct that this could make it easier to query for images by custom data like getImagesByAcd("show_title","true"). But one would still have to deserialize the array, so maybe that's not true.

Would be great if you could give me some insight!

A general way we use the table is this way:

[list]
[]
type = pluginname or if it has several usages pluginname_ (or prefix -> example scheduled content publishing)
[]aux = the item (for example downloadlist plugin, rss, scheduled content publishing)
[*]data = the actual value, often serialized if you need more than one value
[/list]
So for images custom data I would probably use separate entries like this

Maybe:
image_customdata | id of the image | the data serialized
or
image_customdata_ | field name | value.

It is an all purpose table and differently to the other items there is no object model for it since there is no real fixed usage way.

Hi,

I'd be very interested to try this plugin, if it's up-and-running.

a|x

If we'd knew it would be on our extensions section actually. But of course if no one tells us :-)

So sorry for not getting back to you. I thought I had this thread on email notification.
Anyways, I took up work on this after a long rl related break. I'll let you know when I have something working running.

Just to note: This forum has no email notification at all actually. RSS is the only way.