Displaying Images form a Directory

Hello again,

I finally got the mime_magic stuff to work. I ended up
editing php.ini to get it to work.

The following line was commented out so all I did was
uncomment it.

extension=php_mime_magic.dll

Also, I had to add a section with the following item:

[mime_magic]
mime_magic.magicfile = "C:\path\to\PHP\install\extras\magic.mime"

The following code works very well, but I still like the glob()
function more.

// view the mime type
$rpn = "23939.jpg";
echo mime_content_type($rpn);

returns "image/jpeg". Also, if the file is named 23939 without
the .jpg extension, mime_content_type('23939'); also returns
"image/jpeg". I tested dropping the extension on a .gif file as
well and it correctly returned, "image/gif".

Hope this helps.

Jim Carlock
Post replies to the newsgroup.

header ( 'Content-Type: ' . image_type_to_mime_type ( $img ) );
readfile ( $img );

$img is the relative path to the image file. Let's say you use this tree:

/directory_for_everything
/directory_for_everything/directoryforstoringimages
/directory_for_everything/directoryhttpexposed

If your script is stored in the last directory, then $img =
'../directoryforstoringimages/nameofimage';

Hope it helps.

feo

"Jameson" <jameson_ray@comcast.net> escribió en el mensaje
news:1136134747.652428.106160@g44g2000cwa.googlegr oups.com...
> Happy New Year, Everyone!
>
> I am trying to figure out how to display a bunch of images (mainly
> JPEGs, but possibly a few GIFs and PNGs as well) that are stored in a
> local directory on the system. I can do this with the glob() function,
> but I can't seem to put in a directory other than one within the
> webroot. For example, I can only put "/uploads" and not
> "/Volumes/jray/Pictures...".
>
> Any ideas how to get around this? If I can't use the glob function,
> it's fine, but I only want images to be displayed (and not any other
> file that happpens to be stored in that directory).
>
> Thanks in advance!
>

Hi Jim:

Thanks a million for all of the help. I think my PHP installation isn't
set up right, because it seems like anything that I try do do with
images doesn't work very well.

I might try making a symbolic link (like a shortcut on Windows) in the
directory. I know it isn't as ideal as if I could get the directory
parth to wrok with the glob() function, but it might be all I've got at
this point.

I'm glad you got your mime_content_type to work. Sometimes we get lucky
and it turns out to be as simple as uncommenting a line.

Thanks again for all of the help!

Jameson

Jim Carlock wrote:
> Hello again,
>
> I finally got the mime_magic stuff to work. I ended up
> editing php.ini to get it to work.
>
> The following line was commented out so all I did was
> uncomment it.
>
> extension=php_mime_magic.dll
>
> Also, I had to add a section with the following item:
>
> [mime_magic]
> mime_magic.magicfile = "C:\path\to\PHP\install\extras\magic.mime"
>
> The following code works very well, but I still like the glob()
> function more.
>
> // view the mime type
> $rpn = "23939.jpg";
> echo mime_content_type($rpn);
>
> returns "image/jpeg". Also, if the file is named 23939 without
> the .jpg extension, mime_content_type('23939'); also returns
> "image/jpeg". I tested dropping the extension on a .gif file as
> well and it correctly returned, "image/gif".
>
> Hope this helps.
>
> Jim Carlock
> Post replies to the newsgroup.

"Jameson" <jameson_ray@comcast.net> wrote:
> Thanks a million for all of the help. I think my PHP installation
> isn't set up right, because it seems like anything that I try do
> do with images doesn't work very well.

Hi Ray,

If you're as curious about how things work on a Windows NT
system as I am about how they work on a Mac, perhaps we
could continue and see if we come up with something.

For instance, are you doing all this on a MacIntosh system? I
see your posting to the newsgroup using a MacIntosh. That's
where my questions must start.

X-HTTP-UserAgent:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en)
AppleWebKit/416.12 (KHTML, like Gecko) Safari/416.13,gzip(gfe),gzip(gfe)

Apache gets installed as a "Service" on any NT system. How do
you start and stop a web-server on the Mac?

Here we either click on Start, Run then type in services.msc, or
we open a command prompt and type services.msc, or we open
a command prompt and use the following commands to start and
stop the service...

net stop Apache
net start Apache

The services.msc provides the GUI interface and opens a window
whereby you can right click on each listed service, then select "Stop"
or "Start" or get into the service "Properties" to set the Autostart
stuff.

The PHP stuff loads when Apache starts. That's the only way
it gets loaded. The executable, php.exe, isn't even in the PATH
environment variable. So the PHP install folder holds some files
but everything to load gets identified in the PHP.INI file. I forgot
to mention something about the "extension_dir" line found in
PHP.INI:

extension_dir = "C:/WINDOWS/system32/"

This line positively identifies the location of the folder which
holds the extension files. Shortcuts to .dll files do not work on
a Windows system, so the actual .dll must reside in the folder
specified. Also, the path must be specified using the forward
slash, even though Windows itself uses backwards-slashes to
denote a path to a file.

So I ended up using the "net stop Apache" and "net start Apache"
to test things. The "net start ..." and "net stop ..." commands are
extremily useful on any Windows NT system (NT, 2000, XP,
2003).

So my next question is, do you employ a PHP.INI file on a Mac?

You are trying to get this to work on a Mac, right? If you're
unsure of how to answer any of the questions, let me know.
I'm really ignorant when it comes to MacIntosh systems, and
I might be able to ask some easy to answer questions if your
willing to answer some questions. I'm certainly eager to get
answers and explore this, even though no Mac sits in front of
me. :-)

Jim Carlock
Post replies to the newsgroup.

Hi Jim:

Sure, I'd be happy to keep looking into this. Maybe we'll end up
getting it to work.

First off, I am doing this on a Mac. Apache comes built in to OS X (I
believe as a service), and I installed PHP from an install package.

There is a PHP ini file on the Mac, although I've never had to edit it.
I used to run a Windows 2000 server with PHP on it, and I had to edit
the PHP.ini file quite a few times.

Restarting Apache on the Mac can either be done through the command
line or System Preferences. I tend to do it from the GUI, but I think
that "apachectl restart" will restart it from the command line.

There was actually something that I was wondering about your last
version of the script. If we take a look at it...

<?php
$dir = '.';
$sAltText = "Picture";
foreach (glob("*.jpg") as $file) {
echo "file: $file<br />\n";
echo "<i>filename:</i> <b>$file</b>, <i>filetype:</i> <b>" .
filetype($file) . "</b><br />\n";
echo '<img src="' . $file . '" border="0" alt="$sAltText" /><br />' .
"\n";

}

?>

....Let's say we set the directory to $dir = '/Users/jray/Pictures'; (a
path that I can browse to just fine from the command line). Where is
the $dir variable used in the rest of the script? If a directory is
specified in the glob() function, I believe it just defaults to the
directory that the script is in. Did you have a different experience on
your end?

Thanks again for sticking with this. Sometimes is is good to have an
understanding of how a function works across different operating
systems.

Jameson

"Jameson" <jameson_ray@comcast.net> wrote:
> If we take a look at it...

<?php
$dir = '.';
$sAltText = "Picture";
foreach (glob("*.jpg") as $file) {
echo "file: $file<br />\n";
echo "<i>filename:</i> <b>$file</b>, <i>filetype:</i> <b>" .
filetype($file) . "</b><br />\n";
echo '<img src="' . $file . '" border="0" alt="$sAltText" /><br />' .
"\n";
}
?>

> ...Let's say we set the directory to $dir = '/Users/jray/Pictures';
> (a path that I can browse to just fine from the command line).
> Where is the $dir variable used in the rest of the script?

I used the $dir in one of the scripts and forgot to take it out this
one, or perhaps left it on purpose (unknown reason). :-)

The single dot indicates the current directory, two dots indicate
the parent directory of the current directory.

$dir = "..";

You could also use it as the path to the folder you want to parse
and applie the file exstension inside of it...

$dir = "../*.jpg";

> If a directory is specified in the glob() function, I believe it
> just defaults to the directory that the script is in.

That's exactly the way I see it. No difference. I find it much
better to use relative paths right at the moment, using

"../images/*.jpg"

to get to the folder in question, rather than absolute paths,

"/images/*.jpg"

The script would read...

<?php
$dir = '/images/*.jpg';
$sAltText = "Picture";
foreach (glob($dir) as $file) {
echo "file: $file<br />\n";
echo "<i>filename:</i> <b>$file</b>, <i>filetype:</i> <b>" .
filetype($file) . "</b><br />\n";
echo '<img src="' . $file . '" border="0" alt="$sAltText" /><br />' .
"\n";
}
?>

As long as the web-root is set up properly, the "absolute
path" works fine on a website... let your root path be
'/Users/jray/' and the php file resides in, '/php', the images
reside in, '/images/'. So a php file in the php folder could
reference image files by using '../images/img.jpg' or
'/images/img.jpg'.

If you employed Explorer on a Windows system, you could
change from the currently viewed folder to another folder
by typing in ..\WINDOWS, or "..\Program Files\", or
...\WINDOWS\system32\ into the address bar. Someone
had a patent or some such on using the slash to denote paths.
Thus Microsoft patented the backslash concept (don't quote
me though as I can't identify the source read years ago and
maybe my mind plays tricks on me).

It works the same way on Unix systems but you change the
backslashes to forward slashes.

I imagine it works similar on a Mac, but I'll let someone
with Mac experience confirm it. Let me know.

> Thanks again for sticking with this. Sometimes is is good
> to have an understanding of how a function works across
> different operating systems.

Yes, especially when it all jives together and works in the
same or similar manners.

Hope that helps.

Jim Carlock
Post replies to the newsgroup.