Hi there,

would it really be impossible / that hard to provide a way how one could build 'static' pages while being able to make use of the features of the php frontend?

As I read from some other posts there are quite a few people doing the same as me at the moment: On a mostly php driven site they use Links to build static pages with .php extension so that one can use includes and other php functionalities on their links pages. The drawback with that is that the dynamic pages (add, rate etc.) are all cgi and the php code can't be used with that. So you have a lot to do working around this.

I do so for over a year now and I have a lot of my links pages listed as no. 1 rankings in many search engines.
Using the current 'dynamic' approach with the php frontend (i.e. /cgi-bin/page.php) would really be of no good regarding not only the search engine rankings but also many users' bookmarks.

When the php frontend was announced I really hoped that it would work like the cgi version does:

• allow for building 'static' pages with .php extensions and address tags and globals in a php way - and thereby preserving my well established directory structure
• having 'add.php', 'rate.php' and so on scripts as pendants for 'add.cgi', 'rate.cgi' etc.
  

As it seems for now I am stuck with the cgi way of having a LinksSQL site...

So what do you think about that?
Is there really no other way to make the php frontend work than the page.php approach?


Andreas
-------------------------------------------------
http://www.archaeologie-online.de

Hi,

We may look at you being able to call: page.php?do=add from a staticly built site to handle the user cgi functions. This would cause some confusion with the templates though (the static pages would be built from default, but your dynamic pages would be built from default_php). Implementing the build logic in php is not something we are going to do for 2.1.

Cheers,

Alex
--
Gossamer Threads Inc.

Why would the build logic be any different for static pages with PHP? Couldn't you parse template tags (the <%tag%> variety) just the same regardless of output format? As long as <?php?> tags are left alone by the template parser, it seems that a single template set would work for any output format (.html, .shtml, .php, etc.). As I see it, what's being asked for is a way to separate the output (be it static or dynamic) from the underlying Perl program, allowing much more user flexibility.

Dan

Hi Dan,

Replicating the template parser in PHP would be a huge task, for what I think is very little benefit. Why would people want to use <%..%> tags when they are already comfortable with PHP syntax?

Right now, the build process (nph-build.cgi) can definately create .php files. Many people use it already. The missing link is the user side functions like add, modify, search. Page.php replaces those features, but it can not use the same style templates (<% ... %> style), nor do I think it should.

So, some options are:

1. Use page.php to handle the displaying category and links. This uses actual PHP templates for everything.

2. Build .php pages with nph-build.cgi, and use the perl cgi scripts to handle user functions. This uses Links SQL style templates for everything.

3. Build .php pages with nph-build.cgi, and use page.php to handle user functions. This would use Links SQL style templates for static pages, and PHP templates for user functions.

1 and 2 are already done and working in Beta 2. Number 3 is what I am proposing, and won't require very many changes. The most difficult part will be trying to make it obvious to the user what is going on.

Does this make sense? Let me know what you think,

Cheers,

Alex
--
Gossamer Threads Inc.

I would ask the question from the opposite perspective. Why create a "new" (to Links) syntax when the same templates could be used across Links regardless of build format? I don't see any advantage to the PHP template system, other than it uses PHP tags. Maybe that's a benefit to Links newcomers, but I think it's more of a detriment to existing users who have to recreate templates for no real net gain (not complaining, just pointing it out).

Quote:

Right now, the build process (nph-build.cgi) can definately create .php files.

Precisely! :) The ability is there -- all that is missing is the user side functions you mentioned that make it difficult to go fully with a PHP interface -- so I'm having a hard time understanding why all the page.php fuss has come about instead of a very simple update of the existing system and templates. If you want to go purely dynamic (option #1), then page.php is obviously the route to go, but I don't get the impression very many people want to do that.

Option #2 is of limited value. I think most people using PHP on their sites are doing so for common site-wide stuff like navigation, headers, session tracking, etc. Having to recreate that functionality on the add/modify.cgi type pages is quite an annoyance and really makes it hard to maintain consistency on a large site.

#3 seems like the best of the options, although I don't see why page.php?do=add is preferable to add.php. Same number of templates, no? Going with add.php would be much less of a departure from the Perl system, which would be less likely to cause confusion.

Dan

Hi,

I think we may be going in circles here.

I think it boils down to you are asking for the user side features to be implemented in the same template syntax as the static pages?

If so, that's where the problem lies. Recreating the same parser in PHP would be very, very difficult.

As a compromise, you can implement the user side features, however you must use php templates, not Links SQL ones.

So for existing users, it means redoing your dynamic templates like add, search, and modify into PHP ones. We have a script that does a pretty good conversion automatically. It's not too big a deal I hope.

Let me know what you think,

Alex
--
Gossamer Threads Inc.

Yeah, pretty much. As an aside, not just for PHP, though. As you know, the .cgi dependency of the user side pages has been a sticky issue with a lot of people using SSI. I won't pretend to know the difficulty in recreating that parser for PHP, although if page.php can do it, I thought an add.php could, too...

Quote:

We have a script that does a pretty good conversion automatically.

Is that packaged with Links? I don't remember seeing it, although I haven't worked with 2.1 much since being initially foiled by page.php needing to be in the cgi-bin.

Dan

But it can't. It uses PHP templates. Look at the templates in default_php. It does not parse <% .. %> tags.

As for the script, it's just a utility we wrote. You can find it in admin/Links/PHP/convert.sh. If you run it, it will covert all your templates in default to php style, and save them in default_php.

Cheers,

Alex
--
Gossamer Threads Inc.

Ok, I must have misunderstood. I thought you were proposing above to run the add/modify type pages through page.php?

Ah, I finally looked at the preferences section and found that I can go back to the basic editor for posting here! I have a sense of calm about me again. :)

Dan

Dan,

The add/modify etc pages are run through page.php ...
Cheers,
Michael Bray