Plugin Request: File Size Tag?

I’ve updated the plugin to 0.2 according to Ryan Masugas mod.

I’ve also put the upload_pref server path variable in the cache, so that a page with 100 files (= 100 calls to the plugin) will only fetch the server_path from the DB the first time, the subsequent calls will fetch the server_path from the Session cache.

Enjoy!

Works great now Andy, thanks!

You’re quite welcome Steven.

Andy, thanks for officially incorporating those changes. I have a couple others I added that might be useful - or cleaned up by someone more skilled with PHP than myself - namely, you. You can add them or not - I just thought I’d document everything I had changed.

Working with Mark Huot’s File Extension Because his file extension returns a full path, I just added ‘basename’ to make sure we’re only getting the filename:

$filename = basename($filename);

Show file extension Added this line:

$showext = ( ! $TMPL->fetch_param('showext')) ? 'no' :  $TMPL->fetch_param('showext');

Then the extension:

$fileexplode = explode('.', $filename);
$fileext = $fileexplode[1];

Then I had an ‘if’ statement at the end, which I’m sure you would need to change, based on your updated code:

if ($showext =="yes") {
            
            return $this->return_data = $sizedata." ".$fileext;
        }else {
            return $this->return_data = $sizedata;
        }

That’s everything I had changed. Like I said, I’m not PHP guru, so some of this might be ugly - but it’s working!

Hey Ryan, thanks alot for bringing this old thing back to life!

I’ve updated the plug with some new candy, have a look in the plugin manager for updated docs that does a fairly good job of describing the new stuff.

hints:

{fs:file_size}, {fs:file_extension}, {fs:size_unit}
{if fs:file_size > 10 AND fs:size_unit == "MB"}warning: large file!{/if}

Please report back any issues to this thread!

Oooh, nice! Now this plugin is pretty much everything I need for what it is. You added some real nice stuff in there, including magical unicorns, no less! Thanks for updating the usage part of it too - I love a plugin with good usage notes. By studying what you’ve done I also get the benefit of learning how to “prep_conditionals” and return data as tags. Very cool.

Thanks for making all these little tweaks official additions to the plugin.

One question about the cache after using for a couple minutes. In the comments inside the plugin it reads:

“get the path to the file from the upload preferences once per page, then fetch from cache”

What if you are using filesizer on files that appear on one page but have been uploaded in different directories? I’m asking because I think my cache is stuck. I have the following on my template:

{exp:filesizer filename="{miscfile_download}" upload_pref="4" decimals="2" show_extension="yes"}

But it is definitely pulling from upload pref 5, not 4 like I want - which is resulting in an error. I’ll try clearing the caches, but I was wondering if the caching might cause issues like that?

Thanks for reporting!

I’m looking into it.. that shouldn’t be the issue (but it certainly might). I’m fetching the path from the DB and storing it in the $SESS->cache array, for each upload_pref I’m changing the name of the cache key, so both theoretically and in my tests this worked fine, since the upload_pref value decides what path to fetch from the session cache.

I’ll do some more testing and report back here.

Besides, who doesn’t love unicorns? :)

I’m consistently getting the correct server_path, my $SESS->cache array looks like this when print_r’ing it:

[filesizer_filedir_1] => D://_localhost/htdocs/ee160/images/uploads/
[filesizer_filedir_3] => D://_localhost/htdocs/ee160/images/uploads2/

Note: my upload pref #2 is not in use in this template so it’s supposed to be just 1 and 3.

edit: terminology

• Added error checking when fetching the server_path.
• added array_reverse when exploding the filename on ‘.’

Please report back any issues.

Well, I just found that this might be a bug - but not with this plugin. I am seeing some weird behavior with the file_upload_prefs on my install. I just put in a bug report over here: Upload Prefs ID’s are incorrect.

A couple other things (how demanding am I?):

Multiple periods in a filename. I was testing with this file: “pi.filesizer_v03.zip” and the plugin was returning “filesizer_v03” as the extension. I’m sure there is a way in PHP to get the very last piece of shrapnel from an ‘explode’ - in this case, ‘zip’. The way around this now is just to ensure a single period in the filename - but hey, we’re all about foolproofing things, are we not?

Undefined Offest. I am seeing “Notice: Undefined offset: 1 in /home/…/pi.filesizer.php on line 69”. Something to do with the decimals output, I think.

One last thing: Magical Unicorns. I think these need to go above the “$file =” line. Currently, it reads:

// find the file and measure up..
        $file = (substr($filedir,-1, 1) == '/' ? $filedir : $filedir.'/').$filename;

//    magical unicorns
        $filename = basename($filename);
        $tmp = explode('.', $filename); 
        $fileext = $tmp[1];

But in order for it not to throw an error in certain cases I think it needs to read:

//    magical unicorns
        $filename = basename($filename);
        $tmp = explode('.', $filename); 
        $fileext = $tmp[1];
        
// find the file and measure up..
        $file = (substr($filedir,-1, 1) == '/' ? $filedir : $filedir.'/').$filename;

So that we reduce file to basename first. I was getting errors with Mark Huot file fields until I switched that - and now the plugin works fine, except for the Undefined Offset I’m seeing.

LOL

Just to note guys, extract url plus already does most of the functionality here (besides the conditionals)

the_butcher: thanks for the heads up!

psst.. don’t you just love unicorns?