I am very new at this Links SQL and was wondering if there is any printed documentation for Links SQL? I really don't want to have to post a message to forums whenever I have a question. I've had this project dumped in my lap with no background on it whatsoever. I'm basically just having trouble figuring out which files do what. If someone could tell me how to get any documentation or at least a good online resource, I would be very appreciative.

Thanks in advance!

 http://www.postcards.com/FAQ/LinkSQL/
It's a living encyclopedia, of sorts, with many common Links SQL questions answered. There are other helpful items in the resource center, which is linked to at the top of most forum pages.

Dan

Thanks for the reply.

Once again, though, I'm really looking for something other than an online forum to refer to. Like I said, I'm a complete newbie. I'm pretty good with html, and whatever I don't know about it I can figure out easy enough. Mainly what I looking for is a something to let me know which files affect what.

I think that I find something out, and when I change it to how I want it to be, it has no effect. I don't know if its necessary for every little change, but I Build All everytime I do change something. A very good example would be the links.css file. I make changes in it to change background color, text color, etc and it has no effect at all.

I apologize for as ignorant as I am about this product, but without any kind of documentation I have no other resource to rely on.

Thanks

 Regarding page.cgi: Next to the increased capacity moving from Links 2 to Links SQL, I would say page.cgi is the biggest addition. As stated above, it is still early in its development. However, to anyone new to it, I would caution you against relying completely on it for viewing your changes dynamically.

Here is an example:

http://run-down.com/...gi?g=Ratings&d=1
http://run-down.com/links/Ratings/

The first link is the dynamic version of the second link. I have added 'hits' in along with 'votes' and 'rating' to give a more accurate view of the sites popularity (i.e. if a site has 30 hits and 100 votes, there's probably some stuffing of the ballot box ). On the dynamic page, the hits do not show up and the table is aligned rather ugly. On the static page, they show up just fine.

I believe the problem is because the hits were added in via nph-build.cgi and page.cgi does not appear to access that file...? There may have been a better way to set up my changes, but the point remains that there will be some differences between the dynamic and static content at present.

Dan

Dan -

Right.

I pointed out before when you change certain pages -- rate and cool especially -- you need to make the same changes to the page.cgi routines.

The "wrapper" for the found links is hard coded into those routines, so you need to make sure you are not inserting <P> tags into the middle of tables, and that everything is in a TABLE with <TR> tags.

This is more important since the subcategory.html and links.html are in separate files, you need to make sure everything is in sync.

The easiest way is to look at the page-source on the pages that seem funny. If the tags don't match up, that's the problem.



------------------
POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/

There is no "printed" documentation for any of this -- or for most stuff. It changes too fast! There are some good books out there, you can find a list of some of the most used in the FAQ.

Some things aren't yet answered... if you have a specific question, it usually will get an answer in a short while.

The benefit of the FAQ.. is that it has somewhat better indexing/search features than the forum, and I try to pick the keywords to make the searches jump out at you. (It's also a good example of what Links can do

It also shows what questions/answers most people find helpful ....

One very nice thing, when you are in the "design" stage of the site, is to create a new templates directory -- development or something like that.

Then, work in that directory, and use page.cgi to see your changes.

ie: .../cgi-bin/Links/page.cgi?t=development

It will reflect all the changes immediately. You need to check the FAQ for some tips on setting up your links to allow for this -- especially for the detailed pages links.

When you get it right, copy them over, and rebuild your site (always back up your last working template set!!)

I find page.cgi to be most useful at design/development time, than as a run-time option (at least now).

The fact it exists, means that the site _can_ be dynamically generated, and eventually that will lead to customization, user preferences, etc. Right now, it's still very early in the life cycle, and while it _will_ currently allow addition of dynamic content (advertising, news, stats, etc), and a selection of templates -- and/or for sites with low volume, but high content, to not waste diskspace on never accessed pages, it's not (IMHO) completly worked out.

At some point, with true dynamic page generation, the underlying processes that allow the current page.cgi to run, will allow sites to dynamically serve all their content. Right now -- the limitations on system resources -- cpu, memory, other processes -- limit true dynamic page generation for most sites. You need significantly more hardware to dynamically serve a site vs staticly serve it -- maybe 4-6x the horsepower -- and the more hits you get, the more that number goes up.

New advances in hardware may make this a moot point -- but for every jump in hardware, there is a 2 fold jump in what we expect it to be able to do <G>

There is no "printed" documentation for any of this -- or for most stuff. It changes too fast! There are some good books out there, you can find a list of some of the most used in the FAQ.

Some things aren't yet answered... if you have a specific question, it usually will get an answer in a short while.

The benefit of the FAQ.. is that it has somewhat better indexing/search features than the forum, and I try to pick the keywords to make the searches jump out at you. (It's also a good example of what Links can do

It also shows what questions/answers most people find helpful ....

One very nice thing, when you are in the "design" stage of the site, is to create a new templates directory -- development or something like that.

Then, work in that directory, and use page.cgi to see your changes.

ie: .../cgi-bin/Links/page.cgi?t=development

It will reflect all the changes immediately. You need to check the FAQ for some tips on setting up your links to allow for this -- especially for the detailed pages links.

When you get it right, copy them over, and rebuild your site (always back up your last working template set!!)

I find page.cgi to be most useful at design/development time, than as a run-time option (at least now).

The fact it exists, means that the site _can_ be dynamically generated, and eventually that will lead to customization, user preferences, etc. Right now, it's still very early in the life cycle, and while it _will_ currently allow addition of dynamic content (advertising, news, stats, etc), and a selection of templates -- and/or for sites with low volume, but high content, to not waste diskspace on never accessed pages, it's not (IMHO) completly worked out.

At some point, with true dynamic page generation, the underlying processes that allow the current page.cgi to run, will allow sites to dynamically serve all their content. Right now -- the limitations on system resources -- cpu, memory, other processes -- limit true dynamic page generation for most sites. You need significantly more hardware to dynamically serve a site vs staticly serve it -- maybe 4-6x the horsepower -- and the more hits you get, the more that number goes up.

New advances in hardware may make this a moot point -- but for every jump in hardware, there is a 2 fold jump in what we expect it to be able to do <G>








------------------
POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/