Re: [Phpwebsite-developers] Finding mimetype best practice

[Verdon V. <ve...@ve...>]

Hi Shaun and Greg :)

Thanks for your input. I've replied/commented inline below...

best regards,
verdon


On 26-Jul-05, at 5:51 PM, Shaun Murray wrote:

>
> On 26 Jul 2005, at 16:18, Verdon Vaillancourt wrote:
>>
>> if (!function_exists('mime_content_type')) {
>>     function mime_content_type($f) {
>>         $f = escapeshellarg($f);
>>         return trim( `file -bi $f` );
>>     }
>> }
>> $type = mime_content_type($file);
>>
>> However, I suspect this will not work on a windows server.
>
> I suspect it won't work in safe_mode either.
>
> How about using...
>
> http://pear.php.net/package/MIME_Type
>
> ...which does the grunt work for you.
>
> <?php
> require 'MIME/Type.php';
> echo MIME_Type::autoDetect('file.mp3');
> ?>
>
> It uses either the php function, or the file command if available, 
> otherwise it raises an error.

I like this idea! The MIME package is not included with the pear 
libraries, distributed with phpWS, but I have discovered that putting 
Type.php in my mod's class directory, and including it in my class, 
does the job. Ideally, I'd like to find a way to test if this will work 
at my edit function step (before the user gets to the save function), 
so I can completely hide the import option from the edit screen for 
those users who will still not be handled by the Pear function.

I'll have to play a little further yet, but think you have put me on 
the right track. It's hard for me to test, when the 2 servers I have to 
test on both meet the requirements (file or mime_content_type) in one 
way or another ;)

All this has shown me I need to spend a little more time poking around 
the Pear site and documentation!

>
> There's also http://www.phpclasses.org/browse/package/922.html which 
> runs off file extensions and a mime.types file but that's a little 
> dangerous. Stick with PEAR.

This is the sort of thing I was alluding to with my option 3 idea, and 
yes, I feel it is too dangerous.



On 26-Jul-05, at 1:25 PM, Greg Tassone wrote:

> On Tue, 2005-07-26 at 11:18 -0400, Verdon Vaillancourt wrote:
>> In a module of mine, I have a case where I need to check the mimetype
>> of a file already on the server. In my initial attempt, I used...
>>
>> $type = mime_content_type($file);
>>
>> Then I discovered that mime_content_type may not be available in all
>> php builds, and/or that it may not be enabled in php.ini.
> ...
>
>> However, I suspect this will not work on a windows server.
>>
>> That leaves me with a couple options...
>>
>> 1) go with the above solution which I think will work for most people,
>> and provide documentation for the rest
>> 2) use function_exists('mime_content_type') and if it doesn't exist,
>> don't even offer the module feature to the end user
>> 3) use function_exists('mime_content_type') and if it doesn't exist,
>> use a file ext check instead and map to mimetype (not very good I 
>> know)
>
> I don't recommend option #1 at all.  It is usually problematic and more
> trouble than it's worth (e.g., it tends to generate support issues
> needlessly, even when documented).
>
> #2 would probably be my preference if a notification was included when
> the functionality was disabled.

Yes, I think in the long run, as it doesn't appear there will be any 
universal solution (except # 3 which I think is to mickey-mouse) the 
most graceful thing would be to detect what will work at the edit 
screen step, and if file or mime_content_type is not going to be 
available, then replace the Import feature with a note explaining why 
they can't import and will have to stick with upload.

>
> #3 might be nice as well except you still have the problems from
> earlier, such as:
> - Windows servers won't work with the "workaround" as you pointed out.
> - Some Linux and Unix systems don't provide the "file" command either.
> It would break there as well.
> - It's somewhat "hackish" and requires quite a bit of workaround for 
> you
> to implement properly.
>
> Therefore, I wouldn't do #3 unless you REALLY NEEDED this functionality
> at all costs.  Option #2 removes some ambiguity but still provides a
> clean implementation of the built-in PHP functionality.
>
>
>> What I wonder if, is there is something in the phpws api that will do 
>> a
>> similar job for me, that I am not aware of? Keep in mind, I'm dealing
>> with a file already on the server, not one being uploaded.
>
> I don't know enough about the "deep parts" of the api to answer this
> one.  I'll let the experts handle it. :-)
>
> Good luck!
>
> Greg
>