HI. I'm using this path for my images - images/[current-date:custom:Y-m]/[node:nid]-[node:title] and after update node title, path to the file don't change (it got old node title in it).

I don't know it's more file sources or token related, so feel free to move it/delete it.

Solution for now is to not use [node:title] in path - so path should look like images/[current-date:custom:Y-m]/[node:nid]

Comments

deciphered’s picture

Status: Active » Postponed (maintainer needs more info)

Can you test with the latest dev version (available within the next 12 hours) and let me know if the issue still exists as I've been unable to reproduce it.

Cheers,
Deciphered.

batigol’s picture

Sure I try to spare some free time :)

batigol’s picture

This bug is still active.

When you use [node:title] in path to the image, then edit a node and change it title, path to the image (catalog) won't be updated. You can simply get lost in trying to find proper folder, and you don't find it cause it doesn't exist.

deciphered’s picture

Ok,

So I guess what I glossed over was the 'update' part. Have you got 'Active updating' turned on in the FileField Paths settings? If not, then it wouldn't update.

batigol’s picture

Oh, now when you edit the node and save it again - path to the file is changed. I'm gona try this only with FireFox cause Opera sometimes actually don't(!) save node. Also the folder with old node title is properly deleted. Files in database are properly upgraded with new path (no table. You have removed lowercase letters option (Transliterate and Pathauto are the only available).

Tested with - filefield_paths-7.x-1.0-beta3

It seems that [node:title] is working correct. THX for your efforts!

I'm using Colorbox with image background and my background disappear after upgrade to beta3 so I'm gona test it a little bit more - but I don't know its filefield paths related.

EDIT: I simply forget copy my colorbox-insert-image.tpl.php after upgrade drupal to 7.12 everything works fine.

I have also noticed that there is no more filefield_paths table with beta3. Instead we got column in file_managed origname Original name of the file with no path components. Used by the filefield_paths module. Yea, I like it :P

EDIT2:

Sometimes I got this error:

Strict warning: Only variables should be passed by reference in filefield_paths_filefield_paths_process_file() (line 66 of C:\xampp\htdocs\drupal\sites\all\modules\filefield_paths\modules\filefield_paths.inc).

Also with Active updating - when u edit node in English - it's save as node 101, now when u edit the same node in German language it's saves as 102 (it's correct cause different languages are saved as a new node) but it copy all images from 101 to 102 and u can't properly see node 101 as a user.

When a node is a translation, it should COPY images to new folder only.

deciphered’s picture

Status: Postponed (maintainer needs more info) » Fixed

Hi batigol,

Yes the latest update is quite a significant restructure, blowing away the custom database table and only using the field instance for storage simplifies exportability and reduces a lot of the unnecessary complexity of the module. On the downside it means that the module will only be able to easily support Field based integrations, but to be perfectly honest, I'm not really interested in supporting modules that are rolling there own approach to file management.

The 'origname' column has been part of FFP for quite some time as it's an essential way of being able to undo any negatively affecting renames.

I'm glad your initial issue has been resolved, that's very good to hear. Your second issue (the passed by reference issue) should be resolved in the upcoming dev as a fix has been committed to 7.x-1.x.

As for the translation issue, I'm not entirely certain how to approach that, I don't think it's FFPs responsibility to copy the file, if anything that should/could possibly be handled by one of the many translation based modules. However what FFP should do I can't say for certain. Quite possibly I could include the 'Active updating' checkbox on the Entity itself so that it could be checked/unchecked as necessary.

I'll have a think about it. One thing is for certain, it should not be part of this issue as this issue is resolved. I'll open a new issue for it shortly.

Cheers,
Deciphered.

deciphered’s picture

Status: Fixed » Closed (fixed)

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

Anonymous’s picture

Issue summary: View changes

edit