Convert pre-existing filenames

Transliteration 6.x-1.0+ does this. So, not having looked at your code, perhaps you could look at the code in the 6.x branch and see if it is backportable?

The .install file from the DRUPAL-6--1 branch is now a part of DRUPAL-5--2, the upcoming 2.0 release.

I'm lucky that I've read the changelog prior installing Transliteration on an existing site. While this feature makes sense, it has the possibility of breaking existing download URLs in contents or links on external sites. That is why the original patch implemented a confirmation form that warns the user about possible implications of this action.

IMHO, this should really be an opt-in feature. Maybe a constant in the .install file.

I agree with Sun, this should really be an opt-in feature. Maybe a constant in the .install file or button on a settings page.

I had the same problem. If you got inline images, this can be downright dangerous.

Loads of images can vanish. Please make the retroactive conversion optional.

I just had a whole bunch of file attachment links on my site break because files were retroactively renamed. :( At minimum, this needs to be mentioned in the Readme, and ideally a warning should be presented before the conversion of pre-existing file names takes place. It would be better to have this as an option, however.

I suppose there's no going back now. I didn't notice the problem on the same day as I installed this module, so we'd lose too much data by reverting to a backup.

Could a utility be developed to sanitize URLs within nodes, to help us recover?

Changed the status to critical - because this may cause people serious trouble. Imagine someone having several thousand files, and a fith is erroneuosly converted.

There is also a problem with imagefield - imagefield creates .thumb.jpg files in the D6 version for the preview thumbnails in the upload widget. Snce these files are not in the files table, their names are not transliterated. But since Imagefield appears to create the name it looks for from the original filename, it cannot find those files anymore - in consequence all the widgets are there but no thumb images anymore, if the file name was transliterated.

It looks like the modules "scanner", "node find replace" and "search and replace" may be able to go through and fix the broken links, but I need to know what all the "sanitized" substitutions were.

This burned me as well. In my case I enabled the module on a production site, thinking it would clean up new file uploads, and it managed to change filepaths on a bunch of my files without updating the records in the files table. (This particular anomaly was probably related to my use of private_upload module). To fix it I ran

update files set filepath = REPLACE (filepath, " ", "_");

to get rid of the spaces left in the files table that didn't match the new filepaths.

Subscribe.

Just testing transliteration module because it is recommended by FileField module and required by ImageCache module.

Decided to try the 6.x-3.x-dev version since it seems to have been updated most recently.

I tested it on a site with existing files and content database.

YES - I did backup the database and had the files already backed up.

I proceeded to convert existing file names through admin/settings/file-system/transliteration page.

The backups were essential as this does not work properly.

1. The conversion of existing file names reported a handful of files that it was not able to convert.

2. Looking at the files actually in the folders there are other filenames that have not been converted.

3. Some content was working immediately afterwards and some was not.

Yes, the warning is clear, but I couldn't afford the time right away and with the other issues, it is a no go.

4. Also, the date and time of all files is reset to the current date and time when they are being renamed, rather than leaving the date and time unchanged. This seems unnecessary and unusual as normally renaming a file does not change it's date and time.

This was not the outcome I expected, so I have resorted to the backups and turned off the Transliteration module.

Can anyone suggest the best way to sanitize and update existing files, or is this still underdevelopment?

Thanks,

Izzy

As this has been reported to be a very dangerous feature. Am having the horror image in mind of a newbie drupalist, being in full gear for the enterprise product drupal. And then borking 20.000 files.

I guess this is a hard race, because there can be quite some places where files hide from the module.
Not sure if simple image upload with IMCE is now covered and well converted, which would be a start.

Else am voting for turning this feature off by default and marking it with big red letters while hiding it behind a barbwire...
on your own risk...
But maybe it is switched off now by default?

Transliteration is something that belongs to core and to be switched on by default, so no filenames would have to be converted retrospectively.

I would agree that Transliteration makes sense for core and I have been meaning to ask if it has been considered as part of core since the Filefield module is in D7 core and recommends the Transliteration module.

Can anyone comment on whether or not this will be in core?

Otherwise, knowing what I know now it would be worthwhile to have Drupal core file systems help and/or documentation alert new users with the suggestion to consider installing Transliteration early on.

For the use case I had, I made the changes manually. There are utilities available to rename files to remove spaces and make the filename lowercase without changing the date of the file and there are linux commands to do the same.

Changing the database is not so simple but is doable with phpMyAdmin with some patience and care.

Izzy

Well for D7 it sure won't. D8 is another game, so maybe we should start an issue for that... done.
#819966: Get Transliteration into core

In 6.x-3.x and 7.x-3.x this is now a opt-in feature.