phpwebsite-developers

[Phpwebsite-developers] SourceForge support Issues

[Greg M. <drk...@co...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matt,

The issue of SourceForge support issues was brought up in the IRC
channel.  Please see the log here
http://www.phpwebsitemanual.com/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=103&date=20050723.
 SF has prevents -comm from doing many things.  So I raised the question
of another web hosting company providing support for the -comm wiki and
a later phpWebsite and blindman1344 wiki.  mhnoyes said I should bring
it to your attention.  Several people have offered free support for the
hosting.  I know that singletrack, wendal911 and blindman1344 have all
offered.  One of the issues with the wiki doc being in mediawiki is that
the -comm site then does not eat its very own dog food.  I agree and
know the issue.  However, at the same time I tried doc book using to
extend what you guys had already provided.  It sucked big time.  I just
didn't have the patience figure it all out.  However, with the content
management angle of phpWebSite and wiki they both lower the barrier to
produce  documentation.  I have gone on to collect FAQ material from the
forums.  I use the forum posters question and then create or reference
existing wiki doc.  It has been effective for me in answering the same
forum post over and over again.  The problem now with the SF web service
is that the page may not paint when a user goes to the answer.  Hence,
my question about the hosting issue.  Where should the -comm site be
moved to solve these problems?  I don't see an issue with the SF release
tools, etc so they can still be used but the capabilities of SF short
change what we can show for phpWebSite.

Greg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFC4qrnxyxe5L6mr7IRAv09AJ4+VEbha5+CflYjWZFB2QO/xK2hCwCgogzs
plpCsvl6pwQBDZdtgzFm84s=
=53WC
-----END PGP SIGNATURE-----

[Phpwebsite-developers] Finding mimetype best practice

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

Hi :)

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. Some poking 
around the user comments on php.net showed me the following function, 
which seems to work well on my second server...

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.

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)

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.

FYI... the module feature I am referring to above is one that I am 
calling an 'Import'. Basically, it allows the user to select a file 
already on the server (likely uploaded via ftp for instance) and 
register it with the module. By register it, I mean check the file for 
the correct/allowed mimetype, capture the mimetype, name, and size, and 
write it to the item's record in the db. I have provided this option as 
some users of the module could often be dealing with files larger than 
most servers max_upload_size.

Thanks for any thoughts,
verdon

Re: [Phpwebsite-developers] Finding mimetype best practice

[Greg T. <gr...@ta...>]

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=20
> of a file already on the server. In my initial attempt, I used...
>=20
> $type =3D mime_content_type($file);
>=20
> Then I discovered that mime_content_type may not be available in all=20
> php builds, and/or that it may not be enabled in php.ini.
...

> However, I suspect this will not work on a windows server.
>=20
> That leaves me with a couple options...
>=20
> 1) go with the above solution which I think will work for most people,=20
> and provide documentation for the rest
> 2) use function_exists('mime_content_type') and if it doesn't exist,=20
> don't even offer the module feature to the end user
> 3) use function_exists('mime_content_type') and if it doesn't exist,=20
> 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.

#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=20
> similar job for me, that I am not aware of? Keep in mind, I'm dealing=20
> 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

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
>

Re: [Phpwebsite-developers] Finding mimetype best practice

[Shaun M. <sh...@ae...>]

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.

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.


Shaun
aegis design - http://www.aegisdesign.co.uk