Hi,

We've begun work on a front end to Links SQL in PHP. What this entails is a single php script that can add, modify, jump, rate, search and display pages just like Links SQL. It loads the same setup file and works off the same database.def file, so there will be no configuration changes and it will stay "in sync" with your admin.

What this means is you can use php templates to easily integrate Links SQL into any other php application, while keeping all the power and functionality of the Links SQL admin!

If any PHP users can offer any comments/feedback, I'd really appreciate it. We are planning to not have this compatibile with PHP3. I'd be interested if that's a problem for anyone.

Cheers,

Alex

--
Gossamer Threads Inc.

wahoo!


Cool

You've just opened up the world to opensource software like phpAdsNew a pretty good dash god darn banner system and mulititudes of other goodies ... review systems / ./ (slash dot) news systems ... and won't you be invoking the devil too?

I mean I use phpBB which ranks near the top for forum software? I hope that you won't be stepping on your own toes here.


php3 vs php4 hmmm ... not exactly sure but you can use sessions to store information over cookies. most hosting services have updated recently so it shouldn't be a big deal.

I'd love to play with the templates since I use a little from both worlds.

---

openoffice + gimp + sketch ...

Hi QooQ,

What, how, and where can I find out more about phpAdsNew?

About a year ago I purchased a system with all the bells and whistles, and it hasn't worked properly since I got it. And now that my income is depending on it, the jokes starting to wear a little thin.

Love to hear of anything that actually works.

Regan.

Sounds good! Looking forward to playing with the script. By the way - which features of PHP3 will not be compatible with it? Most things are backwards compatible - unless you want to use sessions I am fairly sure that you could do everything PHP 3 compatible...

By the way - You can download PhpAdsNew from http://www.sourceforge.com somewhere on that site..

Cheers,
Michael Bray

 
Hi Alex!

So as links is now is that what the php frontend will be like. Static pages etc etc..

And what will the cost be?

 
Good News , I was me not surely, whether I was to buy Links SQL, there my entire Internet pages based on PHP/MySQL. But thus the integration into the existing page is made much easier.

As soon as this front end is available, i think i will buy a license of Links SQL.

We probably could do everything in PHP3, but PHP3 is so ancient now ;) One of the biggest differences (to a programmer) from PHP3 and 4 (that I recall) is that with PHP3 functions had to be defined before they could be used. There's a whole lot of improvements in PHP4, like speed improvements, and like you said built in sessions, and others...

Another nice thing about PHP4 is the database abstraction layers available. This would allow faster development of the initial release of the PHP frontend. We could make it only support MySQL, but we decided that support for other databases (postgres, etc) as well would be better.

Most hosting companies provide PHP4, and I don't think there are many left that only provide PHP3 support (you should switch if they only provide PHP3 :P), so I don't think making it PHP4+ should be that much of a problem.

I'll be working on this project in the next few weeks, so if any of you have any questions, concerns, or comments can add to this thread or email me at adrian@gossamer-threads.com.


Adrian

Because of the limitations of PHP compared to Perl, some features will be missing, but it will overall be very similar to the Perl CGI version of Links SQL. Static pages will be the same since those are generated in the admin . The dynamic pages on the other hand will function the same as the Perl version, but will probably be faster than the Perl version without mod_perl.

Alex would have to answer this one :) From my knowledge, it should be the same as the normal Links SQL license.


Adrian

Oh yeah, another nice thing they added in 4.0.1pl2 (the version that the frontend will work with, and higher of course) added include_once() and require_once().


Adrian

There won't really be a need for static pages. The php frontend will really be a single php script (page.php or something similiar) that will provide the features off, add.cgi, modify.cgi, page.cgi, jump.cgi, search.cgi.

You could I guess build static php pages like many of you do now, but there would be little benefit (as you are already using the overhead of running a php script, might as well generate the whole thing dynamically).

Cheers,

Alex

--
Gossamer Threads Inc.

 
Greetings Alex!

And the cost will be for this version ??

Alex, this is great. It allows folks like us on a shared server to run the script in dynamic mode without taxing our server too much. :)

Yippee! (I guess this means a new learning curve too)

When is the ETA for this? I am sooo close on the cgi version and perhaps I should wait before we move our site over (and have new urls for everything.) Do you have an ETA?

Oh, I forgot to ask... Does anyone's server only have PHP3 or really want it to be PHP3 compatible? I don't know if we could make it PHP3 compatible, but I just want to know why you want it PHP3 compatible :)


Adrian

Adrian,

When I mentioned PHP 3, I really didn't mean to say that I wanted it PHP 3 compatible. I personally use the PHP 4 and the Zend Optimiser - I know PHP 4 is a lot faster, however I wasn't aware of any problems that would occur running the code in PHP 3.

I personally would program it like it was only going to be used for PHP 4, and take advantage of all its features - however 95% of the time when you do this it would work with PHP 3.

Zend Optimiser only works with PHP 4 I think - so that is a good enough reason to update the PHP Installation.

Cheers,
Michael Bray

here's the link to phpAdsNew
http://sourceforge.net/projects/phpadsnew/

Of course you can always check out the original phpAds which is made by the same folks who do phpMyAdmin ... just seems that they basically stopped worked on the script and have concentratd on phpMyAdmin ... mySQLman of the php world which is also on alot of hosting servers.

I'd really like some comments from those who use Adcycle compared to phpAdsNew ... the again phpAdsNew is opensource

php4 benefit is definitely speed and sessions ... php with version 4 is getting close to perl .... then again I'm not a programmer. just a user

Ummm ... before this gets to crazy in here at the LinksSQL department may I recommend opening a new forum?????

---

openoffice + gimp + sketch ...

Will this new php front end include a detailed page? pretty please?

ahhhhh ..... the end of only perl GT is coming to an end. I guess the SSI like capabilities of php is just to good to ignore ... also with scripts out there like ::: phplinks / bunghole (strange name but exists) and few other low level fundamentalists out there that GT could no longer ignore this whole sector of business.

tink about of all the Nuke'd (NO pun intended considering NY) sites out there that continue to grow everyday and they all run off of php / mysql.


OK ... until GT opens a forum for php check out:

http://www.devshed.com @or@ http://www.hotscripts.com/PHP/ for more info on php and php scripts.


but won't this case a fork in LinksSQL development ???

---

openoffice + gimp + sketch ...

Very Good

We've been running a hugely successful site using plain old links 2.0. We have problems now with the server grinding to a halt when too many people are using it (100-120 people) at the same time. We know it's the CGI spawning that's causing the problems rather than the constant browsing of the site as non-cgi parts still function properly when the problem hits.

We've been planning to upgrade to links SQL as we redesign the site in the over the next 2 months.

I'm new to both PHP and SQL so excuse my ignorance... but I'd like to ask a few questions.

1. Will upgrading to Links SQL alone improve performance?

2. How will this new PHP enhanced version effect performance?

3. Since we've customized the system quite heavily, we obviously only want to do it again once. If we wait for the PHP front-end, how long might (ball-parK) we be waiting?

4. In the meantime, whilst we redesign and get the SQL version in place when we upgrade, is there any way of making Links 2 work with MOD Perl to improve our server overload problems?

m.

Hi,

1. Yes, for large sites. However, you will still run into problems if you have a lot of concurrent users. For this, you should use mod_perl (requires Dedicated Server) or SpeedyCGI (can run on some virtuals).

2. The PHP front end will perform better if you have many concurrent users, and are using regular CGI. The mod_perl/SpeedyCGI versions will be faster.

3. We hope to have it finished in at most 4 weeks, possibly 3. We have a good chunk under way right now.

4. You can run it under Apache::PerlRun.

Cheers,

Alex
--
Gossamer Threads Inc.

Yes!

Cheers,

Alex
--
Gossamer Threads Inc.

Free upgrade!

Cheers,

Alex
--
Gossamer Threads Inc.

this is brilliant Alex, and all those involved - really looking forward to this. Finally be able to integrate vbulletin with links SQL !
---------------------------------------------
DeskPRO.com http://www.deskpro.com?r=gt
vBulletin.com Moderator and Support http://www.vbulletin.com/

I'd recommend using GForum rather then vBulletin. vBulletin uses PHP which is good, but is not coded well at all. The new PHP front end to Links SQL should be great, and I am really looking forward to contributing to it after it is released - as some of you know I do a lot of work with PHP - and will be very happy to help out when the new front end is released.

Out of curiousity - will this be one file, or will it be a detailed.php - search.php - add.php etc?

Cheers
Cheers,
Michael Bray

no chance of changing from Vb. The features of gforum currently don't even appear to come close. but i guess this is now not the place to discuss the pros and cons of forum systems.
---------------------------------------------
DeskPRO.com http://www.deskpro.com?r=gt
vBulletin.com Moderator and Support http://www.vbulletin.com/

Alex wants it to be one index.php and using do=function... Cleaner with the number of files required to put in your web root or wherever you want to put it, but the extra do= parsing (easy and fast) and an extra include (also should be fast). Not that much of a diff between doing the one file method and the multiple file method (though I'm more used to the second method when coding php).



Adrian

That would be for current LINKS SQL users but what about a first timer..

I think (I'm just a programmer, not sales ) anyone with a Links SQL license can use the perl cgi version or the php version. So if you're a new user, if you buy a Links SQL license, you get to use both the perl cgi version and the php version.

Adrian

vB people please post in the G-Forum area to help Jason make improvments and/or add options. He's doing really good!

why vB and pay $$$$ use phpBB (open source - just a copyright and powered by notice cost). that is if you like using something other than a GT product.

Honestly, I'm on the sidelines until GT officially release a price schedule. I can also manage to wait ...
my phpbb board will tide me over in the meantime.

What ever your choice -- be happy!

---

openoffice + gimp + sketch ...

It is currently one file, tentatively called page.php which you will be able to accomplish all the user side functions. To customize/integrate, you will edit the templates of course. The difference being the templates don't use the standard <%if .. %> syntax, but are regular PHP.

As for price, if you don't own Links SQL, then you just need to buy it (now or later) for $450. It uses the same admin/database so really there is no php or perl version, you will be able to switch between them as you like.

Cheers,

Alex
--
Gossamer Threads Inc.

Alex,

I just want to express my gratitude that GT is growing LinksSQL to include a php front end. It really does allow us to have a better (dynamic) web site in a shared hosting environment. I have owned a copy of LinksSQL for like 5 months now, still haven't gone public with it yet, but have been customizing and preparing to go live soon. I will wait for the php version, so my urls don't change more than once.

I like that you guys build quality products! (Also, this will integrate with my vB wonderfully. And I do love my vB!)

I'm really excited about this!

What features does vb have that GForum doesn't?

PaulWilson,

vB has such a wonderful and powerful admin panel. It gives so much flexibility. Also, I have found that it is really intuitive for folks who might not be experts in programming... yet gives all the functionality for someone with tons of experience.

I don't know what GF can do, but vB allows my moderators to Merge Threads, Move Threads, Auto Redirect Moved Threads... varying permissions per usergroup (admin defined) and so so much more. GF might be just as cool. Just, I am not going to switch out of something that is working really well for me.

Our members love it too. (We switched from UBB about 6 months ago).

I don't know about how well it is written or not, but I have heard that it is written really well (version 2). I think the version 1 was a little sketchy.

here's an example: These posts about vB should probably be split and moved to the GF area. Can this be done? Can you pull certain posts out of a thread and either move them or merge them with another thread? (perhaps you can, I don't know). but it seems that we should continue this conversation down there.

this php thing is brilliant news, can't wait to see it. Thanks again everyone.

Paul, other features..

- mass pm to users
- buddy lists
- infinte level of forums/categories
- memberlist
- ignore list
- subscribe to forums/threads
- user control panel
- mass move/merge/split/stick/ threads
- unlimited styles
- co-branding features
- referrer information
- brilliant template system. everything is a template
- avatars
- stars (probably in gforum)
- stats in admin area
- custom replacement code

i am sure there is more, some of these might be in gforum but i have not seen the admin section. Gforum does look really good though, better than wwwthreads i feel already. so yeah, nice.
---------------------------------------------
DeskPRO.com http://www.deskpro.com?r=gt
vBulletin.com Moderator and Support http://www.vbulletin.com/

This is the best news I've heard in quite some time! I had actually half considered trying to overhaul Links SQL to play friendly with PHP, since the all-Perl approach has limited several things I've wanted to do with my site, but I didn't envy that undertaking.

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.

Similarly, if taking that approach (separate index.php pages in each Links-built directory), and if there isn't already such a feature in the latest versions that I haven't yet worked with, a very useful tool would be the ability to un-build the existing index page in each directory at the same time as the new PHP version is being built. Otherwise, you would have to delete them one by one or delete all the top level categories in one fell swoop and hope that you don't have any interruptions rebuilding before someone tries visiting... There are probably some recursive command line tools that could accomplish the goal, but I don't work enough with that to know exactly what they would be.

Dan

About time u guy'z... PHP4 is the route to go... Waaaaaaaay advanced and waaaaaaay faster...

ed

Less Talk More Action: www.9o9o.com

FYI...I'm running PHP3 and PHP4 scripts on my server... Once a server upgrades to php4 it will take on php3 scripts no prob...

Let's go... I want this program yesterday...

Now I just gotta figure out what url I can use to finaly impliment my sql license... LOLOLOL


ed

Less Talk More Action: www.9o9o.com

Not really actually. Perl is much more advanced and a much more complete language in terms of what you can do with it. As for speed, perl is again faster then PHP.

Where PHP shines is the fact that Apache can easily embed a PHP processor inside of itself. This means that the PHP processor is always loaded and always in memory, and running a php script is very quick. When you do the same thing with perl (via mod_perl or SpeedyCGI) the results are just as impressive.

The downside of course is that mod_perl is not as for ISP's to use as PHP (mainly because perl is so flexible that there are more ways to hurt yourself then with PHP).

Cheers,

Alex
--
Gossamer Threads Inc.

Guess I shoulda clarified my posting... I was referring to php3 vs php4... Sorry...

Oh Yeah... I hate being in pain...

Btw... Alex... Kudos on the new message board... Looks great but I still like my vb...

ed

Less Talk More Action: www.9o9o.com

Alex, just ignore ed, he's been taking some php lessons and his tutor has brainwashed all his students so they now think php is the best thing since sliced bread.

Believe me, its php this, php that, can you find this script in php, can this be done in php LOLOL......

We use a php realtime chat script on our site and it is more buggy than the middle of the Amazon. (and isn't poorly written or maybe it is.....who knows)

The same way some of the people at this forum have been with Perl? There is always going to be some people that think there one is the best. I use PHP cause its fast and easy, If something was very important I would get it done in C or C++. A well coded PHP application won't be buggy, and a well coded Perl application won't be buggy. I', not starting a War here, so don't take this as a flame, its just the following quote that got on my nerves


Cheers,

Michael Bray
Cheers,
Michael Bray

Oh dear,

I know Ed and I was making a joke about him and his obsession with php

I don't particularly care whether php or perl is best. The post was not about that.

Didn't mean to start an argument here but I'm a UBB (perl/cgi) convert to the vB...

I know for a fact that the UBB was using 3 times the amount of server power to funtion in comparison to the vB...

It's not that I don't like perl/cgi it's just that in order to make perl/cgi coding fuction just as fast as php a server needs all kinds a add on paraphanelia... Compress this, compress that, speed up this and speed up that...

Our poor cobalt can't take the pressure... LOLOLOL
(just kidding)...

In any case I'm grlad to see that GT is spreading it's wings...

ed

Less Talk More Action: www.9o9o.com

Paul's just chittin' around... The script isn't that bad and the errors only show up when I do some modifications to it...

99% or the time they're javascript errors...



ed

Less Talk More Action: www.9o9o.com

Hey don't make fun of Cobalt !!!

It's still being taught full time in Japanese high schools!!! high schools in Japan don't teach, java, perl or even html but they manage on Cobalt

I'm not joking either ...


hmmm ... I wonder if they're preparing for the next 2yK problem [sarcastic]

---

openoffice + gimp + sketch ...

Good job Ed gets my humor.

Sorry - looks like you guys took my response the wrong way. I didn't mean to piss you off or anything, I didn't think my reply would be interpretted the way it was.

I just wanted to clear up the point that a well coded PHP app wouldn't be buggy. I'll admit, I can't quite see the funny part of it, but I'll re-read it a few times and try to find it, I have a good sense of humour, so I should be able to find it in there somewhere
Cheers,
Michael Bray

I doubt you will get the humor unless you know Ed fairly well. I was taking the micky out of Ed which I expected only him to understand, whilst others thought I was saying php was buggy but I was referring to Ed's coding (in a joking way).

OK Cool
Cheers,
Michael Bray

I think you've just perfectly defined poor use of a public forum! Well done. ;)

Dan

My bad.

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

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

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.

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

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 . 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 . That's more Alex's department.

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


Adrian

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

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.

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.

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.

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.

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
-------------------------------------------------------

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.

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

It's just a single page.php which includes the appropriate files (Page.inc.php, Add.inc.php, etc).

Adrian

I'm not sure if my previous comments on the matter went unnoticed:


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:
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

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


I don't really get Alex's comment either

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

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

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.

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

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.

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?

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.

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

Hi Dan,

Yes, you would be able to modify the add, modify, search, rate, etc php templates and change the links so that they link to a static directory rather then the dynamic one, although I'm not sure this is a good idea (if your pages are .php you still have significant overhead displaying them in a directory).

But the option will be there.

Cheers,

Alex
--
Gossamer Threads Inc.

Hi Alex,

Thanks for the quick reply. Sounds like that system has definite promise.

While it's true that there is still overhead for PHP pages in a static directory, the alternative for me, and probably many others, is .shtml pages which are even more overhead. The fully dynamic page.php approach saves on build time, but it adds a different form of overhead -- extra MySQL query(s) to assemble the requested page in the first place. On a very busy site, I could see that being just as significant.

edit: I should also mention that the reason I feel some dynamic flexibility is important even in a static directory is that I look at Links as part of an overall site, whereas I think the development point of view is to look at incorporating a site into Links or Links being the entire site. As such, it often is not practical to build all of a site's functionality into the template sets; much cleaner (and several megs of disk space less) to dynamically include headers/banners/JavaScript/CSS like they are elsewhere in the site and be able to make "global" changes without having to also change those aspects built into the Links areas.

Dan

Hi Alex,

Well somehow we are not a big fan of PHP (we don't like errors:)). Can u explain what the benifits are for a happy perl/cgi user ? Is this really a good idea?

Allready thanks.

Regards Startpoint..


BTW: PHP fans don't shout to loud :)...