Gossamer Forum
Home : Products : Gossamer Links : Discussions :

PHP Front End to Links SQL

(Page 3 of 4)
> > > >
Quote Reply
Re: [PaulWilson] PHP Front End to Links SQL In reply to
Quote:
which I expected only him to understand
I think you've just perfectly defined poor use of a public forum! Well done. ;)

Dan
Quote Reply
Re: [Dan Kaplan] PHP Front End to Links SQL In reply to
My bad.

Last edited by:

PaulWilson: Sep 15, 2001, 4:50 AM
Quote Reply
Re: [Alex] PHP Front End to Links SQL In reply to
I have created a php gateway for links 2.0 already. http://djgateway.com/?inc=links it has been up and running for 6 months or so.
Alex B Sommerfeld - Owner
Gateway Productions - Professional Disc Jockey
41 Otis St. Danvers Ma. 01923
Home Phone: (978) 777-1285
Work Phone: (978) 762-4661
Cell Phone: (978) 502-5733
E-mail: alex@djgateway.com
Website: http://djgateway.com
Quote Reply
Re: [Alex] PHP Front End to Links SQL In reply to
Dear Alex,

this are good news for all already working with PHP. We are building our pages with PHP, so I had the need to include LINKS SQL in our PHP site. I did it only for the static LINKS-pages and made some modifications (like a badlink-report). Important features like jump are still working as your original cgi-scripts. Others (like add.cgi) I changed to php.

Our LinksSQL modification in PHP can be viewed on http://www.kommunalweb.de

I am looking forward to "LINKS PHP".

Cheers, Susanne

Quote Reply
Re: [zazie] PHP Front End to Links SQL In reply to
Hi,

The main thing about our installation is that it will work with our configuration files. If you change a setting in the admin, or change your SQL configuration, the php front end will work without changes. They will be tied together pretty closely.

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Alex] PHP Front End to Links SQL In reply to
Alex,
What will the performance of the php lsql be in comparison to a server
a) with mod_perl
b) without mod_perl

in terms of speed and resource usage?

account deleted
Quote Reply
Re: [andy_C] PHP Front End to Links SQL In reply to
Here's some crudely done tests on speed...
Note that the PHP frontend is no where close (at least a few more weeks) to being finished, but I've gotten enough to get the home page loading up with categories showing up Smile. So the final version might be faster or slower, but just to give you a taste of what it'll be like:

PHP frontend takes ~0.1 seconds to create the page.
Perl frontend (w/o mod_perl) takes ~0.4 seconds to create the page.

I don't really have mod_perl setup properly on my machine for links sql, so I can't really test the Perl frontend w/ mod_perl. I'm guessing it's even faster than the PHP frontend.

Resource usage? Wouldn't have a clue Tongue. That's more Alex's department.

oh, btw, these were run on a P2 350 w/ 512MB running Apache linux.


Adrian

Last edited by:

brewt: Sep 20, 2001, 4:40 PM
Quote Reply
Re: [brewt] PHP Front End to Links SQL In reply to
Well I decided to go and get mod_perl going on my box... so here's the results:

PHP frontend: ~0.1s
Perl frontend: ~0.4s
Perl frontend (w/ mod_perl): ~0.07s

The home page is not a terribly complex page, so those aren't terribly accurate at showing the differences between them. As soon as I get the subcategories going, I'll post some more peliminary results.


Adrian
Quote Reply
Re: [Alex] PHP Front End to Links SQL In reply to
I'm going to take the plunge and go for the Links SQL 2 upgrade, as it should be the solution so my Links 2.0 flat text blues.

I need to ask a couple of questions though :)

1. If I go ahead and customise the Links SQL system as it stands now, will I have to do it all over again when you finish the PHP implementation, or are they totally separate from each other.

2. How far off are you from finishing? :)

m.

Quote Reply
Re: [Moby] PHP Front End to Links SQL In reply to
Hi,

1. You will need to redo your templates, as the templates will be in PHP, not the normal Links style templates. Any work you spend configuring the program, or inserting data will not be lost, as the back end is identical.

2. We are about two weeks from having a beta ready. Right now displaying the home page and categories are working, just need to go through the rest of the user side.

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Alex] PHP Front End to Links SQL In reply to
Thanks :)

Questions, questions... !

I know my existing database can be imported over to LINKS SQL, but I've added to and removed some of the default fields. Is the import process quite painless?

Thanks again...

m.
Quote Reply
Re: [Moby] PHP Front End to Links SQL In reply to
Hi,

Yes, the import will add any custom columns you added automatically to Links SQL.. If you removed some, then you may run into problems depending on what was removed, however it's pretty easy to work around.

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Alex] PHP Front End to Links SQL In reply to
New Plugin Suggestion
It would be great to have a PHP-Nuke plugin for Links SQL.

Alex,
I not much of programmer, so let me ask you this.

Will this new version of Links SQL [PHP version], will create static pages? [htm, html or shtml]. I understand for many people this might be a big concern, as when it comes to search engines, plain vanila style .htm, .html and .shtml pages are the best.

Vishal
-------------------------------------------------------
Quote Reply
Re: [TRPN] PHP Front End to Links SQL In reply to
Hi,

No, you will simply have a page.php script that will work off your Links SQL database, and use PHP templates.

If you want to build php pages, you can do that right now with the existing system.

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Alex] PHP Front End to Links SQL In reply to
Will there be a page.php on the client side, and then some functions files, or will it simply be one huge file? Surely you are gonna split up the MySQL functions etc into a seperate PHP file etc...
Cheers,
Michael Bray
Quote Reply
Re: [Michael_Bray] PHP Front End to Links SQL In reply to
It's just a single page.php which includes the appropriate files (Page.inc.php, Add.inc.php, etc).

Adrian
Quote Reply
Re: [brewt] PHP Front End to Links SQL In reply to
I'm not sure if my previous comments on the matter went unnoticed:

Quote:
For an existing site that has hundreds, if not thousands, of category directories/pages (static) indexed in a multitude of search engines, I would think it would be very important to be able to operate the PHP frontend as separate index.php pages to be built through the category.html template in each directory, as well as a single one-in-all page as discussed elsewhere in this thread.

The proposed method of a single page.php that does everything would seem to be a *major* drawback to the flexibility a PHP frontend ought to provide. Surely, it wouldn't be much more work to build the PHP templates in the standard directory structure? As long as you are parsing templates, it shouldn't really matter what the destination is...

Alex wrote:
Quote:
If you want to build php pages, you can do that right now with the existing system.
Not very well. If I'm not mistaken, most, if not all, PHP functionality would be lost because it would be rendered useless after being processed by the template parser. Or has that changed somewhere along the line?

Dan
Quote Reply
Re: [Dan Kaplan] PHP Front End to Links SQL In reply to
Quote:
For an existing site that has hundreds, if not thousands, of category directories/pages (static) indexed in a multitude of search engines, I would think it would be very important to be able to operate the PHP frontend as separate index.php pages to be built through the category.html template in each directory, as well as a single one-in-all page as discussed elsewhere in this thread.

I'm sorry, I don't quite get what you're trying to say there.

Quote:
If you want to build php pages, you can do that right now with the existing system.

I don't really get Alex's comment either Wink

My understanding of how things work is that either you run Links in static mode where you build all the pages, or you use dynamic mode where all the pages are generated on the fly. Both methods have disadvantages and advantages. With static, you have to build after every link that gets added, but would be generally faster and use less CPU. With dynamic, you have to use CPU, be slightly slower, but don't have to go through the hassle of building static pages every time.



Adrian
Quote Reply
Re: [brewt] PHP Front End to Links SQL In reply to
Thanks for the reply. I'll see if I can explain a bit better. :)

The major problem with the current template system, as I see it (and based from questions I've read in the forums over the past two and a half years), is that it's difficult to integrate them with any non-Links dynamic aspects of the site. For instance, calling a banner rotation program through SSI on the add.html template is not a trivial task, requiring subroutines, plugins, globals, JavaScript remote invocation, etc. Now, if the Add template functioned exactly as it does currently but output a PHP page (call it www.mysite.com/pages/add.php), then there would be virtually no limitation to what you could do with respects to dynamic site content.

It sounds like that will be addressed with the PHP frontend being discussed, although I'm concerned that a single page.php approach would lump too many things together to be easy to work with. Going back to my point in the previous message, consider a site that has several thousand links and 500 or so categories in a static-build mode. With the proposed single page.php approach, all those *URLs* to directories that make up a large portion of any Links site would no longer work.

However, if the PHP frontend were to build from the category.html template with an option to build "static" PHP pages in the regular directory structure, all the old URLs would still be valid (although I've always been troubled by Links' insistence on referring to URLs along with the file extension, i.e. /dir/subdir/index.shtml, as that only greatly limits future flexibility for changing file extensions and any server that requires the index file be specified for a directory should be put out of its misery!) and the flexibility of PHP pages would still exist. I can't think of any reasons why it wouldn't work...

As an aside, I am curious how the CPU comparison would play out. I've always assumed dynamic would burn a lot more server resources, but I wonder if it would be countered by the old rule that 10% of the sites (categories) get 90% of the traffic? What I mean is that the majority of categories probably get very little visitation, meaning they might use much less in dynamic mode than they would by being staticly built on a regular basis. To be or not to be...

Dan
Quote Reply
Re: [Dan Kaplan] PHP Front End to Links SQL In reply to
Hi Dan,

I can understand your point about preserving links, but there's not much that can be done about that.

How we are going about things is a building a single page.php script. All that script does is figure out what the user wants, loads and runs the proper module, which loads and parses a php template.

For example, going to:

page.php

will load admin/Links/PHP/Home.inc.php which will do all the queries needed to generate the home page, and then run templates/default/home.php template. The home.php template is not a regular <% .. %> template, but rather a php page that you can put whatever you like in it. You want to integrate it into your php ad system? Sure, just put <? $yourcode ?> in it. It will get executed.

If you really wanted a separate php page for each category, then you could always do that by building index.php pages, and just linking things to page.php for add, modify, search, etc.

Let me know if that clears things up.

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Alex] PHP Front End to Links SQL In reply to
Quote:
If you really wanted a separate php page for each category, then you could always do that by building index.php pages, and just linking things to page.php for add, modify, search, etc.
Would the current template parser allow PHP tags to be passed through to the resultant index.php pages? I haven't tried it, but my understanding was that this did not work previously. I had hoped to not do a static build of an entire test directory (10k links), but maybe I'll delete a chunk of them and test it that way...

If we did link to page.php for certain items, would we be able to specify that it is to be used only for those items? What I mean is that, if page.php is designed to handle the home page and all category pages, when someone clicks through to it for the search page, will it try to route them back through to itself when presenting a link to the category a search result is in?

One thing I considered after going to bed last night is that, with my comments above about using the PHP frontend to build category index.php pages, one area where it could not remain truly dynamic is changes in the actual category structure. However, that probably isn't an issue all that often. Page spanning within the categories could still be done as separate more.php pages, or the individual category index.php pages could be multi purpose and dynamically handle page spanning internally. Seems there are a few ways a dynamic/static system could work. :)

Dan
Quote Reply
Re: [Dan Kaplan] PHP Front End to Links SQL In reply to
Quote:
Would the current template parser allow PHP tags to be passed through to the resultant index.php pages?

Yes, your template is just going to be a regular php page with some variables pre defined to make things easier (like $grand_total will be the total number of links).

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: PHP Front End to Links SQL In reply to
My project is probably four weeks from completion -- now I have to decide whether to wait for the PHP front end before doing some serious hard work on the templates.

The site will be static, with daily builds and link verification automated via cron. I don't need or want the built pages to be anything except vanilla HTML.

Will I be able to combine Perl CGI for the automated tasks and PHP for the dynamic functions (search, jump, editors, etc)?

I have PHP available both as Apache module and as a compiled CGI -- could I use the compiled CGI for the cron jobs?


Quote Reply
Re: [YoYoYoYo] PHP Front End to Links SQL In reply to
Hi,

We have no plans to implement the editor system right away, and since you want static html pages, then I would recommend using the current version.

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Alex] PHP Front End to Links SQL In reply to
It appears Alex is correct, not that that's any surprise. :) I did some testing on a small installation and the current template parser does indeed allow for PHP functionality. Did that get changed somewhere along the line? I could've sworn there was talk previously of any PHP in the templates becoming disabled after being parsed for CGI...

So, it looks like the best thing to do for people wanting PHP pages but not wanting to give up the directory structure is to simply set the build extension to .php and add any desired PHP tags to the templates.

I haven't tested any of the cgi-output template pages (add/modify/search), but I'm pretty sure those won't work for PHP... Going back to a previous question, with the new PHP frontend under development, will there be any way to control which templates page.php will function for? Using this example, all I would want it to do is take the place of add.cgi, modify.cgi, and the like, to have a consistent PHP interface. I would not want it to handle things like the home and category pages for the directory reasons mentioned above, so it would need to be smart enough to recognize where to point to for on-site links. For instance, the standard page.php approach might have the home page at /page.php and category #3 at /page.php?cat=3, whereas I would want it to link to pages/category_name/ (significant mostly if a user somehow got to the page.php version of the home page, possibly by manually removing the query string).

If that is beyond the scope of page.php, will it be possible to adapt pieces of it to work as individual templates for the add/modify type pages?

Thanks,
Dan

Last edited by:

Dan Kaplan: Oct 13, 2001, 8:35 AM
> > > >