Viewing PHP pages

Hi Scott,
It works as designed. Safari renders HTML and XML. Pages written in php are not rendered by Safari. PHP is a scripting language, which is executed by the webserver, or as a cgi-bin invoked by the wqebserver, not the webbrowser.
More info on php is widely available on the internet, but I suggest you start with http://www.php.net/

You can view the pages on your machine if you turn on the websharing, but I gather you've done that already

If web sharing is turned on type:
localhost/~scottfeiner/Sites/Pandeiro/site/index.php
in the adress bar of Safari.
I don't use dreamweaver, but probably, the php engine of Dreamweaver is at fault here, not Safari (it never endered php on my machine).

Hi Scott,

PHP-processing of local web pages by OS X's built-in Apache webserver is not enabled out-of-the-box. It's possible that your Tiger upgrade over-wrote the Panther Apache config file </etc/httpd/httpd.conf> which must have had PHP enabled.

To (re-)enable PHP, edit this text file:

/etc/httpd/httpd.conf

Uncomment out these two lines, by removing the leading hash character:

#LoadModule php4_module
#AddModule mod_php4.c

You'll need to restart (stop, then start) the "Personal Web Sharing" Preference Pane.

To test:

1) put a text file called "test.php" containing one line:

<?php phpinfo(); ?>

in your "Sites" folder located in your home directory.
Open your browser and go to:

http://localhost/~Your-Userid/test.php

best of luck,
...ben

Scott F.,

I'm with you on this. A page that ends in .php with no actual php code on it should still show up in Safari when viewed locally without personal web sharing turned on. It used to before Tiger and it works in Tiger with Explorer. Lets face it, it's not correct and we shouldn't have to use workarounds to make it function properly. But, unfortunately it appears that we do.

I'm not quite sure if I agree.
There are a couple of ways Safari, or better the Apple WebKit, can decide how to display a page. If you open a text document in Safari, it has no prior knowledge whether it is a html document, or any other kind of text type document. If a document isa served out by a sarver, it gives it a nine type, being 'text/html', OSX only knows if the file is text, binary, a picture etc. The magic of the file being a text file, and the extension being '.php', Safari decides it is opening a document which doesn't have to be rendered. So it takes the rendering hint from the extension.Which stands to reason, since Safari has no prior knowledge about the renderabilty of the document.
Safari here decides on the strict side;no prior knowledge, ergo I won't render.
I don't see this as incorrect, but then again, I do understand the sentiment. Given the file only has HTML in it, why don't you render my dear Safari?

Hi Scott,

Can we take a step back for a moment?

PHP is a server-side web-scripting language. On a PHP-enabled webserver, pages ending in .php are parsed for
b <?
and
b ?>
tags. These tags are processed, the actions performed, and
b only then
is the webpage sent to the web-browser. When the web-browser receives the .php page there are
b no longer
any
b <?
or
b ?>
tags in it. So even if the browser understood how to process PHP tags, there are none in the page it receives. You can verify this when you do a
b View Source
on a .php page from a working, PHP-enabled webserver.

I have
b never
heard of a web-browser that had a built-in PHP processor. Is it possible that DreamWeaver has some sort of a PHP processor built-in?

With respect to feedback to Apple, it would be nice if Apple had the resources to read all these postings, but unfortunately they don't. For feedback to Apple, we have to explicitly send it using one of their feedback pages, viz: http://www.apple.com/macosx/feedback/

very best regards,
...ben

Hi Scott,

Ahh... the penny drops. You want to set the filename extensions which Safari uses to know when to parse a page for
b HTML
tags!

I'll have to research this. But in the interim, have you tried other browsers?

very best regards,
...ben

Hi Scott,

I haven't looked yet for how to set the filename extensions for which files
b Safari 2.0
will look into and parse any
b HTML tags.

However there appear to be lots of other browsers that exhibit the behaviour you need right out of the box. For example I created a file called
b test.php
containing these two lines:

<html>
bold text

When opening this
b local
file, the following browsers all parsed the
b HTML,
despite the
b .php
suffix.

firefox 1.0.4
omniweb 5.1
camino 0.8.4
mozilla 1.7.7

I didn't have a copy of iCab or Opera installed to try. By parsed the HTML, I mean these four browsers returned:

b bold
text

and
b not

<html>
bold text

I hope this helps,

best of luck,
...ben

Ok, I've seen te light.
Still I'm not sure whether the rendering of pages locally is a clear problem.
I can't look in to the minds of the Apple Development Team, but I can feel their rationale. The problem isn't quite as simple. Safari renders through the WebKit. However, more applications rely on the webkit for rendering, and I'm not sure if it is appropiate behaviour for, e.g. Mail.app, to render all text it reads which contains pure HTML.
This is complicated by the fact that OSX relies on the magic number and the file suffix to find appropiate appliication bundles to handle them.
I am sure however, that i've never found any binding regulation that states that pages only should be rendered locally if they have the .html or .htm suffix.
(I admit, somewhere in the eightes of the last century I made a recommendation to dictate that html pages always had a .html suffix, just to spite my colleagues who tried to convince me that MS was worth looking at, so I'm not completely unbiased).
Apart from the above statement, I described the .html/.htm suffix as best practice for static content at the company I worked for. I still feel that to be the best practice. Just as using the .php files for files that contain php statements etc. etc.
Realize also that most WebServer just serve the content of a file with the .html/h.htm suffix with the "text/html" mime directive, but tend to serve text files with another suffix as text/plain, or let de WebServer process them (as is the case with the .php suffix, or the .asp suffix on IIS Servers). This processing, even if the file doesn't contain any executable statements, takes up CPU cycles. For a small site not a very high cost, but larger sites, with lots of hits, can seriouisly degrade performance.

just my 2 euro cents