Any hints on how to do this?
The Taxonomy logic can be lifted from here (in the comments)
http://drupal.org/node/64135
http://drupal.org/node/69076
So in short how can I make it Overlay some text based on a True; or nothing if False.
Any hints on how to do this?
The Taxonomy logic can be lifted from here (in the comments)
http://drupal.org/node/64135
http://drupal.org/node/69076
So in short how can I make it Overlay some text based on a True; or nothing if False.
Comments
Comment #1
mikeytown2 commentedK so the text module can eval php... anyway here is my test code.
Comment #2
mikeytown2 commentedHow can I get the node that is associated with the pic? Arg() returns the path to the jpg not the node.
Comment #3
mikeytown2 commentedGoing to mess around with
But I think it only would work if your viewing that pic on that node. doing it in a View would mess up the image generation most likely.
Another idea would be to search the DB. Any hints on what tables to search in to get a 1 to 1 match (using filename)?
$_SERVER['REQUEST_URI'];should give me the filename.Comment #4
dman commentedYou are looking in the right places, but have a look at the existing source of imagecache_actions/textactions.inc ...
inside textactions_evaluate_text() the filepath is already available for use in your custom code - as $caption->path or $image->filepath.
$node should already be available if you were using image.module. This is a prime use of this facility, so that function was built-in. (although maybe not well documented)
And the same could be made available if someone was able to repair the imagefield version.
Comment #5
mikeytown2 commented$node doesn't work 100% of the time.
Been looking at the Drupal DB and this is what I think will work...
Get file name via REQUEST_URI
Search files table for that name
Grab fid from the query. $fid
Search CCK field for that fid (any way to search all cck imagefields?)
grab nid from the query. $nid
We now have the node ID. Time to party.
Comment #6
mikeytown2 commentedHere's the query for all the image fields
grab field_name
Comment #7
dman commentedYes, $node is not yet supported FOR IMAGEFIELDS. I think I documented that a few times.
It's currently working with image.module only. See above.
That code you've got there is probably half of the bit we need to re-enable imagefield support - although we still need the magic that will detect the image field name. That's the bit that got tricky between D5 and D6 and was disabled.
You will see that the above textactions_node_from_filepath($filepath) function already has the original file filepath, so no REQUEST_URI hacking there needed.
Comment #8
mikeytown2 commentedhere's my guess at it... doesn't work but should be close. Maybe u can help me
I think the problem is the last WHERE sql command.
EDIT: FIXED some dumb errors
Comment #9
dman commentedIt's doing the right thing (by sight) yep...
But I feel there must be some better API calls to - eg - cck_get_all_field_names()
I simply haven't had the dedication to delve into the latest CCK API code to find the bits we need. Yet direct DB queries like this are also to be avoided. Especially for something as deep as CCK.
... which is why I've been avoiding it altogether!
RE the above code, I don't know if it's even possible to select from multiple tables like that on the fly.
Lazy way, but me, I'd probably loop on the tables and make multiple queries. Not good code, but at least understandable.
The code above will certainly have problems - although I can't debug it right now.
Comment #10
mikeytown2 commentedPlace inside "Text:" Text Area Field and set "Evaluate text as PHP code" to TRUE.
If someone wants to fix the SQL statements so they are safe, that would be nice
@dman How can I access $filepath? variable is empty in the scope of the text eval.
Comment #11
mikeytown2 commentedgot the base name of the image & fixed some of the SQL so it more secure
I think this is the best I can do, without some sort of real access to the referring node.
Comment #12
mikeytown2 commentedGot This
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1 query: SELECT vid, nid, field_image_additional_fid AS fid, field_image_additional_list AS list, field_image_additional_data AS data FROM content_field_image_additional WHERE field_image_additional_fid = in .../includes/common.inc(1648) : eval()'d code on line 38.
It has to do with my for loop. <= should be <
Line 18
Comment #13
dman commentedOK.
Your efforts have prompted me to visit this and work it (or something based on it) into our text evaluator...
You showed it could be done, and provided enough of the groundwork. I then refactored the code a few times:
- placed the content-type loop outside the fid loop
- munged the SQL back down into just what we needed
- munged the lookup further to scan for multiple fid matches (unlikely maybe impossible , but whatever) in one query
- saw that filefield supports image 'description' next to the field so added support for that TOO.
- added support for upload.module and filefield.module while I was there.
Yeah, all good.
I'll roll it into dev.
Comment #14
mikeytown2 commentedSweet, I'm glad I inspired you.
I've created and destroyed the same node with the same pics a couple of times, and the data was still in the DB from it. Thus I got multiple matches, with only one "live" one; so it is necessary. I spent some time figuring that one out.
Comment #15
dman commentedHm.
That (in the first case) sounds like we really SHOULD be paying attention to the node VERSION id, not just the nid.
Really should. I saw the column, but I just didn't want to think about it right then.
Me, I was hoping that the file-attachment utils will get with the program and start to support re-use of existing images where possible. That makes THIS job harder, but (IMO) website management easier/better.
Comment #16
mikeytown2 commentedI should say the same node content, but it ended up having different node id's due to multiple deletions/creations. Versions/Revisions is something I never considered.
Comment #17
dman commentedI'll tenatively call this 'fixed'
it's in 6.x-1.2
Comment #18
asak commentedSo.. should this method now work with an image overlay as well? or just a text overlay?
(continuing my thoughts from http://drupal.org/node/323455#comment-1218756)
Nice work !
Comment #19
mikeytown2 commentedsome code that is related to this:
http://drupal.org/node/374202
Set the action via rules... edit a page auto regenerate images.
Comment #21
dman commentedJust using this old issue to publish a new image for the docs.
- I added a howto recipe of text-from-image possibilities Into the docs just now.
Comment #22
ccshannon commentedDoes this mean if I have imagefield/filefield images displaying on a home or section page (so there are many imagecache images from various nodes on one page) and the text overlay action calls 'return $node->title;' it _should_ get the title of the node the image is from?
What I'm getting is all the images are getting the same node title from one node ... the newest node on the site. It's not even a node displayed on the same page as the images.
So, all the nodes get the same information. If I'm misunderstanding what the update covers (using 6.x-1.5) then maybe I should delve into mikeytown2's code to retrieve nid for fid?
Thanks for all the work on this, btw.
Comment #23
dman commentedIt certainly SHOULD be using the info relative to the image itself.
Not sure how many images could get one title, unless it was like node #0 and they were retrieving blanks or something (cannot happen)
Yes, the problem must be in the lookup that traces image-path to nid. It's a little heuristic at the moment,
have a look.
Comment #24
ccshannon commentedUpon further view, it's not the imagefield/filefield.
I have a homepage template that loads nodes via a number of nodereference fields stored in the homepage 'node'.
The template runs theme('imagecache' ....) on each image path from the loaded ref nodes. Some images receive a larger scale preset than others, depending on their placement in the page.
I added a "dpm($file_data)" (have dev module installed) to the PHP block for one of the presets and I expected to get a message for each image (in this case 10 images) but only got one and it was an object class, no data.
Tried again with dpm($image) and got one msg again: the image object for the sample image back in the Preset settings.
I wonder if I could pass the data I need to use (a short string stored in the referenced node) into the theme function for the img tag.
For instance, how would I extract the image's alt text for overlay?
Anyway, it appears to be the way I am calling imagecache from the template.
Comment #25
dman commentedum ... ah?
Well that pipeline sounds like the sort of madness I'd build for myself, so it makes sense.
I'm thinking you are calling it too late however.
In short -
imagecache gets a request for a image to process. All it knows is the name of the requested file and the preset definitions.
Imagecache_actions gets that info and does its best to look at the database and figure out who 'owns' the file and return the associated node data.
Only *most* files have database entries to use. I may be wrong, but it sounds like the process is running on already-cooked files?
Already-processed imagecache files don't really exist in the DB. You'll have to pass in the actual uploaded img filename, not the already-processed derivative.
template runs theme('imagecache' ....) on each image path from the loaded ref nodes
That path may already be cooked. Which means I can't find the owner.
That said, the way I look at the database to guess the owner is highly dependant on CCKs database schema. There just was no good way to get from 'image' to 'owner'. That heuristic may need work. I could only model it on what appeared to work from introspection of the tables themselves.
A heuristic to guess the source of already-cooked file paths may be possible ... but it starting to get really out there.
Comment #26
rickh commentedHey guys, I know this is a very old post. But i've been looking around for hours and I can't finds anything. What i want is if a user select "sold" on the edit page in a cck select box, it overlays an image on top of all pictures associuated with that node, whether it's in views or on the node itself. Any ideas?