Update Imagine usage

[Guite]

Review thumbnail generation possibilities in the updated Imagine system plugin.

https://github.com/zikula/core/tree/1.3/src/plugins/Imagine

@jusuff

[jusuff]

If something would be not clear enough - let me know. Will be happy to help.

[Guite]

Hi Jusuff,

some questions:

1. NOTICE: it is recommended to use only one of these methods (generating thumbs in template or PHP code). Any specific reason for that?
2. The object id may be alphanumeric, right? So it is possible to inject the object type into it (for example in Dizkus something like objectid='post/4' or objectid='topic-7' ?
3. I see the following requirements:
   • plugin must be installed (PluginUtil::getState('Imagine') == PluginUtil::ENABLED)
   • directory specified in the default preset (or the used one) must exist Did I forget anything? Any idea how to react if something is not correct? I dislike falling back to the old behaviour (using Imagine directly in the module) as I like the approach of having the common facade you introduced.
4. Wondering how to specify which preset should be used by a generated module. I think of using the default preset per default but generate an entrypoint for allowing the module developer changing it easily - ideally independently for each object type or better first for each object type and second for each single upload field. Do you agree with this approach?
5. Documentation says: Custom module preset should be stored inside module (presets are serializable). Would a modvar be appropriate for that?

[jusuff]

Ad 1. This notice is caused by the thumb generation method. When thumb is requested, modification time of source image is checked and if this is different then timestamp in thumb name, then old thumb is deleted and new one is created. With new timestamp it means that file name is changed. So if you would request thumb in module code (calling manager "getThumb" method) it may regenerate thumbnail. If you would also use smarty "thumb" tag in template to get the same thumbnail, it is possible to get cached template with outdated path. This can be avoided when thumbnail request (manager->getThumb or smarty thumb plugin) is always used the same way. Of course this wont be an issue, when module properly check cache validity. But I preferred to warn.

Ad 2. Yes, object id can be alphanumeric. It can be simple int id (eg "123") or some string - "topic-7". Need to check how plugin would behave when object id contains slash ("post/7"). For modules which handle more then one object types, strings like "objectType-objectId" whould be the best.

Ad 3.

• Imagine plugin implements "Zikula_Plugin_AlwaysOnInterface" so you don't need to care about enabling it. It will always be enabled.
• I' not sure which directory you're asking about. Thumbs are stored in dir which contains: $baseDir/$moduleDir/$objectDir/$imageDir All of this path parts are auto-created, except first one. If you want specify $baseDir (which by default is ztemp/systemplugin.imagine) you have to take care about it and make sure it exists.

Ad 4. If you would like to give user choice about presets - this way (defining presets for object types and object image fields) is absolutely correct.

Ad 5. Modvars are good choice - I used them for storing Imagine own presets.

[Guite]

Thank you!

Ad 3.: I am talking about $baseDir not being autocreated. So a module can not assume that the ztemp/systemplugin.imagine directory is existing?

[jusuff]

No - module can assume that ztemp/systemplugin.imagine exists. It's checked on plugin initialisation, so it will always exists (it's mostly done due to required htaccess file which allows access to images under this dir).

But when you want to set other base directory in module (for example ztemp/FooModule/thumbs) you have to take care about this dir and ensure it's existence. Imagine Manager wont accept non-existing directory and use default one instead.

[Guite]

I still have some problems with question 1. There are Pro's and Con's for both controller layer and view template approaches.

aspect 1: to keep things consistent and concise I tend to doing things in PHP and just assign the thumbnail pathes to the templates (controller 1 : 0 view) aspect 2: for different use cases the generated modules could define different presets (controller 2 : 0 view); module developers could then adjust this by overriding the corresponding helper class aspect 3: this would make it more difficult to module users to customise things as there would be no way to edit the presets (controller 2 : 1 view); thus for them it could be better to control stuff in the templates aspect 4: also introducing a thumbnail in another template would require adapting/enhancing the controller (controller 2 : 2 view)

I tend to implementing it in the PHP layers, but I am really not sure yet. what do you recommend?

[Guite]

Talked with different people: we choose the view plugin for easier customisability.

[jusuff]

In my opinion thumbnails are part of presentation layer so it's better to handle them in templates by smarty plugin. This is how I'm going to use Imagine. Controller layer may be required for managing presets or implementing more advanced image manipulations (for example - cropping images like it is done in SimpleMedia). But final thumb generation fits better to view layer (et least in my opinion).

[Guite]

Going to implement a combined solution:

• A dedicated util class provides different presets for several use cases (view pages, display pages, and so on).
• Also this class provides an entry point for the module developer to override or customise the presets. Parameters will be the object type, the field name and the context (controller, api, function, etc.)
• The module user (site admin) can further customise this by overriding templates and using own presets where desired.
• In special cases the user can also use inline options instead.

[Guite]

Implemented in a03fb5b2a763377b1ad55e385096e1cb511ebe1d