Hello. Thank you for this software. I hope to be able to customize the fields associated with images. I thought I might just change the names of the existing fields, but as yet cannot figure that out. Please advise whether what I want is possible.

Thank you.

Not sure I understand. Could you try to explain some more.
Thanks.

Thanks, fretzl.
Right now, the fields available are:
Location:
City:
State:
Country:
Credit:
Copyright:
I have no need for any of those. I would rather have fields of my own choosing. I don't know how to change those, or whether I should. I don't know if I can add others, or how.

You cannot change those. But you don't have to use them for their original label. On the theme side no one sees how they are named originally. For example on our own site the location field is used for links to 3rd party themes.

It is technically possible to extend the "custom field" below via a plugin filters but nothing ready made exists for that.

I have tried all of the themes, and I can't see how any of the fields I have mentioned are displayed to users. If these are not displayed to users, then I can't make use of them. My goal is not just to display images but to tell the user/viewer information about those images.

I must be missing something important...

You have to modify your theme to show these fields. Or the easy way is just to use the image description.

None of the themes prints this information.
However, there are functions you can use to print this but you will have to insert this yourself.

This one is probably the easiest:
printImageData($field, $label = '')

So, in image.php insert something like this where you want it to appear:
` Say you filled out New York in the "City" fied, this will output: City: New York`

But instead it "prints" this:

a:1:{s:5:"en_US";s:19:"City: New York";}

Ah yes, forgot these fields are multilingual.

You can use this instead:
``

This is similar for all fields, e.g.:
``
…etcetera.

That's actually a bug. printImageData should cover multilingual fields. getImageData() actually does already correctly so extra wrapper not needed as in fretzl's example. But was not used byprintImageData` internally for unknown reasons. This is fixed in the master on GitHub now.

There are also object model methods who do it also correctly like
echo $_zp_current_image->getLocation()

Now it displays correctly, but still it really won't work for me because the heading for each field Location, City, etc. are all still showing. I'm surprised no one has ever asked for this before. I'll check back someday to see if my request ever gets implemented.

In the meantime, thank you for the prompt and helpful responses.

What we did is change here is the display on the front end (theme). That is what your users see.That is independent from the backend display. Even if the label on the backend would be changed the database field would still be the same internally anway.

Again, if you need full control of the display why don't you put the info right into the image description? Your visitors will not care which field the data comes from.

I suppose I could do that. It would require copying and pasting the "headings" each time I added an image.

But, this is a database! In my mind, when objects share similar data they should have fields to contain that data. I have identified twelve items of interest for every one of my images.

I wonder how much I should pay for a modification to this software - one that would be open source for everyone to utilize.

Zenphoto is not a "database" technically :-) The existing fields cannot be changed but it would be possible to extend to add additional ones at the bottom where the custom data field is. Those however will not be covered by the search on the theme side.

This is probably way off topic for the thread. Still, you should not be provided incorrect information as has been done above.

There is a standard means for adding database fields. There is an example of this in the userAddressFields plugin. There is also another in the customFieldExtender example plugin. Unfortunately this is not included anywhere in the Zenphoto repositories, so you would have to install the ZenPhoto20 package to get it.

In all cases if the examples are followed the added fields [b]WILL[/b] be included in the possible searchable fields. They default to not enabled just like the EXIF and IPTC fields from the image metadata.

Using existing database fields is a shortcut way to provide your own data, but it does have perils. Unless you disable the processing of image metadata that feeds these fields what you manually enter can be overwritten on metadata refreshes.

And, of course as you have noticed, the standard printing functions believe the know the "name" of this field and will show it.

If you still want to use these fields for your own purposes after reading the above, then to get your desired name you will have to provide your own printing function.

You ask how much it would cost to implement this. I would love to respond, but unfortunately the zenphoto team has seen fit to remove my details from the "pair support" page. Perhaps one of the team members who are left in the list has the knowledge and skill to quote you on this change. If not you can contact me at stephen [at sign] sbillard.org.

I admit it was a bit inaccurat information and mainly aimed at Stephanie not being a developer apparently.

Quote:There is also another in the customFieldExtender example plugin. Unfortunately this is not included anywhere in the Zenphoto repositories
It is though named differently: https://github.com/zenphoto/Unsupported/tree/master/plugins/filter-custom_data

You have been removed from the paid support page because it was as you know always for team members only. You choose not to be one anymore. Also, pointing to the fork is not helpful.

Are you afraid of the fork? Is the zenphoto team now into censorship?

As to the plugin you point to. Again, you have made a mistake. Perhaps you should research your answers more carefully so you do not mislead your users.

That plugin does not add any fields to the database at all. It is simply a means of storing data in the custom field of the database table. The whole reason for the new technique is that sharing the custom field is not parasitical as plugins tend to step on each other's data.

As to the paid support page--that is your call. But you should note that the page is really for your users to get features they need in zenpoto (or its fork on GitHub.) So right now you have only one option for someone who wants to customize the way zenphoto works--you. Given your propensity to mis-state the current features perhaps that is too limited a choice.

Stephen, we're trying to foster an open community here, but it's difficult to do so when we continue to receive divisive posts from former members. This is not censorship, it's simply us doing what is right for our project and having a dialog. We haven't removed or blocked any posts.

If you wished to have a say in how the project operates, and the ability to help and post information on the forums, then you should collaborate with us positively rather than dividing yourself and making fun of and deriding our statements. This isn't productive, and that's why it isn't helpful as Malte stated.

We welcome your help if it is positive and supportive. However, it is unwelcome if your posting continues to be derisive of our developers, or the statements they make about the software or how we support our users.

Your project may operate however it wishes. But of course I would expect that your prime focus would be on what your user need/want.

The information provided above is misleading at best. That is why I have posted the correct information. I did also react to acrylian's statement that pointing to the ZenPhoto20 fork is not helpful. I guess I disagree, since it does provide the example plugin for making these custom fields whereas the plugin acrylian links to does not.

Same thing for links that might help users get custom features they might wish. You can limit those to your team. No problem, but that does also limit the options of your users.

I have had enough time now to look through the items sbillard and acrylian have linked to. I have to say upfront and I hope not too rudely: that is exactly what I wanted in the first place and I don't know why I wasn't just directed there in post two of this thread. Just because I am not a developer does not mean I can't learn. I wouldn't be using open source software if I was a total ninny.

Now I just have to figure out whether I should delete all my zenphoto and run with zenphoto20, or just borrow the customFieldExtender page from 20, or stick with my blob of data in the description of each image with zenphoto.

I know I need to go zenphoto20; I'm just a little lazy about it all right now.

I do appreciate the help I have received here but I wish it had been a little more forthright.