Gossamer Forum
Home : Products : Gossamer Links : Pre Sales :

Lack of Established Mod_Rewrite Option For PHP Version Disappointing

Quote Reply
Lack of Established Mod_Rewrite Option For PHP Version Disappointing
I am a big fan of Links and Gossamer Threads. I have an old Links 2.0 from years ago still running. But since those days when I used to be a regular perl junkie, I have come to really prefer PHP scripts. I just find them so much easier to work with and such a lighter load on my dedicated server.

I really want to upgrade to Links SQL and I was very excited to hear there is a new PHP-based front-end.

But I am very disappointed there is no decent, consolidated presentable .htaccess mod-rewrite hack to produce search-engine friendly URLs. This hack is absolutely critical to having a viable links directory with a PHP front-end. I won't purchase Links SQL without one.

All I find are wisps of threads with a line or two of code and references to go see a thread in the Gossamer Forum section. I've been all over this board for a couple of days now chasing thread after thread. Usually this board provides excellent support, but I've got the impression you're all a bunch of perl programmers who
are used to building/re-building your sites for every update and aren't interested. That's understandable aronud here. Don't take it as a complaint. It's just the environment.

Unfortunately I'm not a hardcore Apache/PHP programmer. Writing mod-rewrites is a bit outside my limits.

But I can't consider buying a $450 script without knowing I can produce SE friendly URLs first using the PHP front-end version.

I really suggest Gossamer Threads step in here and fill this void because the commnuity isn't doing it. It should be provided in the Resources section of the Support area as a regular Modification. Or included in the download pack with the software.

Sean
Scarsdale Technologies, Inc.
http://www.ScarsdaleTech.com
Quote Reply
Re: [spcover] Lack of Established Mod_Rewrite Option For PHP Version Disappointing In reply to
I don't speak for GT, but I remember reading somewhere that the PHP development has all but stopped, and Links SQL is designed to run in perl/mod_perl mode.

The PHP front end was just that, a front end, not a full integrated solution. Most of the "work" was still done by perl.

Also, I have to disagree about the "load" of PHP vs perl (but without a lot of hard numbers, and side by side tests, talk is pointless), and for the "ease" of maintaining or writing. To me, PHP is a *mess*. The whole point of structured programming was to separate the input, code and output into separately maintainable items. PHP has always seemed a major step backwards in programming form, logic and cleanliness.

The origins of PHP were to run a scripting language on servers that had no cgi-bin access. Sort of like perl, it's original intentions were trampled upon, and like the original Lotus 123, it was morphed and modded to do just about anything (except make coffee). The difference, is, perl is a programming language, and has steadily moved more in that direction. PHP is a scripting language, and it can't really be more than that, without the huge effort that went into moving perl over. It also puts the "scripts" and sensitive stuff in the webspace.

That said, GT's programs idealize and epitomize the modularity, cleanliness, reusability, and SEPARATION of form and function in almost any language, but especially perl. The more you program with it, and stick to the reusable, stylistic perl conventions, rather than taking the short cuts that perl allows (and GT makes so tempting <G>) you write *awesome* code, that is reusable, modular, and upgradable. The API is consistent, so programs built upon abstraction or object layers continue to work, even with major rewrites of the underlying code, complete bypassing of the original module, or other plugin changes. (Unlike the Amazon API which is just about going to drive me crazy).

GT's template parser is probably as powerful as PHP in and of itself. It has great built in functionality, plus full access to perl and almost anything else on your system.

If you were so inclined, you could write whole programs within the template, using global and function calls (and end up with a *much* nicer looking, and easier to maintain template/output file).

PHP is for people who:

1) don't have access to perl
and
2) don't have access to the GT engines if they do have access to perl.

On a dedicated server, with mod_perl, and GT's engine code running your programs, you don't need PHP. And, in building dozens if not hundreds of sites, while I've wished for additional features, or ready-made scripts, I've never once wished I could run PHP, or felt I needed it. I don't even enable it on my servers, and I'm trying to wean Andy off it too ;)

My opinion against PHP is at least as strong as yours is for it. :)

All this being said, I don't see why you can't just change the .cgi to .php and use the suggestions given for the page.cgi mod_rewrite rules. But, of course, I have no way to test it out, since I don't have PhP enabled on my servers ;)


It really is just two lines of rewrite code, to make work.


PUGDOG´┐Ż Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.
Quote Reply
Re: [spcover] Lack of Established Mod_Rewrite Option For PHP Version Disappointing In reply to
I'd like to confirm that development of the Links SQL PHP front end has been stopped. It is still packaged with Links SQL, but there will not be any further development on it. If you need a fairly basic Links SQL setup and don't have access to setup Links SQL under mod_perl, then this would be suitable for you. If you need some of the more advanced or newer features in Links SQL (for example, plugins, or the upcoming payment support), then you will have to use the Perl front end.

Remember that you *can* build static pages, which will be search engine friendly. Also, if you set things up properly, you can make Links SQL build the pages as .php files, so that you can insert PHP code in the files to be further parsed by PHP.

Adrian
Quote Reply
Re: [brewt] Lack of Established Mod_Rewrite Option For PHP Version Disappointing In reply to
>> But I can't consider buying a $450 script without knowing I can produce SE friendly URLs first using the PHP front-end version. <<
You can visit our site Need Scripts and you will notice that all the url's are static/search engine friendly. Trust me, Links SQL has been a great assest for our web site and even though it is feature packed, it is very easy to use.

Like Adrian suggestions, you can just setup an option where Links SQL will build pages with .php and so you can use php codes within your web site. Also, for any reason if you prefer to use .html instead of .php then just create a .htaccess with below line in it

AddType application/x-httpd-php .html

and now you should be able to use php tags/codes on .html pages :)

-----------------------------------

Vishal

Vishal
-------------------------------------------------------
Quote Reply
Re: [spcover] Lack of Established Mod_Rewrite Option For PHP Version Disappointing In reply to
You can run LinksSQL with SHTML pages to include dynamic content, and then do a mod rewrite to have those pages appear as html for maximum search engine food. I had my main site on PHP before changing over to LinksSQL and hated it.
Belize Tourism & Country Guide
Belize News
Quote Reply
Re: [NeedScripts.Com] Lack of Established Mod_Rewrite Option For PHP Version Disappointing In reply to
In Reply To:
Also, for any reason if you prefer to use .html instead of .php then just create a .htaccess with below line in it

AddType application/x-httpd-php .html

and now you should be able to use php tags/codes on .html pages :)


is that for real???? I never knew you could do that! Don't know much about re-write rules but it looks like i need to find out more.

r
Quote Reply
Re: [ryel01] Lack of Established Mod_Rewrite Option For PHP Version Disappointing In reply to
All this is doing is adding .html files to the list of files that PHP will parse (so there may be a slight slowdown with normal static pages - probably not significant though, I've never tested it). Note that this only works if your webserver config allows you to override such options.

Adrian
Quote Reply
Re: [brewt] Lack of Established Mod_Rewrite Option For PHP Version Disappointing In reply to
Quote:
is that for real???? I never knew you could do that! Don't know much about re-write rules but it looks like i need to find out more.

Yup.. it is realy..

Tongue Self-promotion Tongue :: Visit Need Scripts (www.needscripts.com/) I am using the same trick and it is working great for me :)


Quote:
All this is doing is adding .html files to the list of files that PHP will parse (so there may be a slight slowdown with normal static pages - probably not significant though, I've never tested it). Note that this only works if your webserver config allows you to override such options.

Well, I have not made *any* changes in webservers configuration, so I would say that normally adding .htaccess file with above line will do the trick and well, you don't have anything to loose by trying.

About the speed, hum... I am averaging more than million page views every month at Need Scripts and haven't seen any noticiable slowdown while using the above .htaccess file. I assume the main reason is cuz I have using Links SQL option to generate static pages, and I believe parse of static html pages takes very very very very resource.

Well hope this helps.

Vishal

Vishal
-------------------------------------------------------