How to display Custom_user_fields on sides of Image in Displayimage.php

[codeslayer]

Hi !

I need to display some of the "custom_users_fields" next to Image either left or right, in displayimage.php
Screenshot is attached.

Please tell me how do i display individual fields from database on displayimgae.php page.

any help in this regard will be highly appreciated.

Thanks

[codeslayer]

Can anyone help me with the problem stated above, please !
admins, moderator, developers anyone please help !!!!

[codeslayer]

no support ?

[n3n]

Im also interested in finding this out.  Also i would like to move the whole info block to the right side of
the intermediate image.

[codeslayer]

i wish if there was somekind of support here !

[Joachim Müller]

If nobody answers, then usually nobody knows the answer. What would be the point of supporters posting "I don't know how to accomplish this" or "I'm not ready to look into this in-depth"? Don't mix up terms: there is support if things go wrong or you get errors. There is only limited feedback from supporters if you request new features, which is basically what you did.

[codeslayer]

If nobody answers, then usually nobody knows the answer. What would be the point of supporters posting "I don't know how to accomplish this" or "I'm not ready to look into this in-depth"? Don't mix up terms: there is support if things go wrong or you get errors. There is only limited feedback from supporters if you request new features, which is basically what you did.

I Guess i have to make my own way. All i wanted to know how many file are involed in displaying details from database on to displayimage.php. I could have used simple php to get the rows and display it on displayimage.php but i wanted to use the existing CPG infrastructure knowing how things work in CPG. Unfortunatly there is no DFD's avilable to tell us about the structure and flow of data.

It makes sense displaying different data in different places.

I know you guys are working hard and CPG is getting better and better day by day, and i am sure that one day this feature will be considered in upcoming features 

[Paver]

We all make our way as this is an open community.  The developers do write quite a bit of documentation, but yes, there is no "code documentation".  On the other hand, this is open-source so you can easily follow the code flow, look at the data structures, and customize as you like.  In fact, there is code documentation in that most of the code is well-commented and well-labelled (in terms of variables, field names, etc).  You have the output in front of you and the code ready to examine.  That is more than sufficient, particularly when you realize that the code changes (via improvements) often enough that it would be very time-consuming to write the documentation you are requesting while coding the new features and improvements.

In any case, that's the way it is.  Make your own contribution as you are able to.  You are more than welcome to.

As for assistance, as GauGau said, if someone who read this thread were able to assist, he/she would.  I personally cannot give any assistance off the top of my head.  If I had the time and inclination to do so, I would use the same tools I use for any coding - a good searching tool (I use WinGrep), a good text editor (I use CrimsonEditor), and a good database editor (I use phpMyAdmin).

As GauGau also implied, if you have patience, someone might assist you in the future.  You don't have to do everything yourself, but you shouldn't assume that someone else will be able to help you immediately.

[codeslayer]

We all make our way as this is an open community.  The developers do write quite a bit of documentation, but yes, there is no "code documentation".  On the other hand, this is open-source so you can easily follow the code flow, look at the data structures, and customize as you like.  In fact, there is code documentation in that most of the code is well-commented and well-labelled (in terms of variables, field names, etc).  You have the output in front of you and the code ready to examine.  That is more than sufficient, particularly when you realize that the code changes (via improvements) often enough that it would be very time-consuming to write the documentation you are requesting while coding the new features and improvements.

In any case, that's the way it is.  Make your own contribution as you are able to.  You are more than welcome to.

As for assistance, as GauGau said, if someone who read this thread were able to assist, he/she would.  I personally cannot give any assistance off the top of my head.  If I had the time and inclination to do so, I would use the same tools I use for any coding - a good searching tool (I use WinGrep), a good text editor (I use CrimsonEditor), and a good database editor (I use phpMyAdmin).

As GauGau also implied, if you have patience, someone might assist you in the future.  You don't have to do everything yourself, but you shouldn't assume that someone else will be able to help you immediately.

Thank you for the quick reply, Paver.

I am looking in the code to get the output i am looking for, and as soon i get with some thing needfull i'll share the code, in case someone might need it too. Afterwards i'll try to make a data flow diagram of cpg, to help those who wants to how things work in CPG.

[Paver]

That's the spirit!   

I forgot to mention my mantra which is to create a plugin for what you want (instead of creating a hack/mod).  A plugin doesn't touch the core code and is so much easier to use.  The only drawback is that it's a little more difficult to code - actually, it's not more difficult, it just requires a more flexible mind to see how your job can be done using a plugin hook instead of just brute-force changing the code at the place of impact.

In this case, you might be able to merely modify a theme function/variable which is just as good as a plugin since it doesn't affect the core scripts.

My suggestion is to look at the way tags are handled in theme variables (like {STATS}) and create a new set of tags {CUSTOM_FIELD1}, etc. in the appropriate theme variable, then write the code to process these new tags in the appropriate theme function.  That way, any one can write the theme variable how they like (moving the data tags around and wrapping them with table cells, etc), then use your theme function as is to process those tags.

In this case, you could share your code as a theme contribution, like classic_filmstrip_vert which provides a vertical filmstrip.

[Paver]

As for the actual data, my without-looking-at-it guess is that the data you want will not be available directly to the function you want to parse those tags from the appropriate template_ variable.  (This guess comes from my recollection of the file info tags from writing my Display Fields plugin, which allows you to show/hide the file info fields.)  If that's true, I would suggest grabbing the data directly from the database tables.  You can search for the  custom fields field names to see how Coppermine currently does this, although it may be hidden in a SELECT * call, but I think those field names might be mentioned because if they are blank, they are not shown, although they might also not be mentioned if the file info fields are routinely checked for being blank with no special condition for the custom fields.  (Yes, I realize this last sentence was a crazy run-on sentence.  If only I had the skills of Garcia Marquez.)  In any case, the query should be fairly simple as long as the picture ID is available to your function.  If it's not, then more work will be required to figure out how to get it.

As you can see, it might be a simple answer or it might not be.  I just don't have time now to do more than give thoughts without looking (because I know how easy it is for me to get side-tracked for long stretches of time by just "looking").

If you have specific questions once you assess things, give a holler (in this thread).