Could we add php evaluated code box as option for all actions' numbers and values ? That would allow for creation of truly dynamic images such as widgets. Examples: weather showing widget, profile stats widget etc etc. AFAIK dynamic option currently exist only for text overlay. More power to Drupal!

CommentFileSizeAuthor
#7 imagecache_customaction.module.txt2.89 KBcrea

Comments

dman’s picture

dman commented

That's crazy talk.
Imagecache is not structured to handle changing data. It's a cache, not a generator (this bonus image manip is really a scope extension). It's not expected to - and not going to - make time-or-data-sensitive images. The pipeline that invokes it is all wrong for on-demand images.

That COULD be a totally different, and useful project. banner.module or signwriter.module have similar jobs. They could even be extended to use a common set of actions like imagecache has - or at least imageapi! So it's not impossible, may be good. But it won't be imagecache.

A GOOD idea however is to have evaluated code. Not around all existing actions (me-ssy) but as an action itself. I was thinking of that a while ago. Just have arbitrary code as one of the actions.
Given the action parameters (filename, presetname, script) the script can run any coded php-gd process it likes. The actual action routines are generally only 5 lines long, so that's do-able in a textarea.

crea’s picture

crea commented

Do you mean better architectural solution would be some other module updating images before they get cached by imagecache ? Probably yes, but at the moment imagecache has all the stuff to make this available: api to create and flush derivatives cache and existing set of image manipulations. And if imagecache was pure cache, actions with so rich features wouldn't exist. Maybe it can be done with some api instead of evaluated box. But I dont see any special problem about passing dynamic values to actions...Custom module using api could pass these values and control caching with api (flushing and such).

Isn't it just a matter of manament where to do manipulation, in imagecache action or another module ? In a separate module you would need caching anyway...and think of it, you probably will need different image manipulations for different image sizes (derivatives) so you eventually will come to duplication of imagecache functionality in your separate module...or do you think its better to write own generator module and make different imagefield for each derivative ?

Well, I'll look at existing api asap anyway. If everything is so simple as you say (several lines of code) than custom coded action could solve this need too..

dman’s picture

dman commented

And if imagecache was pure cache, actions with so rich features wouldn't exist.

Well, I wrote them, so I know what they are for.

Simply, the name, direction and purpose of imagecache is to avoid making images on the fly. Otherwise it would just be a runtime image generator, but it works in the exact opposite end of the pipeline from that.
Abusing the "flush derivatives" feature is bad mojo. Image generation can easily be very intensive on any medium site - I'm running one where if I flushed all my imagecache-watermarked images, it would take like 4 hours running the CPU hot and a very patient webspider to rebuild them all.

This (Potential Denial-Of-Service) was also a reason why live captions didn't go into imagecache a while ago. There IS a problem with passing dynamic variables on a public site.

Imagecache works by allowing Apache to serve the image that is there, and only then asking the script if it can please replace it if missing. This is much more efficient in all use-cases imagecache is intended for.
Running a full Drupal bootstrap to gen an image each request (even if it turns out to be cached) is much more inefficient.

BUT. If you want to do so, It's quite possible for an on-demand generator module to gather and use all the imageapi, or even imagecache_actions actions using the available hooks, and serve its own, on-demand pipeline. It can be 1/3 the size of imagecache, and be re-using all the forms and actions. Extending signwriter.module or similar to allow imagecache_actions processes would be a desirable thing.
Runtime image generators are fine, and cool. But potentially inefficient when running inside the Drupal framework. Much better as a call-alone script.
It's just got to be a companion to imagecache, not an update to it.

crea’s picture

crea commented

No no no! You dont understand me. I'm not asking to make imagecache runtime generator. Ofcourse that would be stupid and would kill the purpose of caching. I'm talking about passing info to imagecache action not for constant rebuilding! Images would be still cached, flushing logic would be controlled in separate module. And separate module can KNOW when information used by imagecache is changed ( to be more clear, when we WANT it to change on our images). So caching would still work as fine as before. And why you talk about potential DOS attack like we forced to flush all images at once ? We can flush single images or single presets, and they will be rebuild on demand, not at the time you flush them. So these 4 hours of CPU would be spread over many real time hours and there would be minimal possibility of DOS attack. ( well, CPU and general web host load is different issue, you can always add more hardware depending on your setup)

If you have weather displaying widget for some city, and you get updated weather information twice a day, you only need to flush twice a day single image, not all weather widgets or all city widgets. And if noone will request that widget from your host, image will be never generated at all.

Well, I understand its not very efficient to run full Drupal bootstrap but that way you have full and easy access to its DB. If you had separate script you would need to access DB anyway to get info. You would also need to duplicate logic and lots of SQL in your script. And also your script wouldn't be so flexible - every time you need to change information you would need to reprogram your script logic ( isn't CMS about not writing your SQL manually each time ? :) ). If I want to display complex profile information in my widget, with Drupal its easy.
So there are always tradeoffs, the tradeoff to CPU load would be lots of developer working hours, which are more costly by default, unless you have your own cell with monkey developers, ofcourse :)

dman’s picture

dman commented

Imagecache does not (currently) support per-image refresh. At the moment, it's all-or-nothing. It's possible, and, in a different context, even a good thing - can be built.
I'm encouraging a separate module (Especially if it can re-use our existing filters). Just trying to discourage scope creep on this that does one thing consistently and efficiently.
A weather image update is neccessarily time-sensitive, therefore a different use-case. It's good, a nice idea, but needs a different approach.
The Drupal bootstrap CAN be simplified, and may work. Please give it a go. Re-using the presets would be cool.

crea’s picture

crea commented

Imagecache does not (currently) support per-image refresh.

If I understand it correctly, function imagecache_image_flush($path) flushes all derivatives of single image. In most cases it is enough. Even more, I think it can be easily modified to flush single preset of single image.

About different approach to image generating: I'm not experienced drupal developer and there is minimal possibility of me doing it. However, for my project I think I will just make custom action with dynamic values ( adding several lines of code is not a problem for me :) ). When I opened this issue, I was hoping that someone experienced enough could make it :)

crea’s picture

crea commented
Title: Make actions dynamic » Custom action support - first step to dynamic actions
Status: Active » Needs review
StatusFileSize
new imagecache_customaction.module.txt2.89 KB

I did what you suggested originally - pls see attached draft

Although, I want to state, its usage requires of knowing ImageAPI and is strictly speaking not what I'm talking about in this issue. Perhaps proper module is matter of some api and better UI. Good example is Views module - it doesnt require you to know any API or php to use. So ideally reusing existing actions (passing variables) shouldn't require you to reprogram them, copy code, and such...

dman’s picture

dman commented

That's perfect!
I'll try it out and roll it in to imagecache_actions soon.
Thanks!

dman’s picture

dman commented
Status: Needs review » Patch (to be ported)

I've put a modified version of that into the 6-1--2 release :) With a sample bit of code.
I think it can be coped back to D5 also if anyone wants it. There's nothing different between versions.
Cheers!

asak’s picture

asak commented

subscribing (for the D5 version of this magic!)

(I'll give it a try and see how it goes anyway)

erik seifert’s picture

erik seifert commented

Hmm,

Let me have a comment on this thread.

What can be the second step to make a dynamic action ?

- You must provide Data to an action
- You must a special identifier for image + data context

So i think everything is here. We need only a special path for inserting data and provide it to an action.

I think it could be so:

/imagecache/NID-1|TEXT-HELLO/path/to/image/file/file.jpg

This solution would go hand in hand with imagecache and drupal.

To avoid manipulation, you could use something like

/imagecache/CONTEXT_AS_SALTEN_STRING/path/to/image/file/file.jpg

So it could be easy handle custom code in action:


....
$nid = node_load($context->nid) ;
...
crea’s picture

crea commented
Version: 5.x-2.2 » 5.x-3.x-dev

Any ideas how to make it work with Imagecache Actions 5.x-3.x-dev ?
I don't see my action in actions list even after clearing cache
UPD: I had to rename function imagecache_customaction_actions() to imagecache_customaction_imagecache_actions() to fix it

dman’s picture

dman commented
Status: Patch (to be ported) » Fixed

I'm pretty sure this has got to where it was going.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.