Gossamer Forum
Quote Reply
Plugins.
OK,

I know the plugins are cool, and I plan to use them - just one thing I thought I would recommend, and I am guessing no one else is going to support this - but I'll say it anyway, and that is to somehow have PHP plugins supported.

Must of you are Perl fans, and Perl has its place on the web - but for users that don't have access to Mod_Perl, PHP is a very good solution... For a site I am developing, I am going to use Links SQL & all add ons will be done in PHP - so I thought that the if the plugin system supported PHP stuff then those mods, plus other ones would be much easier to release.

Anyway - I don't really know how the plugin system works enough yet to know if this is a possibility - I will probably hack in the feature somehow if it isn't added - its just that I know you guys at GT could code it better then I could.

Cheers,
Michael Bray

Discuss webhosting at
<a href="http://www.webhostarea.com/forums/">The Webhost Area Forums!</a>
Quote Reply
test In reply to
Signature stuffed up :)

Just testing...

Discuss webhosting at
The Webhost Area Forums!
http://www.webhostarea.com/forums/
Quote Reply
Re: Plugins In reply to
Hello Michael,

I don't know how PHP works yet and don't know about plug-ins yet but i support you Michael!
Because i quess PHP is much easier then perl/mod_perl, so we will get many plug-ins to use
and not only the 'Pro's' can make plugins but we all can.
So the 'Pro's' can get some rest because we divide the work and we are all happen Smile!!!

So you got my vote!

Regards startpoint.

Quote Reply
Re: Plugins. In reply to
I'll say something that will make the Perl people even madder. How about supporting ASP!

Randall

Quote Reply
Re: Plugins. In reply to
Hey.... if you can't use your real name, don't post things like that!!! <G>

But, remember, PHP is _much_ more limited than PERL. PHP is a server-side scripting language. PERL is fully functional programming language/interpreter/compiler, and mod_perl is a way to embed that into the Apache server, and access all the Apache:: modules.

The next version of Links should be close to Apache modules as you can get without using the Apache interface (for compatibility). If the modules can be pre-loaded, in a startup.pl script, then for all intents and purposes, Links SQL will be part of Apache.

PHP provides a reasonable way for the display pages to access data, and do things, but it can't do the same type of "builds" that Links/Perl does.

I've played with this over the past few months, and still can't find a place or a way to integrate PHP into my sites. I've toyed with it, and tried add-ins in PHP, and such, but keep returning to perl-based solutions.

I guess I don't like the embedded scripts in the HTML, it's going backwards from template-based I/O.

I just haven't found anything I can do in PHP that I can't do in perl -- even perl-script SSI is possible, with emb_perl and/or your own private modules. The more I read about the integration of perl/apache/CGI through these modules, the excited I get as to how finely tuned the site can get.

I still see PHP as a front-end, offering dynamic page content, possibly replacing the .shtml type pages. I've seen it work pretty well with forum type software, but It seems to start to break down with more complicated applications, both in the application development cycle and in the implementation cycles. It might get worked out over time, but part of the reason web ISP hosts can offer PHP but not mod_perl, is one indication of the differences in capability that is possible too.....

http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/

Quote Reply
Re: Plugins. In reply to
Sorry for the anonymous post. I'm using a different computer and wasn't logged on. I guess alex had temporarily set that thread to accept anonymous posts as I see you can't do that now.

Randall

Quote Reply
Re: Plugins. In reply to
Pugdog,

I see your point - I realise that PHP can't do alot of stuff that you can do with Perl, but it can do all/most off the stuff that Links can do. As a learning experience, and because I wanted to use my license on another site I am making - I rewrote my site in PHP/MySQL from Links SQL - and it can do everything that I had Links doing + more on the admin side.

One thing that I like about PHP is that the code is very readable (try understanding some of the stuff in those modules from the new Links SQL :) ). Another thing is that development time is much better then Perl - If I had to do the same thing in PHP as I did in Perl, PHP would be developed a lot quicker.

Last of all, I reckon that PHP is faster then Perl for something things, not all things *when* you are not using Mod_Perl. My site isn't busy enough for me to be able to do too much testing of this though. On my site I think that the cgi-bin folder is not even being used anymore :p

Back to the point of the plugins - If it is possible to make PHP plugins possible, I don't see a reason why it shouldn't be done. For things such as a review addon, PHP would be the best solution for some people. After putting more thought into it, it would be more difficult then I first thought to make the plugins work with PHP - but it would be possible.

Discuss webhosting at
The Webhost Area Forums!
http://www.webhostarea.com/forums/
Quote Reply
Re: Plugins. In reply to
While PHP support is a good idea...I don't know how GT feels about this. May be Alex will be able to shed some light...from the looks of it...the new core module system may be effective for other applications like PHP, but it is too soon to say.

BTW: It is a myth that you only can execute CGI scripts in your cgi-bin...most servers are configured to execute scripts anywhere within your account directories.

Regards,

Eliot Lee

Quote Reply
Re: Plugins. In reply to
Well... funny... but I find PHP to look more like line-noise and garbled gook than even OOP modular perl :) (At my age, that is a really odd realiziation!)

As Eliot pointed out, you _can_ run perl from anywhere on your server, _if_ the configuration is set up that way.

You can either allow it to be overridden in the .htaccess files on a directory by directory basis (safest on a trusted server) or granted in the main configuration on a per-directory basis (just as good, since it still limits scripts to authorized directories) or you can just enable any program with a .cgi or .pl extension to be executed anywhere from any directory.

But, that becomes a security problem!

I have tried to write in PHP, and while PHP may appeal to some people, I can't get the hang of it.

To me, it's like prototyping in basic, perl is more like Pascal, and then you still have the C/C++ guys.

For me, PHP is more like programming in Dbase or Paradox. I never quite got the hang of it, even though I managed to turn out some pretty good applications. I seem to have gotten the hang of Perl, at least 80-90% (believe me, I don't even _TRY_ to write poetry or play with one-liners).

I see PHP as the fancy interface. I have problems with it trying to run a site, since I prefer SCRIPTS to run a site, rather than a collection of "pages" that are scattered around. PHP violates my sense of order, and everything I"ve worked to learn over the past 20 years. That doesn't make it "bad".... it just limits it's usefulness.

Like trying to make a Lotus spreadsheet do everything under the sun (and if you are over 30 years old, you _KNOW_ those people!), I just don't think it's worth it. PHP has a place for dynamic pages. I don't see it as an application development platform, for a number of aesthetic and problematic reasons.

Just because it _can_ be done, doesn't mean it _should_ be done :)

http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/

Quote Reply
Re: Plugins. In reply to
Yeah - But remember you don't have to work it like that. I am personally trying to make my site work along the logic of Links SQL - just using PHP/MySQL.

You can have php files that only have functions in them - output no HTML. For example, I have a file, security.php which has a dozen or so security functions, which allow me to handle .htaccess/.htpasswd files, allows to me to set user privelages and passwords for my sites and handles admin logins etc.

Then there is a html.php which handles the template system, and basically any output by a script - then there is the mysql.php etc as well. This way the code is easy to handle - and on the HTML pages you basically have...

<?php

# Required Files.

# load the header template.
template(header);

# load an ad.

showad(468x60);

?>

All the HTML junk here

<?php

#Show the top ten posters on the forum.
topten();

?>

More HTML.

<?php

template(footer);

?>

As you can see - you don't have to go through and put all the code on each page - which would make it a mess to handle. This is basically like using CGI & SSI, except its PHP, so if you are in a rush you can add some code to the page, instead oad adding a function and linking it all together.

I guess its just a case of the language that best solves your problem. For my sort of site - which is alot of dynamically created pages, PHP is the best solution.

When I mentioned that I didn't have anything in my cgi-bin, I was trying to say that I wasn't running any Perl scripts, rather then the fact that the directory was empty :)

Discuss webhosting at
The Webhost Area Forums!
http://www.webhostarea.com/forums/
Quote Reply
Re: Plugins. In reply to
And I'm more comfortable doing that in Perl .... maybe even emb_perl (if I dare!).

It's a way of thinking, too.

Why have the HTML page and server do the work, when I'm really trying to output a page, and just want the server to serve it, but to create it via a script.

I much prefer perl + templates.

I just can't seem to find an application I can do with PHP that I can't do with perl.

I do prefer PHP to SSI, but that is a great way for me to have a "static" main page, that is dynamically updated.

I guess I'm also not convinced how much "dynamic content" a user needs. I've tried to minimalize -- and streamline -- what the user sees, and reverse the trend of adding more and more content/options to each page. The next generations of the sites I'm developing will reflect that.

I really think users want to do things, then push a button, go back to where they can make another choice to do something else. If they can do everything from every page, they start to get confused, and disoriented. Supermarkets are great, but sometimes you just want a bake shop, or deli, and you don't want to be bombarded with produce, packaged goods, household items, etc.

http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/

Quote Reply
Re: Plugins. In reply to
I have to disagree with you on that one,

I think that users should be able to access all/most of the options quickly, rather then having to push 10 dozen buttons. Dynamic content, if used properly, is very good. You could pull useless stats from somewhere and print it on the screen for the sake of having dynamic, and I agree that is useless. But if you have a legitimate use for it on your site - then what is wrong with it?

I guess you dislike of dynamic content is what you could make you not really like PHP - as it is definatly aimmed towards the dynamic content sites.

Discuss webhosting at
The Webhost Area Forums!
http://www.webhostarea.com/forums/
Quote Reply
Re: Plugins. In reply to
Don't get me wrong.

There is only a limited number of things a person needs to do at any given time.

I think the failure of most "high tech" sites is that there _are_ too many options.

Then, there are sites with too few options, and the need to do the same keystrokes over and over.

What's dynamic content? In the forum, some people asked for a clock to figure out the 'relative' time. Fine. But I don't need a site to tell me it's TUESDAY when I look at my computer, and see it's already Wednesday, or that it's still Monday.

Usually, since my clock is synced 30x a day, what I find is _their_ clock is off by sometimes a good amount.

Do I really need weather, news, and how many users are logged in on my screen? Depends on what sort of site it is. If I am at weather.com I would _hope_ to see weather on my screen. If I'm nosing around shareware.com _I_COULD_CARE_LESS_.

Is this making sense? What I hate is dynamic content for the sake of dynamic content. If you wander the net, there are some great looking pages, with great stuff on them, and I will never go back. Neither would you.

Dynamic content is _NOT_ what the game is about. It doesn't make pages look "alive" it often makes them annoying, disconcerting, or bothersome.

CONTENT and/or SERVICE is what the game is about. If you offer something people want and/or need, and you present it cleanly then you have a useful site.

I visit many of the monolithic software and hardware sites on a regular basis. Their cgi-scripting is wonderful, it's impressive, and 9 times out of 10 it takes me longer to find what I'm looking for -- if I can find it at all!

I want to see a SEARCH box, and I want it to work.

When I look at the traffic to my sites, that's what _most_ people want as well.

They want what they want, when they want it, and only what they want.

Giving them more just annoys them.

But, there are differences in philosophy, and that is why there are so many choices.

But, I learned my lesson (a lesson my grandfather tried to teach my uncle before I was born) when I was able to break up a collection of 9 different things being sold for $35 (for example) and break it up into it's 9 parts, and sell MORE OF THEM, and sometimes even MULTIPLE PARTS to the SAME PERSON for $50 each... I learned my lesson well. They only wanted part #3 and would pay MORE for it, rather then get all 9 parts for _less_ money.

People want what they want, and only what they want, when they want it.

See, you can even say it differently, and the song remains the same. :)

This is the problem of the web. And of dynamic content. And of multimedia web pages. And of all the stuff that people go "WOW" to once, then get flat-out annoyed having to go through each and every time they log in.

So, yes, dynamic content has a place, but TARGETED content is the future of the Internet, and that can be dynamic, psuedo dynamic, or even static. I've got some non-changing web pages that have been hit 10x more than anything I've got dynamic, simply because the content is relevant to what people are looking for, when they visit that site.

I guess this is what I don't see with PHP as a web site building tool.

The only PHP program I have found useful was phpMyAdmin, and with the MySQLMan program, even that has become problematic. And why did I use it? It gave me what I wanted, when I wanted it, and only what I wanted :) (Once I went through the gymnastics of compiling PHP into my server, that is.)

I've been around too long, and my age is starting to show.

You know what the _best_ example of "dynamic" content was that I've found in months of travelling the web? When I logged back into Netflix a few weeks ago, and when I clicked on "What's playing now" it gave me the listings for _MY_ neighborhood, without me entering a SINGLE THING! (Of course it had my zip code.) I was absolutely stunned, and impressed, and had to flick back and forth with it. Why? ... again.... it was exactly what I wanted, when I wanted it, with nothing I didn't need (like movies _not_ playing near me, etc.) And it took me by surprise. A major upgrade that was actually USEFUL and USER FRIENDLY, and didn't require any input on my part to serve up. I'm actually still impressed with it. Simple, clean, and useful. So un-Web-like <G>.

Oh well, time for bed. Too many late hours.



http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/