Hi,

How many people here have access to PHP? I have just started using it on my machine, and have found it very good....

If I were to make mods written in PHP, would they be usable.

Quite a few people use it, but for limited purposes.

I don't use it on any user areas, but it's great for Admin stuff. I tried the forums and other programs in it, but don't think it's there yet. Right now I see it as a more advanced form of SSI.

It's still evolving, and PHP4 is going to be quite different from PHP3, somewhat of a total rewrite, rethink, and it's based on the ZEND engine. It will behave differently.

PugDog,

PHP4 Beta 3 is out at the moment. After playing around with it I think that programs using both Perl and PHP can be very useful.

Perl's regex's etc are better, but for other things - PHP is much more efficent.

I haven't tryed this yet... and I donno how you could get it to work as the page would have a php extension, do you know how you can setup something like this???


Anyway - When PHP4 is officially released I am sure there will be more documentation.

------------------
Michael Bray
Review your webhost or find a new one.
www.webhostarea.com
Links SQL User
------------------






[This message has been edited by Michael_Bray (edited February 19, 2000).]

Because PHP is _server_side_ and depends on the file extension, not the content header, and the content header is what the browser needs to know what to do with it, the type should still be "text/HTML" shouldn't it?

Servers decide what to do with a file based on it's extension (MIME-type) or location (scriptalias directory). The browser decides what to do with a file based on the content header sent by the server based on the MIME-type determined by the extension.

By the time the file hits the browser, there is no "php" code in it, it's all been replaced.

So, what the Links scripts need to do is write out the templates as .php files, not .html files. (just like you'd write out .shtml for SSI).

Wherever you wanted PHP to do some work, you'd have to put the tags in, just as you would Javascript or SSI. Then, you'd have _TWO_ sets of replacement tags. One set that Links would replace when it generated the "static" site, and the second set that is the PHP that is used when the "static" site is accessed.

To get Links and PHP to work together should not be hard -- PHP is just a scripting language that does something where you tell it in the "HTML" file that is sent back to the browser.

For instance, if you wanted your home page to insert the last 10 accessed links in your site, you could make it a .php3 file, have links write out an index.php3 file, and use a snippet of PHP code that accesses the database, and asks for the 10 files with the most recent time stamp, then displays them.

Think of it as SSI on steroids (at least at first) then you can expand it into programs the same way people got Lotus 123 to do everything except add up numbers





------------------
POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/

OK then,

What I was trying to get done was having PHP code done parsed by a .pl file which I wanted Perl to parse as well.

I wasn't thinking to clearly at the time, and come to think about it -> Even if it did work - you wouldn't get a speed increase as you are limited by both types slowest factor

Oh well - Creating a .php file will do

------------------
Michael Bray
Review your webhost or find a new one.
www.webhostarea.com
Links SQL User
------------------

Too many late nights

If you are running a perl script, there is no reason - or need - to call PHP, since perl can do it all.

The reason for PHP is in the web pages, when you want to add dynamic content, especially for smaller things, you should see a speed/performance increase over using pure .cgi to generate the whole site.

This is _only_ if you need/want dynamic content on each page load. Nothing is faster than pure .html kick-the-page-out-the-port serving.

PHP has some advantages when working with MySQL -- it has really been set up to do that (as the phpMyAdmin program shows).

The question, as Alex brought up, is -- for "serious" work, is emb_perl better?

WWWThreads with mod_perl FLIES! The PHP Forum software I tried didn't come close, nor did Sporum.

The _problem_ I'm going to have, is by shifting so much to the MySQL database, am I going to bottleneck there? Right now -- NO. Accesses are still _FAST_.

 How about the common Links question, "how do I add SSI to my .cgi pages?" Wouldn't that be a good place to incorporate PHP into Perl, assuming the SSI in question could be worked into PHP?

Dan

Yes, _that_ is where the PHP seems to have advantages.

What I meant in the last post, is that if you are running a perl script anything.pl there is no need or reason to output a .php file to the browser -- just do it all in perl.

If you are building the Links site, using the perl scripts, building php into the pages, and setting them to .php3 to "run" when the user accesses them has possibility.

Before going crazy... check out emb_perl.

There have been 2 releases since I've last checked it out -- and the Documentation is finally there.

The advantage is you won't have to learn two languages to do the ordinary tasks. What can't be built in emb_perl can be built in perl, so it might take the place of PHP. If so... that's one less thing to have to learn and keep track of.



------------------
POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/

PHP rocks for database use and easy dynamic content but PERL is _obviosuly_ a proper programming tool.

I've use it evey day @ work and more importantly on a [18 months old] 1.x version of Gossamer Threads to serve up dynamic content on the LHS/RHS of the page, leaving the clever stuff to Perl for the links engine.

As a matter of interest, the templating available with v2.x of Gossamer Threads, can I just pop php into there and get apache to parse it, or will I need to do some modifications?

I've never tried it, but you should be able to just change the "build" extension to .php3 (or whatever your server parses) and then it will build.

I don't think this will work with dynamic pages for the reasons above -- the perl process is generating the page.

That means I do not think php will run inside the search or add or user forms.

You'd need to rewrite those _in_ php, and save them to the server as php extention files, and then "run" them when they are called for.

Is this making sense?

If you are running a CGI program, you have eliminated -- and bypassed -- the need for any sort of server side scripting. Just do it all inside the cgi script.

If you are building static pages you want to change on each read, then you use PHP or emb_perl or SSI to allow the pages to appear to be dynamically built.

Hope that's clear.... I think some people are getting hung up trying to make a cgi script output a php page that the server will parse as it's being output.



------------------
POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/

pugdog>
I don't think this will work with dynamic pages for the reasons above -- the perl process is generating the page.

Absolutely,
from memory, the version I currently use has a number of pages that are perl dynamic (the signup is the only one I could think of) here it's only static stuff (unless I get around to using Perl DBI)

pugdog>
You'd need to rewrite those _in_ php, and save them to the server as php extention files, and then "run" them when they are called for.

Is this making sense?

Yes, I'll give that a go when I start coding it again

Thanks

;D