This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit

eZ Community » Forums » Developer » Class "FILE" has no extension

Class "FILE" has no extension

Class "FILE" has no extension

Monday 14 May 2012 5:36:14 pm - 8 replies

Good evening

Everytime I upload a file on ezpublish (an element of "file" class) the extension is not saved.

Actually when I try to get information about this element with 


I get this:

"/var/prov/storage/original/application/3f43ead9d8d7e078505c3ccf54f0849f " where's the extension??



Tuesday 15 May 2012 3:32:58 am

What version of eZ Publish are you using?  This was an issue in older versions.  While the extension is not needed to ascertain the file/mime-type, it's certainly handy.

Saturday 08 November 2014 6:10:19 pm

Hi folks!

Faced the same problem. When a file is uploaded through the editor online, this is stored without extension, instead the extension is preserved when the file is uploaded directly as an object. Being unable to open the extensionless file linking directly to its file path, I looked into it and ended up to somehow make it work making these adjustments as well explained here at

Even though the file is still stored without the extension, now it opens up.


changed this line

$destFileName = md5( basename( $fileName ) . microtime() . mt_rand() );

to this

$extension = pathinfo( $fileName, PATHINFO_EXTENSION );
if ( $extension )
    $extension = '.' . $extension;
$destFileName = md5( basename( $fileName ) . microtime() . mt_rand() )  . $extension;

blunk.gif Emoticon

Saturday 08 November 2014 7:01:05 pm

I don't know if I'm missing some essential part of the story but I would never link directly to the var storage file - this is the type of code I would use:

<a href={$attribute.content.filepath|ezroot}>{$attribute.content.original_filename|wash(xhtml)}</a> {$attribute.content.filesize|si(byte)}

That should return the contents of the hashed file wrapped with the necessary mime type info to have it come out right.

If that's not happening there's something fundamentally broken with your installation - and/or it's the bug that Geoff mention - which I've never run into either.

Modified on Saturday 08 November 2014 7:03:51 pm by Steven E Bailey

Saturday 08 November 2014 7:43:45 pm


It is an extremely bad and unnecessary practice to link directly to any files in the var directory!

Instead please link to files only through the content/download module view which provides any feature you would require.

When you work within the supported feature set there is no need for your patch / kernel hack.

Ps. You could submit a pull request if you insist that direct linking to a var dir file without a human readable friendly file name is better than the supported features.


Modified on Sunday 09 November 2014 2:45:51 am by // Heath

Sunday 09 November 2014 4:13:52 pm

Hi guys. Though I thoroughly agree with you when you advise not to link directly to a file and alter without any mean the kernel, my client made a specific request with the option to open the file to a new browser window, so I made it this way:

{def $file = $object.data_map.file}
{if $classification|eq('new_window')}
    <a href="{$file.content.filepath|ezroot('no')}" target="_blank" title="{$file.content.original_filename|wash("xhtml")}">
    <a href={concat("content/download/", $file.contentobject_id, "/", $, "/file/", $file.content.original_filename)|ezurl} title="{$file.content.original_filename|wash("xhtml")} [downloaded {$file.content.download_count} times]">

Otherwise, how else can I make this happening without linking directly to the file?

Modified on Sunday 09 November 2014 4:19:29 pm by Lo' F.

Sunday 09 November 2014 7:11:10 pm

Hello Lo' F.,

First lets have you share with us some more information.

What kind of file are you trying to open in the new browser window (inline vs download)?

What version of eZ Publish are you using?

What browsers are you using for testing?

For inline PDF you need to set the following settings, clear all caches (using the admin) and clear all browser caches and restart your browser.





I hope this helps!




Modified on Sunday 09 November 2014 7:14:48 pm by // Heath

Wednesday 21 January 2015 5:17:39 pm

Hey Heath, it has been a while since the post, but having to deal with some other stuff took me kind of busy and away from testing the solution you suggested here.

Well, I must say, no need to hack the kernel at all, that setting works just as it is. It adds the extension to the encoded name of the uploaded file.Thanks, Heath!

By the way, the question you asked (just as a reference for the post):

- pdf files

- Community Project 2014.7, legacy stack

- Firefox 35.0

Modified on Sunday 15 February 2015 4:54:47 pm by Lo' F.

Saturday 24 January 2015 12:36:55 am

Hello Lo' F,

I'm pleased I could help you find a solution to your problem.

Best wishes.



You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from