I've created a few imagecache presets - lets say "width-200", "width-300" and so on.. Then added filefield image to my content type. Set unlimited number of values. Allowed Insert module for this CCK field, checked some of the imagecache presets. Now when creating new node, the field displays, Insert module shows allowed presets, inserts the img tag in the textarea as it should be - like

<img class="imagecache-width-200px" title="" alt="" src="http://domain.com/sites/default/files/imagecache/width-200px/100_0889.JPG"/>

But the problem is that the preset is not generated yet - the image on this url doesn't exist. I don't display the image anywhere else (the CCK field is set to be hidden - NOT excluded in display fields option), so I think the theme('imagecache',....) isn't run, so the derivates aren't created.

Comments

bydga’s picture

Status: Active » Fixed

sry my bad. It seems like theres some error in the server configuration.

bydga’s picture

Title: Inserting imagecache presets doesn't work » Inserting imagecache presets doesn't work in cooperation with filefield_paths module
Status: Fixed » Active

A'right, I finally found out what was going on. The problem is with module filefield_paths. The Insert module doesn't respect whether the path (or even the file name transliterated) is changed by filefield_paths module and creates the img tag as the image was in sites/default/files.

gooddesignusa’s picture

would love for this module to work with filefield_paths and imagefield_tokens
subscribing

legion80’s picture

i'm running into the same problem. rewriting the file path used to work for me before, but it might be because i was using the old filefield_insert module. going to try it with that instead and see if it fixes it.

my use case: allow users to upload images and then embed into the body of a node. using a combo of filefield_paths, filefield_sources, and insert modules.

subscribing.

legion80’s picture

Actually so it's a non-issue for me-- I just never did a full test. I was just uploading, but never saving the node. I didn't realize that the files don't get moved until after the hook_nodeapi() method gets called, which occurs when you save the node.

deciphered’s picture

Hi guys,

Might me best to to move this issue to FileField Paths, but before I do that can you confirm what version of FileField Paths you are running so that I can confirm whether this is an issue? I suspect that this issue was fixed a while back in the development release, which is long overdue to become a new stable release.

Let me know.

Cheers,
Deciphered.

Igal’s picture

I am using filefield path 1.3, insert 1.0-beta2 and have the same problem.
I get from insert button the following code

<img src="http://mysite.com/sites/default/files/imagecache/max200/image.jpg" alt="" title="" class="imagecache-max200" />

the correct code should be:

<img src="http://mysite.com/sites/default/files/imagecache/max200/PATH/NID-image.jpg" alt="" title="" class="imagecache-max200" />

Where PATH is "File path:" defined in filefield path and NID is token added in filename field of filefield path ([nid]-[filefield-onlyname-original].[filefield-extension-original])

deciphered’s picture

Project: Insert » File (Field) Paths
Version: 6.x-1.0-beta2 » 6.x-1.3

If this is before you save the node, that's expected behaviour, FileField Paths doesn't move/rename the file until you save the node and that includes correcting of the URL that Insert inserted.

If the URL is still wrong after you save the node, then try the latest development version of FileField Paths which has vastly improved the replacement pattern for correcting old URLs in the Node body and CCK Text fields.

Let me know how you go.

Cheers,
Deciphered.

Igal’s picture

With latest development version the behavior is as you described. The image path before node save shown in body text without ImageField Path elements and after save the path changed automatically.

Thanks

deciphered’s picture

Version: 6.x-1.3 » 6.x-1.x-dev
Status: Active » Fixed

Good to hear.

Status: Fixed » Closed (fixed)

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