Add token support for image file directory and image names

I support this as an configuration option.

+1 : I fully agree, either optional or permanent.

I find this feature is very important when you want to update pictures side wide. I use image module in combination with image_insert en tinymce and images end up all over a site and it is hard to keep track where you used it.

At the moment when you update a image node you have to be very careful that the file name you upload is exactly the same as the former, otherwise your site ends up with a whole bunch of broken links all over your site where you used that image. In fact I don't know if this will work, if the module will add a number at the end when you update.

With image files renamed to node number, the renamed filename will always stays the same, no matter what you upload to update an image.

Or how about another option to prefix the node number? 23_img_3498.jpg or 24_funnycat.jpg or 25_iminurbase.jpg so you still have some sense of what's in the photo if you're browsing the directory manually or taking a backup?

Imagine you have a photo collection that has been inserted in many articles all over your site. Imagine you found a better photo and want to replace an existing one. You go to the image node upload the new photo. Then with your idea you still have the problem that the image filename changes. This would cause all references to this node's image to break and you would need to go through your whole site to find where you used the photo.

That's why I prefer that the image filename equals the nodenumber. Then when you update an image node, you don't need to change anything in your site, because the name of the image file will not change with the new upload it will be updated automatically all over the site without breaking anything.

The only other way is when at inserting images you insert php code that would generate the right image filename, but this slows down page generation and likely asks for larger changes in the code as TinyMCE is only made for HTML editing and it would break code with PHP insertion.

This specific request is only one of many possible ways you may want to organise your site. I think the replacement photo is a bit of an extreme example and would really cause more troubles than not, but ...

I hacked in something similar this week - using user-defined tokens to invent the filename (of the derivatives at least, I chose to leave the original alone, but it could be done too)

So there's a user option to set
'filename pattern' to
%user/%nid-%filename.%suffix
for
arnold/7-mycat.jpg

or
uploaded-images/%type/%filename-%date.%suffix
for
uploaded-images/thumbnail/mycat-2007-03-27.jpg

etc. I'll post the code when I get home later. Needs a little work, but it allowed me to but the 'thumbnail' and 'preview' into a subdirectory away from my real images.

I simply detest file upload systems that discard my filename. It's often the only bit of useful metadata attached to the thing.

So here's the tokenized filepath renamer.
Current available vars are

+    $tokens = array(
+      '%filespath'=>$path,
+      '%nodepath'=>$node->path ? $node->path : $path,
+      '%filename'=>substr($filename, 0, strpos($filename, '.')), 
+      '%type'=>$type,
+      '%extension'=>substr($filename, $pos+1),
+      '%nid'=>$node->nid,
+      '%uid'=>$node->uid,
+    );

a few more may be useful. filesafe version of the full node title for one.

In summary, This patch
- adds an option to the configuration screen (and quite a bit of description and examples)
- When building derivatives, passes axtra context info to the _image_filename - which constructs the new image path from the given pattern.

There will be a few problems with this first attempt, I'm sure. As above, it does NOT mutilate the 'original' file at all, just the derivatives.

Responses?

the token module might be of interest to you. i doubt it'd be work introducing a dependency but it does some similar stuff.

i like the idea but i'm not sure about the approach. here are a few comments i had reading over the patch:

• i don't think PHP4 will allow $node = array() as a function's default parameter.
• comments like:
  

  // modified by dman to allow for advanced filename generation patterns
  // and subdirectories for storage
  

  are not very useful.

• you need to be more consistent in your use of whitespace. please review the drupal coding standards
• i have some reservations about the mkdirs() function you've created. at the very least it should be image_mkdirs() so that it doesn't conflict with another funciton. it's a really bad idea to assume the operation of a function just based on its name.

Yeah, as noted, this is just something I did for a requirement on a project this week - posted here as an FYI to illustrate a possible approach, not as a proposed Drupal patch yet. This is from live code, I still need those comments to let other developers I'm working with know that the project is no longer unmodified Drupal core.

I don't think I've ever encountered problems with array() as a default param before, I'm sure I've done it on PHP4 . I'll have to check.

I was expecting to find a mkdirs function already available in file.inc or something. Instead I just pasted in a version from a standard library. I'm annoyed that there seem to be a bunch of duplicate {module}_clean_id() or {module}_safe_filename() functions floating around because form_clean_id() wasn't good enough. I didn't want to add another variation for a similarly basic, re-usable func.

However, this code needs work, for sure. But beyond the whitespace and comment wording, is it worth polishing up?

like i said, i like the idea but with something like this it's all about the details. i hear what you're saying about working code. please keep refining it.

you might want to look at the patch i've got on #131589 it seems like it makes some similar changes to the filename generation (i was trying to get the paths to generate names of duplicate files correctly). again this is something i'd like to see committed because it would solve a few open issues, it just needs to be done very carefully.

also marked http://drupal.org/node/131932 as a duplicate

marked http://drupal.org/node/124763 as a duplicate of this

marked http://drupal.org/node/72685 as a duplicate (even though it's older than this).

I am commenting mainly to show support for this patch, and try to get it bumped up in the priority list. I am working on a site that will have hundreds of images, and I would love to have the ability to structure them in some sort of logical manner. I would prefer the directories be based on the gallery names, as is common with most major stand alone galleries.

I honestly have no idea what I can do to help, as my PHP skills aren't what they used to be. But I am certainly willing to do what I can to get this issue moved along.

i agree that using the gallery (really a taxonomy) is a bad idea. it adds a dependency on another module and can change too frequently.

Anyone ever hear of URL Aliases? PathAuto will even alias your images any way you want.

Frankly, if you want to use a node number to rename it, why not also add the user's ID who submitted the picture (so you know who to blame)?

nancyw, that's a good point thought it worth distinguishing between aliasing image nodes and providing paths to image files. user id would be a good addition to the tokens used for naming files.

I've already nominated user id (uid) as one of the tokens that should be available.
Although the objections about a gallery not being a core property of an image are valid, if we can find a way to include tagged user terms (which include 'galleries') in a rational way, it is right to give the admin the OPTION to do so. It's a valid chioce, and the admin should have the ability to define their own file storage patterns.

To solve the general case, we need a token that will be replaced with the taxonomy term of choice.
So if you have a Gallery vocab containing [kittens,puppies,goldfish]
you can nominate that images get saved in the path
files/images/%gallery/%uid/
and end up with
files/images/puppies/7/cutie.jpg

... yes there are issues with unclassified images (fixable) and with multiple taxonomies (first valid term?) but it's do-able.
However I don't know how to handle re-tagging of already uploaded and classified files. This would require a bit of housekeeping.

For my site, taxonomy makes the most sense, but I understand that other folks wouldn't use it that way. The best bet is what dman said, to allow the admin the option to structure it any way they choose, based on tokens.

Has there been any thought with using the Token module API? It seems like a pretty reliable module in terms of staying updated, and it seems that - from what I have seen - it is part of most people's post-core-install install package.

marked http://drupal.org/node/151372 as a duplicate

marked http://drupal.org/node/147668 as a duplicate

I think this could be a base for another patch: allow to use more levels in files/ directory. (the same as Postfix or Squid does it):

A/A123.jpg
B/B123.jpg
C/C123.jpg

This could be very important for large sites with thousands of images. Browsing them using SSH is then a big pain

meba: The subdirectory thing is a much wished-for feature for image, at least for those of us who have a couple thousand pictures.
Here's one such issue: http://drupal.org/node/72685
Here's a workaround: http://drupal.org/node/151733 (comment 12)

marked http://drupal.org/node/193285 as a duplicate

Here's a re-roll against the recent changes.
I removed the array(), renamed the mkdirs, stripped the comments, checked the syntax,
and ensured that the upgrade - from the 'images' directory method should be smooth. The 'images' dir setting is now redundant, as we have more control ... but you can keep using it as a convention.

There should be no trouble starting to use this alongside images named the old way.

Some of the implications of using generated tokens in filenames are yet to be tested, for example if you mutilate the original filename, the derivatives then mutilate that further, which may produce interesting results.

More tokens (like gallery tags discussed above) can be added as we go. I've not needed the token.module, as it's only a few lines of replacement.
Dates and initial letters (as requested) can be added also, once this phase is tested and in.

For the CVS-impaired, here's the patched file also (also containing two other bugfixes)

Hi!

Can someone help me to use the "Image import" with the last patch from dman ? I've got 30.000 pictures on my website and i need a structure... How can i do that?

EggL, it's bad form to change the title like that...

dman, glad you've taken this on. I didn't have time to actually test it out but here's some thoughts I had just reading it over.

The comment on _image_default_filename_pattern() doesn't make much sense...

Why is image_view() taking $node by reference?

$tokens['%filename']=$filename; should have some spaces around the =.

image_mkdirs() needs better PHPDoc and doesn't look like it follows Drupal's coding standards...

What happens if I call _image_filename() with $node = NULL? it seems like it would break some stuff... If that's the case then the parameters and parameter order of _image_filename() should probably be revised.

[1]
I guess ...
The comment was about why that little call was declared rather than what it does. It looks trivial, but I found myself copying the same tricky string into multiple places (and then having to change it a few times) - so abstracted it.
I re-wrote into a more standard comment.
[2]
I really can't recall. It may have been left-over from one of my many other tests. I've mutilated the module several times now and merged many tweaks ... then last night managed to strip and split some of those changes into clean, independant patches. Anyway, removed as it looks wrong.
[3]
Fine. So much for my visual review ;-)
[4]
Worst that can happen with no node is that the filename pattern ends up with blanks in it.
Blanks then get immediately collapsed via the de-tokenizing regexp (in theory) to produce valid fallback filenames.

Intended behaviour (some experimentation needed):

  "images/%label/%nid-%filename.%extension"

... with a node input
=> "images/7-mycat.jpg"
=> "images/thumbnail/7-mycat.jpg"

... with no node input
=> "images/mycat.jpg"
=> "images/thumbnail/mycat.jpg"

You may see how
"images/{}/7-mycat.jpg" becomes "images/7-mycat.jpg" and
"images/thumbnail/{}-mycat.jpg" becomes "images/thumbnail/mycat.jpg"
(If my regexp works as intended)

I expect this behaviour may need a little more massaging as people really figure out what their naming requirements are.
--------------
Revised patch attached

@EGGL - No system can really insert structure where there is none. What naming conventions are your files you wish to import currently using? Is there anything there that can help.
This change is NOT intended to move and rename large amounts of legacy files that already exist within Drupal and are linked to from other places. That's a big messy job, so you may be out of luck there.
However, it should be able to work with image_import from file directories ... but WHAT extra structure or metadata do you have that we can leverage it on?

Not sure how that title went wrong - I think I posted in reply to the bad comment ... Whups

I had a thought that this approach may have a strange side-effect on the temp directory process.
This may need investigation, but I'm not really sure what the cron-cleaning the temp dir is all about anyway.
Just a thought...

I am not very good at this so what do I implement to image.module and how do I implement it?
Where do I set the settings so that I get a folderstructure like this:
/files/images/"galleryname"/"picture.ext"
/files/images/"galleryname"/thumbs/"picture.thumbs.ext"
/files/images/"galleryname"/resized/"picture.%size.ext"

anyone?

now I have nearly managed to do it as I outlined above, I am just missing to make a token out of the cathegoryname, how do I do that?

The procedure for category names is just not yet there or fully figured out.
- what happens when there are more than one tag?
- what if you want to use several vocabularies?
- - and filename-tag only from one?

It's do-able. just not yet done.

We need a good general-case solution (not just yours ;-)

I was thinking of using the vocab-name as the token to be replaced. That could work. Not sure how to handle multiples tho.
Anyone have ideas?

The way I look at it, people who would like to organize the files in folders by their cathegory is people who uses single-vocabularies and single-categories for their pictures.
People who runs multiple vocabs or cats would probably want to organize more by date.
So maybe what should be added is tokens for year, month and for those sites with heavy use also date?

but could I please be directed in how I should fetch the category name?
Assuming that it is just one relevant vocabulary and that images just can be added to one category within that vocabulary?

Dates are a good suggestion.

The very naive anser for you is something like:

  // Build filename according to token pattern.

  if (!empty($node->taxonomy)) {
    $term_obj = array_pop($node->taxonomy);
    $term = $term_obj['name'];
  }

  $tokens = array(
    '%nodepath'  => $node->path ? $node->path : 'node-'. $node->nid,
    '%term'  => $term ? $term : '',

Untested, off-the-top-of-my-head code etc. It's a starting point for you.
That'll just attempt to grab the first associated term from the node and slam its name into %term.

Needs docs, needs help added, needs to handle funny characters in terms, really needs to be more clever than just array_pop. Please improve on it.

(strange, where's codefilter gone?)

Codefilter: http://drupal.org/node/208636

Is there some designated areas where to put this code?

Yes.
Between the bits already there saying :

  // Build filename according to token pattern.

and

  $tokens = array(
    '%nodepath'  => $node->path ? $node->path : 'node-'. $node->nid,

c'mon, work with me here!

Damn, that term-code didnt work, thanks anyway

Using the patch it seems to me that the imported files doesn't seem to be assigned to categories during import, even though I check that during import. anyone experienced the same?

The best idea, from my point of view at least, is to allow the admin to create folders according to gallery name (or any name he/she wishes to give the folder). For example :

/files/images/gallery1/picture_etc.png
/files/images/gallery2/picture_blah.png
/files/images/cool_gallery/sub_cool1/another_pic.png
/files/images/yetanothergallery/silly_photo.png

Hopefully, that's a suitable example. The current setup is unworkable when you start loading hundreds, even thousands of pictures into a single folder. On that note, I would like to add my voice to those who want to see this as a feature, so much so that I would be willing to help fund its development. If a little money would help, I would appreciate hearing from whoever is in charge of this or this project to see if we can make this happen in relatively short order.

Thanks, and take care out there.

-- Marcel Gagné

marked http://drupal.org/node/193343 as duplicate
marked http://drupal.org/node/203019 as duplicate

Marked http://drupal.org/node/228237 as duplicate

I think we should grab the idea of importing directory trees "as is" from the /import/ folder into /images/ - that's absolutely stunning in its simplicity, and would work for everybody.

Hetta, your #47 suggestion is one of many ways to structure the images file folder/names.

As well as structuring according to taxonomy (galleries; cf comment #21 vs #17 and #16) or date tokens, many different ways should be offered for choosing the filename or the upload path.

• The source code of the uploadpath.module could be a good inspiration source for your developments, as it already uses tokens to set up custom file paths. (Watch out, this module is in dev, look for its patches as well).

Furthermore this way, integration or support of the uploadpath.module might be interesting.

About taxonomy/gallery folder imports, see #225014: Import images into corresponding sub-gallery, basing on folders tree.

• The auto_nodetitle.module may give some more hints on how to use tokens. As far as I remember, although it applies to the node title, it works automaticaly depending on nodetypes, I guess quite similarly to the pathauto.module (cf #18)

PS.: Finally, I would just like to stress out on the fact that keeping the image.module in a production environnement requires to be careful even with stable releases. That is why I think most users use one of the latest 5.x stable version and, because of that, I think that the current most-wanted features discussed here should as well be commited as such within 5.x stable versions.

Agreed.
My patches were always against D5. I can't see when it got changed.
This is working for me, but is such an important piece of surgery I just need other folk to actually test and review it, to see if I missed any assumptions or tricky filesystem issues.

It probably doesn't yet work with image_import as the file gets created before it gets tagged (I think) which leaves me SOL for coming up with a name. But image_import is trying to solve that itself, I believe.

Here's another update. A chunk of testing and I've got image galleries/taxonomy vocabs going to my satisfaction.
The previous version might not have been working at all in some cases - I found an order-of-operations sorta problem :)

This is getting fun. My images directory may even get organised eventually. Need to try out various peoples different preferred filename patterns and see how it shakes out.

Me, I'm going
images/%vocab-2/%label/%filename.%label.%extension
where vocab-2 is the primary term from my image galleries.

NOTE currently if you put your derivatives in a different folder from your original it'll break lightbox (and who knows what else) because of the way it guesses where the other images are. I've got a fix for it, but need to see what else breaks :)

Filename naming pattern:
Pattern to use when saving or creating derivatives (like thumbnails) for an image. Available tokens are: %nodepath, %filename, %filename_raw, %label, %extension, %nid, %uid, %date, %year, %month, %day, %vocab-2.

files/images/a-term/thumb/sample-filename.thumb.jpg

%filename is a sanitized version of the upload name, with special characters converted to "-" and lowercased. If you want to keep the messy filename, use %filename_raw.
%vocab-n will be replaced with the a term from the named vocabulary: %vocab-2 = Image Galleries .
Missing elements will be collapsed cleanly if possible. (images/%vocab-2/%filename.%label.%extension will become images/%filename.%extension if no vocab-2 term or label is present). Files are not renamed or moved after upload, even if these parameters are changed.

@dman: Just to give you an idea, this is my Pathauto pattern for Acidfree: [type]_[author-name-raw]_[nid].

You have "uid" but not "username". Just a thought.

Adding username as another token is easy. I don't have sites where that would be helpful, but no reason why we can't just add it.
Hm. I wonder if I should rename %label to %type or %size ?

There is certainly no need to follow Pathauto's patterns, but adding node type might come in handy for someone.

Oh, was that node type? Well that's not much use for us. I thought it was image type (preset size)
So, useful names are important, aren't they ;-)

Well, duh. Guess I was stuck in Pathauto-land. Been spending far too much time there lately debugging the code.

bump.
I'm sure there's going to be some teething problems with this move, but I've found and patched the ones I encountered. Anyone else?

Here's the latest cut.
Added the (dangerous, optional) ability to shift pre-existing images into the new naming schema. It's an added option, but was needed to solve my actual problem of having hundreds of images that were actually tagged, but not in folders.

Now, with a useful filename convention (using the image-gallery as a dirname) I can run re-gen derivatives and the old images get sorted. Eventually, it takes a bit of waiting around.
My images folder is now actually browsable instead of having 1400 images and derivatives in it. That was just killing the remote filebrowser we were wanting to use to select images to use :-)

Yes, this is a tricky thing to do to an existing site. It may even break links you've already hardcoded, as the images are going away. BUT it's a better, bigger, long-term solution.
... And I've written a little filter/repair module that fixes broken references (detects embedded images in text, scans for the file, repairs the link if it can locate the new location) ... I may post that up if anyone can figure out what it does.

And, um, bump

Above patch was against DRUPAL-5
re-roll for DRUPAL-5--2 attached.

Testing this patch with the latest image 5.x-2.x-dev:

1) Using image_import: a photo which was named "cd0794.01_actaea-rubra.jpg" got renamed to "cd0794.jpg", and the derivatives were generated therefrom: cd0794.preview.jpg and cd0794.thumbnail.jpg. The derivatives were put into the relevant image gallery directory ("images/photos/ac"), but the original ended up in the "main" directory ("images/photos").

2) Marking "[x] force renaming of original", and clicking "[x] generate derivatives" on a few image nodes: both original + derivatives end up in "images/photos". As there were no extra periods in the name of these images, they retained their full names ("d06-2212-actaea-rubra.jpg" + derivatives, and "pi1998-22-19-actaea-rubra.jpg" + derivatives).

My setting in admin/settings/image, for "Filename naming pattern" is: images/photos/%vocab-7/%filename.%label.%extension
(where vocab-7 is the image galleries).

Lovely patch, I think it just needs a few tweaks.

Since 6.x is where the action is, this needs to get committed there first and then back ported.

That period problem should be easy to fix.

I was concerned about the behaviour with image_import. The thing is, that image import transfers the file before it finishes building the node. At the point it's trying to save, the taxonomy/gallery values haven't been set. The extended path cannot be constructed.
This may require a tweak to image_import

@drewish. Golly. I guess I'll see what I can do. May take a while as I'm not very active using 6. Still, I should probably start some time.

I found some inconsistancies in the 5--2 version, as the image paths are now being stored in a new table! It almost worked, but was actually discarding the handle on the original.
Needed to fix it up so that image_insert could handle updating the original files path. It was refusing to do so before.
Changes in this patch.

Also, when using 'rebuild' I found that the taxonomy wasn't always present in the fully-loaded form, so I've had to add lots of logic to decipher the 'taxonomy' array to handle loaded/form_values/single/multi/freetag selects each time before calc-ing an image path.

The period problem was just the difference between a strpos() and a strrpos() :-)

I've been bulk testing using node_import, and that is now getting the paths right first time.
Using image_import now also puts them in the right place first time! It was the problem with parsing the 'taxonomy' array that was damaging it. Cool.

This is a dangerous feature to play with on an existing site as any existing hard links to old files, especially derivatives, may get broken!

NOTE: Although I will eventually try for the 6.x release, this development is still against 5--2, as that's where my real-world testing is happening.

.dan.

OK, on the latest 5.x-2.x-dev:
#1. image import works, and images end up where they're supposed to go.
#2. regenerate images works, but the /%vocab-7/ part of the directory (or file path) is ignored (= for me, original + derivatives are in /files/images/photos/ )
#3. the name is retained even if there's more than one "." in the file name (= the conversion of spaces, _, ., etc. to "-" (except for the last ".")) works now.
#4. _original (from image import?) now has an entry in the files table, too. Derivatives are generated on first view instead of right away; shrug.
Edit: #5. I've found double .preview. and .thumbnail. entries for derivatives in the table files. Edit: I had one set called "cd0794.01_actaea-rubra.[derivative].jpg" and one set called "cd0794-01-actaea-rubra.[derivative].jpg" (. and _ converted to "-"). Dunno how that happened.

Good job, only #2 and #5 needs fixing, for 5.x-2.x-dev!

marked http://drupal.org/node/248088 as duplicate.

marked http://drupal.org/node/248088 as duplicate.

Could I have more reasonable argument why my support request marked as duplicate? Instead of just providing a very generic reason which does not even apply to my support request, like below.

Duplicate of http://drupal.org/node/103793 (and about 1000 other issues, marked duplicate) - test that, give feedback, and - if you can - upgrade the 5.x-2.x-dev script to 6.x-1.x-dev.

Changed back the status of http://drupal.org/node/248088 to active.

Can image be not renamed, but somehow aliased via mod rewrite? as it happen in drupal with node URLs? in this case no changes in filestructure necessary if webmaster desided to change a way files named? aslo it is possible in this case to keep old aliases to support external links work for some time.

Mangust: you're missing the point, which is, file systems crash and burn under the onslaught of thousands of files in one single directory. This patch addresses that problem - and it's a feature that's been asked dozens of times. Gotta love dman for taking it on :-)

Images can be renamed any way you like, with url_alias.

I have tried to apply the patch manually into the latest 6.x-1.x-dev (2008-Apr-18). Please find that patch attached.

When tried to create an image node with a selected picture, I got a blank white screen after I hit the Save button. I was actually confused where to put the line to be modified in the following codes:

@@ -357,7 +415,7 @@ function image_prepare(&$node, $field_na
     }
 
     // Save the file to the temp directory.
-    $file = file_save_upload($field_name, _image_filename($file->filename, IMAGE_ORIGINAL, TRUE));
+    $file = file_save_upload($field_name, _image_filename($file->filename, IMAGE_ORIGINAL, TRUE, $node));
     if (!$file) {
       return;
     }

As there is no image_prepare function in 6.x-1.x-dev.

Could anybody give me suggestions?

#62 still applied to 5--2-dev, and I got a chance to revisit it (sorry for the delay - real work)

#2. regenerate images works, but the /%vocab-7/ part of the directory (or file path) is ignored (= for me, original + derivatives are in /files/images/photos/ )

Could not replicate. %vocab-1 (image gallery) is working fine for me on rebuild, and even on image_import too!
I'm using a freetagging, flat vocab with no funny characters. Not sure what could be the difference for you. I tried non-freetagging, still worked.

#4. Derivatives are generated on first view instead of right away; shrug.

I'm pretty sure that wasn't me. But I like it!

Edit: #5. I've found double .preview. and .thumbnail. entries for derivatives in the table files. Edit: I had one set called "cd0794.01_actaea-rubra.[derivative].jpg" and one set called "cd0794-01-actaea-rubra.[derivative].jpg" (. and _ converted to "-"). Dunno how that happened.

Also unable to replicate duplicate rows. I tried a bunch of random things like changing the naming pattern in mid-session, using multiple vocabs, etc, but not sure.
There was a point where '_' was being filtered out as a special character, I've caught that now, and I guess the literal '.' is legal also. ... and this produced another instance where I needed strrpos() not strpos(). Caught that now I think.
You can choose to use %filename_raw if my preferred %filename sanitized version is a problem. %filename_raw is the configured default - to match old behaviour.

I've been using it now a bit, and am happy with it.
I'll see if a D6 roll is too painful. I can do it in theory, but simply won't be pushing the testing to the limits as I don't run real sites in D6.

Anyway, here's two fixes (basically just regexp) , and a small modification to the UI docs.

marked http://drupal.org/node/228640 as duplicate.

marked http://drupal.org/node/259459 as duplicate.
marked http://drupal.org/node/259652 as duplicate.

Nice patch, thanks dman!!

I'm hoping this can help me with my problem. I'm using version image_filename_rewrite-5--2.02.patch of the patch. I need my thumbnails renamed as following:

Original image name: image1.jpg

Thumbnail name needed: imagethumb1.jpg

So, basically I need the %label token inserted within %filename_raw token between the last alpha character and the first numeric character. Can this be done and if so, can anyone guide me?

I know a bit of PHP so I'll give my revised image.module file a look, but I'm not knowlegable enough to give it a good hack, I fear!

That one's a bit tricky-dicky.

To support something like that, we'd have to allow your token string to be, um, a regular expression.
Not impossible, but hard to document, and probably at least one other config field. .. for the input match. I can imagine it, but currently I'd call it overkill for just getting this patch in.

If you are really keen, go hack at it. Add a 'match' field to the config which you will then add something like /^([a-z]+)([0-9]+)\.(.*)$/
to find your original, then your token can use %1, %2 to rewrite into
"images/%1%label%2.%extension"

... Actually making it work in the middle, I'll leave up to you.

The real problem is - what happens when your input filenames do NOT match your input pattern? I don't know how to support that without some sort of procedural logic. Therefore ... pattern-based rewrites are not a general-case solution as far as I can see.

Maybe instead we need a hook callback - so you can define your own rewrites? .. Nah, overkill.

I already tackled writing a piece of code to split the file name into the tokens I need:

$filename="image234.jpg";
preg_match('/\d/', $filename, $matches);
list($firstdigit) = $matches;
echo "Original file name: $filename<br />";
$stringend=strchr($filename, $firstdigit);
$imagenumber=(substr($stringend, -(strlen($stringend)), ($strlen-4)));
echo "Image number: $imagenumber <br />";
$filestart=substr(($filename), 0, (strpos($filename, $firstdigit)));
echo "Start file name: $filestart<br />";

Next I'd just need to update this array with the new tokens calling my function to split the filename, right? (Obviously I'd clean up my code, the echos are there for test purposes.)

  $tokens = array(
    '%nodepath'  => $node->path ? $node->path : $node->nid ? 'node-'. $node->nid : '',
    '%filename'  => image_cleanstring(substr($filename, 0, $pos)),
    '%filename_raw'  => substr($filename, 0, strrpos($filename, '.')),
    '%label'     => $label,
    '%extension' => strtolower(substr($filename, $pos+1)),
    '%extension_raw' => substr($filename, $pos+1),
    '%nid'       => $node->nid,
    '%uid'       => $node->uid,
    '%date'      => date('Y-m-d'),
    '%year'      => date('Y'),
    '%month'     => date('m'),
    '%day'       => date('d'),
  );

You're right about the problem of images that don't follow this logic. Any further suggestions on that?

Giving this some more thought --

Couldn't I just run the appropriate regex on my filename and if it's not in the format image123.jpg I use your $token array as provided and it is image123.jpg, I run it through my function to tokenize it and then use a modified version of your $token array? (Just an if, then, else to get the right array.)

I just need a little more direction about what to modify in image.module to switch %filename to %filename_start and %filename_end.

I worked on this for much of the day and I got some results, but not the right results.

Here is what I did.

First, I wrote a function to split my filenames into smaller token. The image names I want to split are cam1.jpg, cam2.jpg, etc and camb1.jpg, camb2.jpg.

Here is the function:

function split_camstring(&$string1, &$string2) {
		preg_match('/\d/', $string1, $matches);
		list($firstdigit) = $matches;
		$stringend=strchr($string1, $firstdigit);
		$filestart=substr(($string1), 0, (strpos($string1, $firstdigit)));
		$string1=$filestart;
		$string2=(substr($stringend, -(strlen($stringend)), ($strlen-4)));
		}

Next, I worked with the $tokens array as I mentioned above. I set up an if-then-else with two versions of the _image_filename function that includes that array. Here is an abbreviated version of my if-then-else:

if(preg_match('/(cam|camb)([0-9]+)(\.jp(e)?g)/',$filename))
	{
	$filestart=$filename;
	split_camstring($filestart, $imagenumber);
/**
 * Creates an image filename.
 *
 * Uses a token template string to invent new filename and folder structure for each derivative file.
 */
function _image_filename($filename, $label = IMAGE_ORIGINAL, $temp = FALSE, $node = NULL) {
  $filename = basename($filename);
  $pos = strrpos($filename, '.');

  // Build filename according to token pattern.
  // When previewing a new (temp) node, we don't know the nid, but it should be available by submit time, so it'll work out.
  $tokens = array(
    '%nodepath'  => $node->path ? $node->path : $node->nid ? 'node-'. $node->nid : '',
	'%filename'  => image_cleanstring(substr($filename, 0, $pos)),
    '%filename_raw'  => substr($filename, 0, strrpos($filename, '.')),
    '%filenamestart'  => image_cleanstring(substr($filestart, 0, $pos)),
    '%filenamestart_raw'  => substr($filestart, 0, strrpos($filestart, '.')),
	'%imagenumber' => $imagenumber,
    '%label'     => $label,
    '%extension' => strtolower(substr($filename, $pos+1)),
    '%extension_raw' => substr($filename, $pos+1),
    '%nid'       => $node->nid,
    '%uid'       => $node->uid,
    '%date'      => date('Y-m-d'),
    '%year'      => date('Y'),
    '%month'     => date('m'),
    '%day'       => date('d'),
  );

everything else in function
} else {

The original version of the file untouched
}

Then I went to the file naming pattern area for the image modules and set up this token sequence:

images/%filenamestart_raw.%label%imagenumber.%extension_raw

Once again, I'm trying to get my thumbs to be like:

cam.thumb1.jpg
camb.thumb1.jpg
cam.thumb2.jpg
camb.thumb2.jpg

However, it's not working right. My thumb images names are a mess. The new tokens aren't being interpreted. This is what I'm seeing on my server:

cam2start_raw.thumbnail%imagenumber.jpg

Any suggestions? I feel I'm so close!

I hope someone can pitch in and help me out here. I re-thought this and inserted the following before function _image_filename where the $token array is:

if(preg_match('/(cam|camb)([0-9]+)(\.jp(e)?g)/',$filename))
	{
		preg_match('/\d/', $filename, $matches);
		list($firstdigit) = $matches;
		$stringend=strchr($filename, $firstdigit);
		$startfilename=substr(($filename), 0, (strpos($filename, $firstdigit)));
		$imagenumber=(substr($stringend, -(strlen($stringend)), ($strlen-4)));
	}
	else
	{
		$startfilename=$filename;
		$imagenumber='';
	}

This is instead of the function in my previous post and then if-then-else that calls a different version of the _image_filename function.

So, assuming $filename is just the file name without a path, what I'm doing is testing to see if it's in the form cam1.jpg or camb.jpg (these are the image file name types I need to tokenize further). If that is the file name, code is executed to create two new variables, namely $startfilename and $imagenumber.

If $filename doesn't pass the regex, I assign $startfilename the value $filename had and $imagenumber is empty.

Then I added the following to the $token array:

    '%startfilename'  => image_cleanstring(substr($startfilename, 0, $pos)),
    '%startfilename_raw'  => substr($startfilename, 0, strrpos($startfilename, '.')),
    '%imagenumber' => $imagenumber,

So, I should have 3 additional tokens.

To the admin panel and I make my file naming pattern images/%startfilename.%label%imagenumber.%extension_raw.

I got different results than my previous attempt, but still no where near acceptable. Now I'm only getting one thumbnail file which is named thumbnail.jpg which is no good.

Can someone please tell me what I'm doing wrong, or am I really trying to achieve the impossible?

You are going down a little road to madness.
Because your requirement is so custom, there's not much future in trying to integrate with the tokenize approach.

What I would suggest is trying to override _image_filename() altogether with your own version. Taking the same input it does, ignoring the token string, and returning whatever you think it should return. Possibly falling back to tokens if it fails.

Now, I dunno the best way to over-ride it. Normally we'd try hooks ... but that's still inappropriate here.

So just insert a call to return my_image_filename() at the top of _image_filename and keep clear of the rest of the code.
Or maybe allow it to be 'themed' :) theme_image_filename() ...
All-around, it's looking pretty hacky.

You say there isn't much future in trying to integrate it with the tokenize approach. Do you mean integrating it there and having something to give back to the community? Although I'd love to have something to contribute back, that really wasn't my goal here since I agree with you that I'm probably the only one in the community that would ever need a strange requirement like this. I'm just trying to find the easiest way to get this to work for me so I can move on with the rest of my site.

Are you able to suggest why I'm now just getting one thumnail image of thumbnail.jpg? Can you tell me if $filename is just the file name with extension?

I'll have to see what I can do with your suggestion, but I'm new with PHP and still am not necessarily grasping how Drupal all works with the hooks and that stdClass that I just can't seem to wrap my head around.

Suppose better to make this tokenizing with token-module

if (module_exists('token')) ...

So if no token module installed then no config params!

I'm still working on the token approach, but nearing ready to give up. It seems that the system isn't recognizing the new tokens I'm adding to the array and when that happens, I end up with one lone thumbnail file of thumbnail.jpg. When I change the token string back to the default which is with existing tokens, it works as it should, but of course I have this special requirement of how my thumbs need to be named.

Any suggestions for getting the mod to recognize my additional tokens?

I hope I'm not speaking too soon, but I think I got this working the way I need it too! :-)

The if/then/else in post #78 was above (ie, outside of) the _image_filename function and therefore my new variable names were out of scope with the function. I just moved my if/then/else into the function and it appears to be working!

will this work with the keep tree patch (make galleries and subgalleries based on directories and subdirectories) http://drupal.org/node/225014 ?

http://drupal.org/node/256210 seems mildly related ... about leaving the files where they were using upload path...

marked http://drupal.org/node/271369 as duplicate

This discussion has got so long and I really got lost whether any solution came out of it at the end. I am not a programmer but a good user :) I think duo to practicality issue and to make the images more useful across the system it is better to use a logical way to follow the link back to the image at all the time. If the Image Module is able to create a sub folder for a gallery as soon it has been created from Admin panel then we can use a selected gallery number system to get us to the image in the containing gallery by:

images/gallery-01/gallery-01_image#1.extension
images/gallery-01/gallery-01_image#2.extension
...
..
..
images/gallery-0x/gallery-0x_image#x.extension

This will allow me to use the images in any future post much easier and logically update it as well.

I think the searching system in Drupal Web site should become more efficient to avoid so many duplicated issues being posted. The Google Help and discussion API is good since when you type the subject an list of related issues are keep coming up at the side bar which might fit your match. This will stop people to post the same or nearly the same issue over and over.

You can see this here
http://groups.google.com/group/Gmail-Help-Composing-Messages-en/post

Thank you for your hard work guys

You gave a link to the google system which I cannot access. It may be good, but I cannot see it. This shows that sometimes it is not easy to find the best answer the first time you look.

I think the answer is not best from numbers like you say, but more useful from gallery names. IMO.
A problem the programmers is looking at is:
what happens when an image is tagged with a different term?
changing tags - when we have files saved with the tag name - means the file names may change. This is a tricky problem. It's not easy to get the best answers all the time. We ARE thinking about the future. maybe more than your ideas.
We are looking for good answers, not just easy ones.

If you do not want to read the long discussion, then maybe you don't want to see the big problem. We actually want to see the an answer.
We are looking for a good way forward.
I think the best way is to add more ways for the admin to add tokens to the filenames. Then the right people can make the right rules.

Sorry you have to be logged on in with Gmail to see it as it says

You must sign in to Google to complete the previous action.

I did not mean to underestimate your work. Someone had redirected my thread to read here and download patch but I was more lost. Anyway, you might look into Gallery2 for similar solution. The thing is when an images got its initial position in one Gallery and tagged with a order number, it should not matter in positioning it on any other records. No one says that an image in History Gallery can not be used for Social Science.

If we are looking at cross Gallery representation then we should look into creating aliases from different gallery for the same initial entity. This means Galleries should allow for physical image presentation as well aliases images. In other word an option in Edit image view "show image in Gallery 1, 2, 3, .., X" and from each Gallery view Image will have different properties view. In view interface one can see link to other Gallery positioning for the same image.

I hope this can help.

I am against inclusion of Gallery, which is a taxonomy. Since there exists the possibility that an image is part of various taxonomy terms (galleries) at the same time (i.e. mammals, dogs, pets). While taxanomy is extremely flexible, how would you express membership of various vocabularies and terms in a file path? All terms in one string? In what order? Create a folder for each term and make symlinks? How would you do that under Windows (multiplatform)? Too complex!

When you have the image physically presented in a folder, you may link to the same image record from any view position in any album with different SQL string. The representation has nothing to do with where the image is preserved physically. The location just keep in order a tree structure to find the item and update it or make backup when it is needed.

marked http://drupal.org/node/296969 as duplicate.
marked http://drupal.org/node/296940 as duplicate.

I'm new to Drupal and I'm migrating an existing web site which has 1500+ pictures all neatly arranged in sub-directories. Hence this enhancement looks extremely attractive to me as I don't want to end up with 4500 original and derivative files in files/images.

I'm working with D6 though, so I have made an attempt at porting the functionality from #70 into Image 6.x-1.x-alpha3 / 6.x-1.x-dev.

There are two patches because the admin settings code needed to go to image.admin.inc and my scant knowledge of patching in general led me to think they need to be separate?!

One major caveat before trying the patches please: because I was hitting various validation issues, I decided I should really try fixing them first, so my patch here requires the patch from http://drupal.org/node/292039 to be applied first.

I realise that's not ideal, I hope that's not contravening some important rule, but I am posting the patches here in the hope that 292039 will be given the OK fairly quickly, or that people with a need for this enhancement could look at both patches as a unit.

One useful discovery which may benefit anyone testing the D5 patch is that I think in _image_filename() the D5 patch erroneously passes $node->nid to taxonomy_node_get_terms() - this should be $node. As in:

  if (empty($node->taxonomy)) {
    // Fetch them.
   $node->taxonomy = taxonomy_node_get_terms($node);

This was causing galleries of images that had been imported successfully to a "tokenised" path to be moved unexpectedly back to the "normal" image directory at a later time.

Other points:

1. I have retained the form field for the standard IMAGE_DEFAULT_PATH variable. This is relevant to the way I handled temporary file uploads (see next point).
2. The approach dman took for creating a "temp" subdirectory of the tokenised path to hold the uploaded file before Save tended to create a lot of temporary directories which would make things more complicated for a clear-down in image_cron(). Also it is less feasible in D6 because the file_save_upload() needs to be called sooner to make the validation actually work (again, see the other issue). Hence I have taken the view (partly implemented in the patch for http://drupal.org/node/292039) that all temporary files get stored in /files/images/temp only (not /files/tmp either) during preview and only moved to the tokenised path if the user clicks Save.
3. There is a suggestion to remove the "Rebuild Derivatives" form option in http://drupal.org/node/196823. I found this useful because with the tokenised path enhancement in place, a change to an Image node's taxonomy could require its "original" and derivatives to be moved and selecting this option achieves that immediately during the Save action.

Apart from the above differences, I have tried to keep the functionality the same as dman's patch. There are still issues from earlier comments that I have not tackled, like how to handle files where the filename itself has been changed to incorporate a token and the user then amends a taxonomy term. My best idea so far is to limit the functionality so that filenames can't be changed - only paths.

So... your thoughts please :)

Thanks for the efforts. I hope to start working with some D6 sites soon, so I may be needing to push this forward as well.

I'm aware of the temp filename issue, I didn't have a logical fix for it at the time when I was more intent on avoiding data loss :-)

I hope to be able to try this patch out soon... There's heaps of interest, as you can see.
I've now come across half a dozen other 'token' modules, we should probably review the syntax I'm using - which was just made up without reference to the new token.module or anything. Any input on that would be cool.

The uploadpath module has been mentioned already, but that was some time ago and it appears to be working quite nicely now, just not together with image. In addition to defining custom paths, there's also an option to change the actual filenames, but the actual transliteration is hard-coded instead of tokenized.
I suggest looking at the module again and figure out a way to make them cooperate. The problem appears to be with the way image does its housekeeping of file locations, so it would need to be fixed here rather than the uploadpath module.

marked http://drupal.org/node/325848 as duplicate.

I attempted to apply this patch on alpha3 for D5 and got the following:

Hunk #10 succeeded at 1400 with fuzz 1 (offset 10 lines).

Does that still mean I was successful?

If you got no hunk FAILED message, and there is no *.rej file in your target directory ... then yeah, it's OK.

Thanks, dman. And also thanks for your efforts in updating this patch for D6. Very useful!

I have remade my earlier D6 patches because of the changes that have been committed for Image in the last 6-8 weeks.

These patches depend on successful application of the latest patch in #298702: Properly validate image uploads.

Yes, #298702: Properly validate image uploads, not #292039: Image node can be created without any image as previously featured.

Without those fixes to the validation bugs, testing this enhancement would be nigh on impossible for D6. The good news is that there has been some movement on that issue.

I am aware that it is preferable to present all patches in a single file but as the baseline version of image.module for this patch is not HEAD but 'HEAD+#298702' I wimped out and did separate ones.

The 'image-103793-on-1-282-part1.patch' should work against image.module rev 1.282 and 'image-103793-on-1-2-part2.patch' should work against image.admin.inc rev 1.2.

Patches to apply against output from latest patches on #298702: Properly validate image uploads.

Massive coding-style and indentation issues in those patches. Also, please read http://drupal.org/patch/create on how to create a single patch file for changes in multiple files.

sp3boy: You are using tabs for indentation, which probably gets displayed correctly in your own editor, but not in ours. See if you can configure the editor to replace tabs with 2 spaces, those indentation issues should be solved then.

I had configured my editor, I do read the guidelines - what I haven't necessarily done is check whether the D5 patch (comment 70 above) that I converted to D6 had tabs to begin with (it did).

However before I post another patch I will do my best to fix this.

Well, at least my editor can be configured to replace all occurences of tabs in a file with 2 spaces automatically on save. then it wouldn't matter if it contained tabs before, thats why I mentioned it.

Here is another patch. I have created a single patch file as suggested in the documentation. However because the "base" version is not the CVS version (it's HEAD plus the latest patch in #298702: Properly validate image uploads) I've had to use diff between two directories.

I have corrected all the obvious coding style issues. I'm sure there are some I've missed.

Always forget the status change.

Not sure if the previous patch will apply easily. Re-made to run from "image" directory.

I have to delete the paths in the patch and left only the filenames, then I could apply it successfully from image module directory.

Eventually it works perfect. This should, must, have to be committed.

Very nice work, tx.

A minor touch...

It might not be necessary to delete the paths if you run patch with -p0 ? Just a thought.

I tried this patch locally and it worked. However, it was only a small test case. Expect more feedback soon, when I'm going to try this with a bigger installation (more terms and images). Thanks a lot for the patch already, much appreciated.

Sorry, but I would not recommend using this patch on a production site. The approach and implementation is wrong, because it re-invents the wheel.

Token module is the generic API module in Drupal to allow modules to use user-customized strings as token values. If we want to add this functionality, then it has to be based on Token module.

Another important aspect is that this functionality most likely must not allow to change the image derivative filenames. Some other modules like Thickbox or Lightbox depend on the fact that derivative images are named foo.preview.jpg or foo.thumbnail.jpg - i.e. this patch may allow to alter the basename "foo", but not anything after it.

I was going to try it out. When I'm tallking about trying something out I'm not talking about blindly putting it on a production installation. :P
Your second point is something that in my opinion should not hold up the development of image.module. If they rely on such a naming scheme, they are doing it wrong.

Yes, this should INDEED integrate token module. That is mentioned way up in this thread as a nice-to-have. The original initiative however predates availability of token module. And has very slowly progressed along its own branch.
Building in token module support is certainly desired. But I suggest we enable the renaming feature enhancement if token is available, but not making image.module dependant on it (fallback to default behaviour).

Second, it is true that lightbox and a few others do depend of filename-munging to guess derivitive names. This is a weakness in design at their end and should (and can) be worked around better. image.module can provide a file-renaming API.
Admins must be allowed to define their own naming schemes. If it breaks someone elses assumptions - the admin can choose to work within, around or outside of those limitations.

Looking back to comment #93 - I did state "My best idea so far is to limit the functionality so that filenames can't be changed - only paths." I still think that has merit although I have not changed any of the patch's original functionality as far as I know.

I have a live site with 1500 pictures (originals, not counting thumbnails etc.) and without this patch life would be much harder and I would indeed have to be renaming actual files, not just organising the images into taxonomy-driven paths.

Let's get the ball rolling on doing this with token module :)

I'm afraid my working copies of image module are starting to diverge too far from CVS for me to make a patch.
But this is what you need at a suitable place in image_admin_settings to get the token options listed:

  // If token module is installed, show the possible replacement patterns for the filepath.
  if (module_exists('token')) {
    $form['files']['token_help'] = array(
      '#title' => t('Replacement patterns'),
      '#type' => 'fieldset',
      '#collapsible' => TRUE,
      '#collapsed' => TRUE,
      '#description' => t('Prefer raw-text replacements for text to avoid problems with HTML entities!'),
    );

    $form['files']['token_help']['help'] = array(
      '#value' => theme('token_help', 'global'), // global tokens only, we don't have a node yet
    );
  }

As far as I can tell, the replacement only needs to be made in _image_filename.
The token API docs here http://drupal.org/node/307140 explain how to do that.

Maybe someone can take this and move it forward a bit?

Also, people more aware of security concerns than me need to consider what to do with raw input tokens at this stage.
EDIT: Turns out that's not an issue as we only have global tokens at this stage.

Subscribe.

Ok, since my issue #411568: derivative paths should be taken from the corresponding original file, and not from the default got marked as a duplicate of this, I'll try to voice my concern briefly here (also to subscribe). I didn't wrap my brain around all the stuff here yet, but to write it down:

** I need the paths for derivatives to be taken from corresponding original file **
It haven't much to do with administrative settings and/or tokens, it was meant mostly just to ensure that derivatives don't move unexpectedly, after changes done to default path for new images.

The use case is: I change the default image path setting time after time, to direct new uploads into fresh directories, and so avoid issues with the directories getting too big. While new originals should use the (new) default, (rebuilt) derivatives should stick to their originals.

If that's already discussed above, somewhere I overlooked, +1 to that. If not, I would like to see it addressed. Thanks.

This patch will move the old images to the new directory. if you want them to be in seperate directories you just add a token. So instead of changing the default image path you could just use a date token to group pictures into monthly folders or something.

@JirkaRybka -- you're saying that if the path setting is 'firstpath' and you later change it to 'secondpath', and some images that were saved in 'firstpath' get regenerated, their derivatives get saved to 'secondpath'?
I would say that is a bug, to be tackled in a separate issue.

I say exactly that.

I provided a patch for that in the other issue (which got marked as a duplicate of this - I guess that's because I also proposed to have subdirectories for separate sizes, when I was at it [easily removable from my patch]). My concern might be solved in this issue (sorry, I *still* didn't find enough time to examine this thread really in-depth), as long as the provided tokens either include "original Image path" (preferrable, to also avoid pre-patch images getting moved), or at the very least something consistently reproducible for both submit/edit and on-the-fly rebuilds, to avoid files being moved.

Honestly, I believe the "original Image path" way is the only clean one, because I don't want the derivatives to get moved away from their originals whatever I do with the settings. If I built my paths per #120 as date/time tokens, and later decided to change that - say - to nodetype/year, then my derivatives will start being moved on-the-fly again, right? I don't want that.

Honestly, I believe the "original Image path" way is the only clean one,

What you take as a matter of faith, I take as a matter of context. You have a point, but not a big one.

A huge use-case for this feature is a site that has uploaded a few hundred or thousand images, and then says 'gosh, I should have used a better naming scheme... how can I fix that?'. We don't all get it right first time.
so the patch (the last time I touched it at least) included the option

+  // rename/move originals
+  $form['image_move_originals'] = array(
+    '#type' => 'checkbox',
+    '#default_value' => variable_get('image_move_originals', FALSE),
+    '#title' => t('Force renaming of original'),
+    '#description' => t('Normally previously-uploaded images remain where they were put, but if you are using the filename pattern to organise your directories, we want to move them also.Set this option, and the next time images are rebuilt, the original file will be renamed also.'),
   );

Note that derivatives get a little less respect. If you change the paths for derivatives and also rebuild derivatives for that image, then the new derivatives will be placed in the new path.
But that was when the patch was young and hopeful...

Now, #411568: derivative paths should be taken from the corresponding original file, and not from the default is open again, for the bugfix-part.

As related to #123 - if I decided to move originals (and had a way to do so), the derivatives will follow them to the new location naturally (with my fix in place, I mean), but not precede them to new default without the originals being moved first (which is the case now). It doesn't collide with your proposal at all (in fact, I did exactly that sort of a change myself on my site, for newly uploaded images at least, and needed my fix for that to work).

Also my fix (on the other issue) now have nothing to do with future efforts about making the paths more configurable. It just fixes the existing defaults, and also provides two separate places for handling originals/derivatives (usable for inclusion of future changes for both paths, I think, however these changes might look like).

As such, it goes away from the scope of this thread again, I believe.

Renaming this so I don't spend 10 minutes looking for it...

Here's a attempt to implement token support for image directory names. Because the actual copy/rename of an uploaded image is only done after a node has been created, I think it's even possible to use node tokens, instead of just the global ones (as suggested by Joachim in #117). I have only tested this patch for a few hours on a development installation, (i.e. not very thoroughly), and I'm sure I've overlooked many important things - use with care...

Yup, I had a quick look again at this yesterday and it can be done.
_image_filename() needs refactoring to get given a $node object (or a null for a temporary file) -- which I see you've thought of too :)

I was thinking of keeping the basic path variable as a simple path, and adding a variable for filename pattern which can take subfolders.
So for example you'd set:
- image file path: image
- image filename pattern: [uid]/[filename]
and your images would get put into a folder per user with their original upload filename.
But I'm open to discussion on this :)

There are however a couple of other patches that need to get in before we can tackle this as they affect _image_filename too: http://drupal.org/node/411568 and another that escapes me.

Yes, this needs to be appended to the default image path. The reasoning starts with: Backwards compatibility. Followed by: Token is an optional module, it can vanish.

Yes,

having a second configurable variable for the filename pattern would simplify the handling of the temporary directories a lot; no need for a _image_strip_tokens_from_path() any more. It would also mirror uploadpaths behavior a bit more.

What would be the best way to coordinate this with the other patches affecting _image_filename()?

I got a proof of concept working last night, but it totally messed up on creating a thumbnail as the function takes the original image's entire path to create the derivative path, so my tokens got repeated.
Clearly, derivative creation needs to be handled as a different case, which http://drupal.org/node/411568 is doing.
So let's mark this as postponed, get that other issue fixed first and then come back here :)

I've been searching for a few days now about how to rename an image upon the creation of an image node (when a user uploads an image). I know that this thread started off on this topic, but it seems to have taken a few tangents. I was hoping someone could give a summary or a suggestion about if a solution was actually reached (forgive my ignorance, I'm fairly new to drupal)

I have applied marquardt's patch from #126, and it works great with file paths when you upload an image (Thanks!). But I've yet to see anything that will rename the actual file.

I've been referred to the filefield_paths module, but I've observed that it only works with attachments, and not actual image "creations". Perhaps I'm using this incorrectly, or missed a setting somewhere?

It is getting frustrating to search for days and find many people who are looking for this same issue, but with no tangible solutions. I apologize again for being a novice at drupal and making minimal contributions myself, but if anyone has made any progress on the original problem, I would greatly appreciate it!

Ah yes, it is a long thread. So:

SUMMARY

This needs to be implemented with token.module: previous patches in this issue are obsolete.
Using token will mean a LOT of options with relatively little code.
Renaming of files as well as placing them in different subfolders of the main image path will be possible.
This issue needs to be fixed first: http://drupal.org/node/411568

So does that mean that there is no solution for renaming images at this time?

Is there something I must do with the patch provided in http://drupal.org/node/411568 ?

I would think someone with a few hours of spare time would have to reroll the patch in http://drupal.org/node/411568, which shouldn't be too difficult. One could then go on and implement a simplified version of my patch (but with more configuration options, see #127 and #128).

The main problem really is that it's difficult for two people to work on the same part of the code at the same time. I'd be happy to take my patch and work on it along the lines suggested by joachim and sun as soon as there is an accepted version from the other issue. I'd also be willing to re-roll that patch myself, but I've never used Drupal testing framework so far - and apparently sun insists on having tests implemented (which is reasonable). I don't mind learning it, but I won't have the additional time until the weekend or so... Sorry!

I've never used Drupal testing framework so far - and apparently sun insists on having tests implemented (which is reasonable). I don't mind learning it, but I won't have the additional time until the weekend or so... Sorry!

This is exactly why I didn't find enough time to proceed, too. I might find a hour for reroll, but finding a day to research on tests is definitely too high a treshold for me these busy days.

Looking into the possibilities of adding support for the Image module into FileField Paths, which should solve this issue.

More information once I have had time to analyze the issue.

Well, while it's not perfect, it was quite easy to add integration with the Image module to the FileFile Paths module. It will be released in the next 6.x-1.x-dev release in a few hours time for anyone who wishes to help test it.

Cheers,
Deciphered.

Sounds like fun!

Two known issues at this stage:
- No token for derivative image type means that filename without [filefield-onlyname-original] token will create derivative images like {file}{_N}.{ext} (image_0.jpg, image_1.jpg, etc).
- On my XAMPP install the Preview derivative is reported as non-existent, where as on my MAMP install it works perfectly.

Edit: A derivative image token has now been defined to solve the first issue, so that means the second issue is the only known issue.
Edit 2: Found a solution for the second issue, but unfortunately missed the window to get it in this dev build, so will be in the next one in 12 hours time. So pending that release, there are currently no known issues :)

Having done some testing of the Image support in Filefield_paths, it looks like there are two solutions pending for the same requirement: the #126 patch and the Filefield_paths approach.

Correct me if I'm wrong but Filefield_paths offers a consistent approach across several modules, whereas this patch gives token support to Image without the need for Filefield_paths? Both are working towards the same functionality?

What I have found with Filefield_paths is that it can certainly use token values to make an image destination path but if the "Rebuild derivative images" option is selected during image edit, the original file is not moved on Save, even if one or more relevant token values has changed (and the derivatives, probably for the reason that #411568: derivative paths should be taken from the corresponding original file, and not from the default exists, are re-created in the default image path).

I have figured out a couple of small code changes to make that happen (one in Image's image.module, one in Filefield_paths' image.inc), but there still remains the problem that the Content Management Update option for Rebuild derivative images does not work even with my tweaks, which I suspect is because the Filefield_paths functionality is triggered by node_save() which I don't think gets run by image_update().

I realise that some or all of the previous two paragraphs rightly belong in their own issues, but can we rationalise the benefit of getting Filefield_paths to provide the same token support as this issue? At the moment, the only thing that appears certain is the worth of having #411568: derivative paths should be taken from the corresponding original file, and not from the default resolved before moving on.

This is open for business again :D

My two cents. I don't like the filefield paths method. Would prefer a native to image method.

The future for image is as a wrapper for imagefield, so by the next major version, you'll have those anyway.

Is there anything I can do to help redo marquadt's patch to help get this moving along again?

I took a look at that patch with a view to moving it on but - sensible though it is - I decided that to add the other features people have been talking about (ability to rename files as well as paths being the main one) I would be replicating more and more of the code of Filefield_paths.

So I have dropped any personal plans to follow that route and have instead (as per my last comment) been putting in many hours testing Filefield_paths with Image. Although Filefield_paths does advertise integration with Image, there are some gaps and bugs that I'm trying to address.

• Image needs a patch to make Rebuild derivatives call the Filefield_paths nodeapi and keep the rebuild flag still set. I'm still testing that patch and so far it is holding up: #564690: Improve support for Filefield_paths to tokenise image filename and path
• Filefield_paths needs a patch or two to eliminate double slashes in paths if some token values are empty, also to recognise the rebuild flag as being a reason to rename / move files. I'm testing that patch but some complications are arising (see next point): #564680: Add support for bulk rebuilds of derivative files in Image module
• I suspect Filefield_paths also needs a patch to stop it using the hooks for Image nodes during its own Retro-active rebuild routines when processing non-Image nodes. I am hoping to add that fix to my existing patch today.

There are also issues around:

• Whether Filefield_paths retrieves its "original file name" column in {files} correctly (#515044: Add support for the [filefield-onlyname-original] token in PHP 5.1 (and lower))
• Whether Pathauto generates pieces of [termpath-raw] token consistently (#422798: unexpected results when using [termpath] and [termpath-raw] tokens in other modules)
• Whether Image needs to populate the "filename" column of {files} with something other than the derivative label "_original", "thumbnail", "preview" etc. (#424386: images saved to files table with bad data in filename column) so that Filefield_paths and any other module that hopes to allow tokenised renaming of files has a starting point for applying retrospective changes to token values or token templates.

None of the issues above is impossible to resolve if I can get some feedback from the owners of each issue.

Hi,

I'm relatively new to all this and the modules I used before were plug and play so I don't know if I'm asking in the right place - please don't kill if it's not.

What I wanted to do is to integrate the image views gallery with shadowbox which could be done if I could output the image field to file (I have shadowbox configured to deal with direct links to files). I couldn't figure out a way to do this and there isn't a token to change the link to actual file.

The image table as far as I can see has the file ID from the files table so I guess it wouldn't be such a big deal if not the fact I'm all thumbs when it comes to modifying modules. Can there be either an option added to output the field as a link to file or a token for the file path?

Thanks,
JJ Celery

@JJCelery: first thing to learn round here is don't hijack a long-standing issue to your own vaguely related problem.

@joachim well thank you very much I will certainly remember that now, you've been very helpful.

Well you could apply the energy behind your trenchant sarcasm to finding an issue that actually IS about your request. I seem to recall there's one about getting more file data into the Views fields (which are nothing to do with this issue), and again, IIRC, there's a patch that needs testing or working on. Sorry if I'm curt, but really, how obvious is it that switching the topic of an issue is not a done thing?

I think this module could help: http://drupal.org/project/filefield_paths

I think reading my previous comment (#145) could help. Or judging by the total lack of interest in the work I put in to #564690: Improve support for Filefield_paths to tokenise image filename and path over a year ago, perhaps not.

Integration with FileField Paths is the way to go.

Therefore, marking as duplicate of #564690: Improve support for Filefield_paths to tokenise image filename and path

If you already have loads of files in your existing files directory and now you add a token-based file field location, then it will only add new files in the new directory structure. For moving all the existing files in a better directory structure, you can use something like https://www.drupal.org/project/organize_files