Okay, I tried the PHP front end. Didn't work for me, which is sad, because I really bought it for a PHP-enabled site.

Our entire site is pretty much PHP and JavaScript, with the exception of LinksSQL.

Because I couldn't get the PHP version to work, I re-did the templates to reflect our site, but have PHP includes in the templates, so that when Links builds the pages, it builds them with PHP code, and the code executes. The only snafu here is that when it comes to add.cgi (add.html template), the PHP doesn't execute.

Any ideas what I should do?

I think you should read my previous post here: http://www.gossamer-threads.com/...orum.cgi?post=170681

If you wish to use the PHP front end, then you'll want go the dynamic route (ie. use page.php). Building pages means that you're going the static route (with some functions using Perl CGI, eg. Add, Modify, etc).

Have you tried using page.php (note: it's only currently available with the 2.10-beta)?


Adrian

I did try the PHP version. I found that the templates weren't working --they weren't parsing properly, but I'm going to try another fresh install in a different directory to see if it works. I had problems and Alex helped port our 1.0 non sql version over to the new site (we're doing a new site launch).

One thing I didn't really like is that it's an either/or situation...either you use cgi and get the static pages, or you use php, and don't have static pages. I like the idea that search engines will be able to see our static pages, but also need the convenience of cgi.

Our current implementation (non-php front end) is at http://216.118.109/127/links/ if you want to see it.



Like I said, I'll try the PHP beta again.

Yeah, I was thinking about mentioning that to Alex (the ability to build static pages which use the PHP functions). I haven't looked at how building works, so I don't know if it would be possible or not.


Adrian

What was the error? Windows, or *nix?


Adrian

I can't remember the error right now, since I uninstalled that one and went with the cgi version, but we are on a *nix with Apache.

Here is my first error:

It wants globals.txt, and language.txt from the default_php templates directory, when I do a build. But of course, there is no globals.txt, and language.txt. BUT there IS a globals.PHP and language.PHP.

Should I copy the .txt files from the default template directory into the default_php template directory?

More errors:

First, a little info about our installation. I set the /pages/ directory to be the same as the cgi directory, because I want people to be able to hit our links section by typing in just http://...../links/ instead of http://....links/pages/

1) You already read about this before, but global.txt and language.txt is missing from the default_php template directory and had to be copied into it from the 'default' template directory.

2) When doing a build with the default_php templates with the above settings, I got many PHP include warnings because it couldn't find the include_html.php files, so I updated the templates to reflect the full path to the template files, and transferred the updated files into the 'default_php/local' directory. This stopped the warnings and showed me some pages. BUT...

3) I had to go into the admin and make sure all the changes in 'paths and urls' under 'setup' menu were carried through to the other templates (by checking the box). Without this, I didn't see any data, and the paths to the index page (index.php in my case) weren't correct.

4) I did another build after this change and it works, but now, I have see that the 'static' menu item in admin doesn't reflect the proper url (missing the '/' after 'links'). This needs to be changed. Also all the 'Cool' an 'New' menu items in the activated live links program don't have the '/' after the directory name (i.e, http://....Cool/) thus making it unreachable. This needs to be changed in the templates.

The page.php works just fine now, but it still doesn't have the templates modified yet to look like our site. I hope the process goes smoothly, since the header and footer includes on our site contain further php to be parsed.

That's because the default_php template wasn't meant to be built statically. Take a look at that post and the README.php file.


Adrian

Yes, I now realize that. It was a little confusing because I saw the option in the build menu, but we're not supposed to use that template to build. This I didn't know or realize at first.

First thing to understand is that the default_php template wasn't meant to be built (as said in the last post). Secondly, if you do decide to use the dynamic PHP frontend, you can put any PHP code in the default_php templates that you wish. It will be parsed by PHP (don't be mislead by the .html extension).


Adrian

I think we'll have to make it exclude all _php templates so that people don't get confused in the future.


Adrian

Regarding having the pages logged in the search engines - why not add a little function that allows you to pass variables in the query string?

page.php/do/detailed/id/203/

That'll log in search engines and work as well. You'd also make it generate a page with links to each ID for the search engines to spider (no one see's this page except the search engine...)

Much simpler alternative to building pages with PHP functions available etc.
Cheers,
Michael Bray

[Yikes, what's with Windows Installer loading up just to post a reply with the new forum upgrade??? Porn popup panick setting in...]

Quote:

I was thinking about mentioning that to Alex (the ability to build static pages which use the PHP functions).

I've mentioned this several times, so I think Alex is aware of it. I see no reason to limit the PHP front-end functionality to a purely dynamic page.php approach, especially for existing Links installations that don't want to throw away thousands of links to their previously static directories. I've been trying to think of a clean .htaccess way to redirect old static URL requests to the corresponding page.php address without sending back 404 errors (the easiest way I found is to point static directory requests to a 404 script that queries the database for the category ID corresponding to the requested category and redirects to page.php, but the returned 404 error would be almost as bad for link popularity as just killing the static directory and doing nothing to redirect), as this either/or situation (static/dynamic) has me very unsure if it's worth upgrading to the PHP front-end...

Dan