Search Box needed for own sight. Meant to search only own web sight, based on keywords/description/date (meta tags).

So that should do for the mouse-over tooltip. Probably lots of scripts available? but who knows where? Who can help me with this?

Not too sure exactly what you want, but is the site search engine on this site (in the ASP section) what you need?

Blair

Have found several 'external' search boxes. Free code to place someone else's search box on my page. Meaning you can search the entire web using Google, Hotbot or 'whatever' and display the search results within your own page.

What I want is a search box which can do the same search (search meta tags such as desription, keywords, etcetera) but just for my own websight (everything under http://www.croco.nl/ - http://www.croco.nl/ ) not an internet wide search.

Have found some freeware boxes, but these require a banner on my websight or can only search a limited amount of pages.

Croco Dylan wrote: Have found some freeware boxes, but these require a banner on my websight or can only search a limited amount of pages.

Well, you'll be lucky to find a free one which doesn't require some sort of link back or have a restriction of some kind, so your options are probably limited to using one of these or writing your own. If you look at the Web Wiz Guide site search, there is a function there to get the meta tags which you could possibly modify to get it working how you like.

Blair

Would be a lot easier if I had a budget, or some form of income (from the sight) to spend on (a.o.) some of this stuff. Have no objections to linking to other sights or such, not at all. If someone helps me, there should be something in return. Credit's due where ... and all that.

And free software (or services) can sure make life a lot easier, but just want a completely banner free sight for a change. Seems to me a search bot is pretty generic code, only the starting url of where to search or in which file (txt, database) to search for certain strings is diff'rent.

Had just hoped someone else had invented this wheel, 'cause I'm just plain lazy. Up until now unfortunately, although I'll keep on dreaming ;-)

Unfortunately

b_bonnett wrote: If you look at the Web Wiz Guide site search, there is a function there to get the meta tags which you could possibly modify to get it working how you like.

Tried it just now, demo looks nice but won't work with current provider. Too bad.
Fallback solution is to have a 'sight map/complete index' for each major section of my sight. Even less computer-gifted persons nowadays can find the Ctrl+F.

Still, search box is nicer ....

As to

hpnadig wrote: Add Google Search to Your Site

and of course blair's comments on this

A search page with all external search boxes could be considered as an extra. What I'm wondering is how this will affect your ratings, if any ;-) with the search engines. Ho much will i.e. Google put me higher up on the list, if I have a search box to them?

Any thoughts?

hpnadig wrote: well, I think you've misunderstood Mr.croco... You can have a google tab to search your own site...

Indeed, misunderstood. Such a box will do exactly what I want.
Thankx, dp

Still wondering though for an extra page with 'external' search boxes (to search internet) and whether these will get you any higher up on the search eng's lists.

Anyone any experience with this?

Croco Dylan wrote: What I want is a search box which can do the same search (search meta tags such as desription, keywords, etcetera) but just for my own websight (everything under http://www.croco.nl/ - http://www.croco.nl/ ) not an internet wide search. Have found some freeware boxes, but these require a banner on my websight or can only search a limited amount of pages.

Take a look at http://www.wrensoft.com/zoom - http://www.wrensoft.com/zoom

It should do exactly that, lots of hosting options (php, or asp, or javascript) and does not require any ads or banners - completely hosted on your own site. It's free (as in beer) for sites of up to 50 pages... and that's always been enough for me.

It's better than using Google or something for your own site because you control when it updates - whereas Google only indexes (reads in your site) only once every long while - and search results become outdated quickly. You also have a lot more control over how your website is indexed - what pages to skip etc.

Thankx ray12 for the Zoom tips. Lookx like somet'ing I could defntly use. Also thankx to others, I am still researching possibilities, but for now got a good push in the right direction.

Thankx y'all.

abhinav: thanx for the tip http://www.hotscripts.com/ - http://www.hotscripts.com/

found lots of stuff there, at least two or three javascripts that'll do exactly what i want, thanx again

Quick note: unless your site is very small, JavaScript should be the last resort, because the way it works is that it has to execute on the client-side: that is, in the browser of the person visiting the site. This means that the index data (all the pages, keywords, the way they relate to each other) has to be downloaded to each user's computer before they can run the search query. Now if you have a fairly big website... (which is usually when you need a search function) - each visitor has to download maybe 500kb or so of data before they can run a search query ... that's gonna be some slow loading pages! And if you have the search box on every page...(although it might get cached, you get the idea).

So if your site is very small, you might be able to get away with it only adding 50kb or 100kb to each page. Otherwise, check with your web host to see if they have PHP or ASP, or any server-side scripting support. That's really the most efficient way - because none of the index data has to be transferred, it stays on the server.

Hmm, not such a quick note afterall :) Good luck.

ray12 wrote: each visitor has to download maybe 500kb or so of data before they can run a search query ... that's gonna be some slow loading pages!

Found a java scripted search box ( http://www.tipue.com - tipue ) which uses a datafile. Just enter all info, description and keywords and it workx. So, no need to download all pages and no need for any script or program to "read" all original html files.

As to my ISP. They have announced upcoming changes, and if this were to be believed, I'd be able to use PHP and ASP at some time in the future. When? Nobody knows .... Until then (or untill I change ISP's) I'll have to do with different solutions. Of course, I'm very anxioously awaiting these changes, 'cause then I can do a lot more on wy websight.

For now I'll just settle for the tipue solution. Okay, admitted not perfect. Does work fast and can do what I want. No need for any form of server-side scripting and no specific needs on the client side, except java of course. The major disadvantage however, is that I'll manually have to enter all info (fill datafile) and that differences between the datafile and the actual meta tags that are in the original html files. Discrepancies can easily occur.

Probably I'll see if I can make a simple perl script or use a kourne shell to read all the htmll files, put meta tags in certain fields and arrays and let my (perl)script update or change the contents of the datafile.

Croco Dylan wrote: Found a java scripted search box ( http://www.tipue.com - tipue ) which uses a datafile. Just enter all info, description and keywords and it workx. So, no need to download all pages and no need for any script or program to "read" all original html files.

Actually, the data file is still being downloaded. When i say "download" i don't mean the user has to click on a file and actually download and Save the file manually. What i mean is that the file must be transferred from the server to the client - like when you place an image on your page - the browser will have to still download the image file before it can be displayed on your page. Same thing here, when you have a <script src="data.js"> on the top of your page, the file must be downloaded before the page can be rendered.

Now this is only a problem if the data file is big, but in this case, it could be fast because its a small file: since you said you manually enter the datafile, i assume there really isn't that much data in there. I guess this also means it relies on your manually entered keywords? So it doesn't actually use the words on the page, but just the keywords you type in.. this means there are plenty of words not included in the search, so its quite limited. But again, if your site is like 6-10 pages, you won't really notice until it grows to 30 or more pages...

Croco Dylan wrote: Probably I'll see if I can make a simple perl script or use a kourne shell to read all the htmll files, put meta tags in certain fields and arrays and let my (perl)script update or change the contents of the datafile.

That's a good option, you can even get the perl script to rip unique words out from the html files for your keywords.

The http://www.wrensoft.com/zoom - Zoom thing i pointed at before, has a similar JavaScript search - which requires no server-side stuff. And in addition to that, has a Windows program which creates the data file for you by reading your html pages, and actually using the words it finds on the pages.

ray12 wrote: Actually, the data file is still being downloaded.

As to the size of the datafile, here's what the author's got to say on this

In our experience, the details for five pages tends to take up approximately 1Kb. For example, a site with 75 indexed pages would require a 15Kb data file.

Of course only time will tell how this will turn out to be. I do plan to use a lot more keywords. Not sure bout my keyword policy and may use more internal keywords than 'just' the tags (for bots to pick up). Examples? A search within (future) restricted sections of the sight. These pages are not meant to be found through Google or such, so there's no need for the keywords here. Internally I would wanna use them. I could use one txt file where lines could read like this

someurl;tipue;keyword1, keyword2, ...
sameurl;bots;keyword1, keyword2, ....

A simple perl or ksh script could take this file and update both my datafile and the html-files itself. Then see which files have been modified and upload these. Of course I could make this script as smart as needed, or use several scripts in conjunction with eachother. Some examples, extract all text on pages which is printed in bold or contrasting font. Extract unique or duplicate words, etcetera etcetera. Output can be to any one or more files. Let's say generate a list of keywords used, and the number of occurences. Perhaps this could even be done in conjunction with user feedback without having to resort to server-side scripting. Count and identify keywords as used by visitors and append info to file on server or by mail. One can think of many things up front, which policies and rules to enforce in optimizing the sight and how to evaluate certain data can be better understood (and used) after a certain amount of time has passed.

ray12 wrote: But again, if your site is like 6-10 pages, you won't really notice until it grows to 30 or more pages...

As to size of the sight? Hmm ... hard to say. Plan to start in 1 'n 1/2 month with at least 40 or so stories, some short some long. I call them stories and not pages, since stories may be spread along several pages (small files fast loading). Perhaps with some a 'give your comments page' or poll for users (rate this page) and/or a source page (info found in these publ.'s). Although maybe not 2 full pages, still some space needed. Let's say an average of 2 or 3 pages per story. 3 pages times 40 stories makes at most 120 lines in the datafile, which according to tipue would result in a datafile of 24k. Which isn't that bad. Even if in the first 6 to 12 months I would be able to double the content (40 to 80 stories), that would still be acceptable.

If the need arose for faster searching, I could always split up the sight in several sections and have more than one search box, one for each section with its own datafile and a master search box for top-level search level. The separate datafiles could still be filled automatically, based on i.e. path (directory is a section). Although I'm not particularly fond of such a solution, it still might be used as a fallback untill you come up with something better.

In time, I'll have to upgrade to some form of server-side scripting or even running (i.e.) Apache on a pc here at home, 'specially considering all the (long-term) wishes I have. No question about this whatsoever! For now most important is to come up with enough (interesting) content to make the sight worthwile, and to keep adding enough to get users to come back every once in a while. This is the absolute prio number one. As long as this goal hasn't been reached, I think it would be a waste of time to put much effort into creating the technical best solutions. No need for a search box or site map if you only got two pages.

So what will do for now, or at least untill I resort to more advanced techniques. A basic structure and logic which can also be used with more advanced stuff, such as server-side scripting. Enough flexibility to upgrade, and for now as much dynamic and generic as possible.

When you come to think of it, it's all just pretty bsic ground rules. Although we sometimes tend to forget these, meaning we have to reinvent the wheel every time we want something new. Just a waste of time, ain't it?

Croco Dylan wrote: As to the size of the datafile, here's what the author's got to say on this In our experience, the details for five pages tends to take up approximately 1Kb. For example, a site with 75 indexed pages would require a 15Kb data file.

Yeah that's mostly true for that search script, because it only contains an index of words you manually enter (assuming you don't feed it 70,000 words with your perl scripts). I was describing something more akin to a real search engine, where all of the text on a page is indexed - so any word that appears on a page is searchable.

If you are happy with limited searching (matching only certain words on a page, or just words in the meta keywords tag), then by all means, it won't be much of an issue at all and you should go with it.

Croco Dylan wrote: In time, I'll have to upgrade to some form of server-side scripting or even running (i.e.) Apache on a pc here at home, 'specially considering all the (long-term) wishes I have. No question about this whatsoever! For now most important is to come up with enough (interesting) content to make the sight worthwile, and to keep adding enough to get users to come back every once in a while. This is the absolute prio number one. As long as this goal hasn't been reached, I think it would be a waste of time to put much effort into creating the technical best solutions. No need for a search box or site map if you only got two pages.

Absolutely true. Too many webmasters forget that and the mass of garbage on the Internet is the result of it. The most important thing is to have material that people want. Usability's important, but content is everything.

Although it's a good thing that you've sorta prepared and looked into this sorta thing at an early stage too y'know. Because when, in a few years time, and your site has grown to 500 pages, and you want to add a search function in... and realise that you have to go through 500 pages and give them all META descriptions and META keywords... and specify proper titles for those pages loading in frames and whatever else... it'd be a nightmare. So it's all good really :)

Croco Dylan wrote: When you come to think of it, it's all just pretty bsic ground rules. Although we sometimes tend to forget these, meaning we have to reinvent the wheel every time we want something new. Just a waste of time, ain't it?

There's alot of reinventing of the wheel out there definitely. But at the same time, everyone has slightly different requirements and sometimes DIY can be good too. Most of the time, if you look around the web long enough, you'll find something that does what you need.

Hooray, a kindred spirit I seest beforst me

ray12 wrote: There's alot of reinventing of the wheel out there definitely. But at the same time, everyone has slightly different requirements and sometimes DIY can be good too. Most of the time, if you look around the web long enough, you'll find something that does what you need.

Meant that for your own wheels. As in when first desiging and building a sight (or something else for that matter). Wishes 1 and 2 are must-have's and 3's pretty high on your list. 1 and 2 can be fulfilled by using some trips or ticks you've found. When. let's say a whole lotta later you also wanna have wish number 3 (or 4, 5,6,7), you (have to) decide on something which isn't compatible with your already implemented code for wish 1 and 2. You have to come up with somet'ing new for 1 and 2. Not so smart.

If you would have anticipated things better, it might have taken you more effort and time at the start but you would've found a generic solution for wishes 1 and 2. On one hand you don't want to spend too much time & effort into (possibly never needed) wishes, especially where money (or time) is a big issue. On the other hand you want to anticipate future wishes & developments the best you can, especially where this may give you a headstart on competitors.

As to

ray12 wrote:   where all of the text on a page is indexed - so any word that appears on a page is searchable.

I tend to use off-topic (key)words or double meanings just to be able to link to some other page. Topic-specific words can be found on pages that got's nothing to do with that particular topic. These words are only used so I can link back to other pages. Say the term "seal of approval" which could easily be on a disclaimer page. I would however use this to link to a picture of a seal (the animal) and from there link that to let's say greenpeace, or to a story bout arctic explorations, or to a page on seals & croft or ... or ...

The purpose being, of course, to surprise visitors by the unusual linking. Whether it's effective or even any fun this way? Time will tell.

Back to the search box. A search on all text within pages for a topic-specific word, might also produce a lot of pages that's got absolutely nothing to do with that topic. They're just there for 'surprise linking'. A search box should produce clean results, which wouldn't be the case on my sight. Not if I searched on all text.

As to the use of scripts. Very useful reports can be generated, which text is where and how many times. Because of my unusual linking, I'll still have to judge which keywords, titles and descriptions really apply to the page.

Croco Dylan wrote: Meant that for your own wheels. As in when first desiging and building a sight (or something else for that matter). Wishes 1 and 2 are must-have's and 3's pretty high on your list. 1 and 2 can be fulfilled by using some trips or ticks you've found. When. let's say a whole lotta later you also wanna have wish number 3 (or 4, 5,6,7), you (have to) decide on something which isn't compatible with your already implemented code for wish 1 and 2. You have to come up with somet'ing new for 1 and 2. Not so smart.

Ah yes. Absolutely. Planning ahead and leaving room for future modifications is important... but also be careful of going too far, leaving things too general or wide-open, when a more focused solution could have been better.

Like alot of forums don't bother working out how many new messages have been posted to each thread since the last time you visited. It's a bit excessive to check it for every thread (and remembering the previous number for each thread), and some would be smart enough to only check it for the top 5 thread or something. But i've always found it to be one of the most useful things to have, and having it partially implemented, can sometimes be very valuable, rather than waiting out for the "complete solution" and leaving room for it. Hmm.. perhaps I'm making a different point now. :)

Croco Dylan wrote: I tend to use off-topic (key)words or double meanings just to be able to link to some other page. Topic-specific words can be found on pages that got's nothing to do with that particular topic. These words are only used so I can link back to other pages. Say the term "seal of approval" which could easily be on a disclaimer page. I would however use this to link to a picture of a seal (the animal) and from there link that to let's say greenpeace, or to a story bout arctic explorations, or to a page on seals & croft or ... or ...

I see. That does throw a spin on things. Perhaps having both is still an option, with priority placed on the keywords defined manually? Most scripts and search engines cater for both the words on a page and the manually entered description and keywords.

The biggest problem with using only self-defined words is that you'd have to guess all the possible words that your visitors will type in. Usability wise, if alot of users try a couple of searches, get zero results (most web surfers are trained to reduce the "specific-ness" of their searches in order to get more results - and they expect it), they usually move on and assume its broken. I know I do.

Using words off the page will usually find some results, of some relevance, whether it is of completely accurate relevance is another issue. But perhaps someone did want to find that link to greenpeace that they only remember was linked via a cute seal picture. They'd expect to be able to find it by searching for the seal. Not your priority of concern perhaps, but it's something to think about.

Croco Dylan wrote: As to the use of scripts. Very useful reports can be generated, which text is where and how many times. Because of my unusual linking, I'll still have to judge which keywords, titles and descriptions really apply to the page.

There is still a level of convenience though, I think, to define them in the META description on the same HTML page - as you would have to at one stage write the page itself, enter the title and all that anyway. When you want to modify it, you change it on the page itself. Instead of having to open up a different file, find the corresponding entry (eg: line 203), and type it in there.

ray12 wrote: Ah yes. Absolutely. Planning ahead and leaving room for future modifications is important... but also be careful of going too far, leaving things too general or wide-open, when a more focused solution could have been better.

To the above, point taken. You're right.

As to the off-topic keywords, this does pose me with yet another (self-created) difficulty. How to avoid "dirty" search results? This is something I keep strugglin' with.

As to which set of keywords would be closest to what users expect, you'll probably understand that (in my case) user feedback will be highly needed. I just gotta have the users' feedback on this, in order to optimize my own search box. Knowing which keywords they use, but also checking the popularity of certain pages (most popular pages on top in search result?), or using polls (rate this page, did you find ...) . But for instance this (or likewise) site's always useful too http://inventory.overture.com/d/searchinventory/suggestion/ - http://inventory.overture.com/d/searchinventory/suggestion/

As to where to define keywords. Of course, these should always be in the meta tags of the pages. But I might have two different policies here. One for the bots and external search machines which is mostly "generic" qualifications. 2nd policy, for internal use, I'll have to use all the "generic info", but in addition to this might want more keywords or other descriptions. I don't want my page to show in a Google result, when searched on the term "greenpeace". Topic-wise my page has nothing to do with these guys, except for the link. Internally however, you should be able to search on greenpeace or seal.

If I'd want to modify the description, page title or keywords, I could do so in the html file itself. In which case bots would/might pick up the new words at their next visit. Nuisance here being of course that I'd have to change things in two different places. Both in the datafile (intern search box) as well as in the original html file (for bots). Discrepancies are very easily "born" here, and to avoid such errors I'd have to (manually) check and double-check everything. A way too tedious task and it will not prevent me from making mistakes (fatigue, too fast editing, accidently cut & paste over another line, typo's and ....). Looking for something better I came up with (let's call it) keyword.ini.

In the keyword.ini two lines for each page, one to define the generic keywords and such (for bots) and one for additional words which are only used internally (or all on the same line). Only the keyword.ini file is used to manually fill certain values (keywords). Next, a script could be used to check whether both the html files and the datafile (own search box) contain the right words as defined in my ini file. Simply take the line from the keyword.ini, and compare these with both the html files and the datafile (search box).

Something along the lines of

while (readline keyword.ini)
 extract name of html-file, fill fields keywords, description, page title
  open appropriate html file
   read lines from html file
    if line begins with "<meta name="description
     then compare descriptions (keyword.ini with html description)
      if different, then replace
       (same with keywords, page title, or whatever else)
   read lines from datafile (for search box)
    same procedure for the datafile as with html files above

This way, I only have to define things in one place, namely the keyword.ini file. The check-script could be set at timed intervals and it will change whatever needs to be changed. This script could also produce a list of changed files or trigger an incremental upload (changed files). The keyword.ini could be easily imported into any other file (such as csv or database), so with some easy scripting I could "translate" this file to whatever format needed when I'd upgrade to more advanced techniques. So everything I do in the ini file, can be used when I upgrade or start using other techniques.

As to a user coming back for a specific link (the seal), I could always generate a "site map" for hyperlinks. This is probably a good idea anyway, especially where I want to hide surprise links or menus (adds to the surprise effect). Just as with the keywords.ini, this could be put into a script. Run locally and upload if changed.

Croco Dylan wrote: As to where to define keywords. Of course, these should always be in the meta tags of the pages. But I might have two different policies here. One for the bots and external search machines which is mostly "generic" qualifications. 2nd policy, for internal use, I'll have to use all the "generic info", but in addition to this might want more keywords or other descriptions. I don't want my page to show in a Google result, when searched on the term "greenpeace". Topic-wise my page has nothing to do with these guys, except for the link. Internally however, you should be able to search on greenpeace or seal.

Hmm. So you need two sets of keywords for each page. I actually came across something that could work like this in Zoom but I've never had to use it. Some information here:

http://www.wrensoft.com/zoom/support.html#zoomwords - http://www.wrensoft.com/zoom/support.html#zoomwords

Basically, they seem to have a custom "zoomwords" meta tag, in addition to the usual "keywords" meta tag. The "zoomwords" are only acknowledged by zoom, and are ignored by Google and other search engines. This should let you keep both the public/"generic" keywords and the "dirty"/internal keywords defined on the same page. You might want to look into it.

Or you could go with the keyword.ini file if you're feeling peckish for scripting :) That seems to still rely on having the words in a seperate file from the HTML page though i think? But then you said it'll check, so i assume it'll have to extract the 'correct'/updated text?

Sitemap definitely sounds like a good idea with the 'surprise' link naming system you're thinking of. Sounds like its going to be quite a site! :)

Ray12 wrote: That seems to still rely on having the words in a seperate file from the HTML page though i think? But then you said it'll check, so i assume it'll have to extract the 'correct'/updated text?

Not sure I clearly explained my intentions. So a simple example.

Let's say I have a page called pirates.htm in the articles directory, with the keywords "pirates, sailing" in the meta tags. Let's now say that I'd want to replace the keyword "sailing" with "history", how would I the do this?

In this example the old line in the html file pirates.htm would read like
<meta tags="keywords" content="pirates,sailing">

My keywords.ini file could read something like this
art/pirates.htm;[page title];[description];pirates,sailing;[own keywords]

If I need to change the keywords pirates,sailing to pirates,history I'd do so in the ini file by changing the line as typed above to

art/pirates.htm;[page title];[description];pirates,history;[own keywords]

The script reads all line of the ini file and for the line as typed above it will do the following.
1. read lines
2. find and open (in this case) pirates.htm
3. search for lines beginning with "<meta tags=keywords (..) "
4. Compare keywords as found in ini file with keywords as found in html file
5. If different, replace the old keywords with the new keywords (write to html or replace text).

After the script the same line in pirates.htm would now be
<meta tags="keywords" content="pirates,history">

Something along the same lines could be used for the datafile as used by my search box.

Script can be either started manually from prompt or at timed intervals. Such scripts are all run locally. I could make the script in such a manner that I'm able to either run the script for entire directories (all htm files) or when given the filename as a parameter only runs for the given filename (pirates.htm).

I see. So it's a bit of an update script that reads in the HTML files and update the keywords changed in keywords.ini. But I guess, when you introduce a new page to the site, you will be entering it twice, once in the HTML file with the meta info, title, description, and then a second time, entering the equivalent info in keywords.ini.

Or you could also have a backwards updating script, which extracts the info from the pirates.htm file, and enter it into the keywords.ini file, for new pages. If you know what i mean :)

ray12 wrote: Or you could also have a backwards updating script, which extracts the info from the pirates.htm file, and enter it into the keywords.ini file, for new pages. If you know what i mean :)

Good idea! Would probably use such things to generate reports. Especially user feedback (or counters on every page) can be used as to generate other keywords reports.

I'm a bit hesitant 'bout dynamically assigning keywords, descriptions or such. Kind of lose the human interpretation of "dirty" keywords and double meanings. Better to generate reports and use those when (humanly) deciding what to put where.

Answered too quickly, and this came to me after a split-second

ray12 wrote: But I guess, when you introduce a new page to the site, you will be entering it twice, once in the HTML file with the meta info, title, description, and then a second time, entering the equivalent info in keywords.ini.

Beauty in simplicity. Only update the keyword.ini file. Built in a timed run for the following, first find out which (html) files have changed (attrib date mod), then run checkmetatags script.

This way don't have to double work.

Croco Dylan wrote: Beauty in simplicity. Only update the keyword.ini file. Built in a timed run for the following, first find out which (html) files have changed (attrib date mod), then run checkmetatags script.

Would you still need the first script? You could just have one that reads from keyword.ini and update your html accordingly if you're only updating keyword.ini?

It sounds like you have it figured out though, good stuff.

To all who've replied, either on this forum or directly to me. As to the original questions which started this thread, I think we covered most of it.

My tendency towards prolixity, as well as the fact that suggestions or questions (automatically) triggers many more questions (on my part), might have caused this thread to grow so big. Some may even feel that the thread has gotten out of hand, that it has strayed from the original question or that I'm deliberately dragging this all along, just to get my url on all o'these pages. So just to be sure, before anyone does accuse me of blatant advertising, I've changed my signature (for now).

All your feedback is highly appreciated and I hope others have found answers to their own questions or have found ideas, trips & ticks or suggestions, which they'd like to use themselves. After all, this is what a forum is for ('em).

As to compliments I've received, I feel honoured. To some it may seem that I've got all thoruoghly worked out. Let's just say that I'm good at understanding (or drawing) the "bigger picture". Back in the good ol' days (when I still had a job), this is all I had to do. Draw (or design) the bigger picture, the high-level architecture. And then others, who are far better (at that) than me, could fill in the technical  specs, write the code or whatever. I guess most or at least some of you have seen guys like me; (sometimes?) arrogant bastards in fancy suits who think they know it all :) While you, the tech-wizzes have to figure out all the difficult stuff (code). Now that I am building my own websight, I do feel my 'bigger picture understanding' to be very valuable, but I'm still not the tech-wiz who can fill in all the tech details an such.

This is where you all come in .... so thankx again to all of you. Your tech trips & ticks are just what I lack myself.