borfast

I'm not sure about why you are getting those errors but you might try this: http://www.wats.ca/resources/httperrorcodes/24

For Invision Power Board, you have IPDyanmic Lite: http://www.invisionpower.com/documentation...oc.php?page=129 There may be others but I don't know any.

Yes, it can be done through phpMyAdmin. In cPanel, under the database section, you have the phpMyAdmin. Beware, the link will open a new window automatically ( Mad!!! ). Then, in phpMyAdmin, select a database you already have - if you don't have one, simply create one with the name you want; in this case you will want to adjust the SQL statements so they won't create the database again - and then, on the top of the right frame, you'll see a link that says "SQL". Click it and you'll have a text box where you can enter the SQL statements directly or, if you prefer, upload the file to the server and let it take care of things for you.

No problem. If you need anything else, just ask

You have a problem with paths, there. Nothing to worry about, you just need to understand relative paths a little better I'll write a brief explanation of how relative and absolute paths work. Let's think of your public_html directory on the FTP server as the root of all paths - / Under that root, you have, among other things, the "Archives" directory and the "menu" directory, which translate into "/Archives" and "/menu". You have "head_sitemap.inc" inside the "menu" directory, so it's path is "/menu/head_sitemap.inc", right? And the file you're using for tests is "history.php", which is inside the "Archives" folder, which will make it's path be "/Archives/history.php". Are you still with me? Good Now, when you specify a PHP include such as require_once("menu/head_sitemap.inc"); you're telling PHP to include the file whose path is the one you specify but which in turn is appended to the directory of the currently executing script - in this case the currently executing script is "history.php" and the folder where it is kept is "/Archives". So what you're actually telling PHP to include in that file is "/Archives/head_sitemap.inc", which doesn't exist What you want to tell PHP to include is "/menu/head_sitemap.inc", so that's what you would have to put in the require_once(...) statement. But in this case, that's not what you will do, because our root folder, /, is not the public_html directory. In the real world, the root directory is... well, the root Every path is built starting from it. And our public_html directory is just a directory a bit under the root directory. In TCH's servers (and mostly in every UNIX system), each account has a "home directory". That directory is usually "/home/yourusername" and that's exactly our case here at TCH. So imagine your username is "duff"; your home directory would be "/home/duff". Inside that directory, there's the "public_html" directory, which is where you place everything you want to be accessible on your web site. So... going back to our "include" problem, the correct absolute path for the include would be "/home/duff/public_html/menu/head_sitemap.inc". There's another way to do this, which is by using relative paths. The difference between absolute and relative paths is that if using the former, you specify the complete path to the directory or file you want to reach, right from the root directory, while if you use the latter, you build the path to the directory or file you want to reach, from the directory where the file you're workin on resides. In this case, using a relative path to reach the "head_sitemap.inc" file would wield this relative path: "../menu/head_sitemap.inc" The "../" means "go up one directory". In our case, since we were in "/home/duff/public_html/Archives/", going up one directory means we'll get to "/home/duff/public_html/" and then we just need to add the rest of the path - "menu/head_sitemap.inc". And now you're probably asking yourself "which should I use, absolute or relative paths?". Well, in my humble opinion, both have advantages and disadvantages. Absolute paths are good because you can use them in a file, put it anywhere in your web site and the paths will always be correct. On the other hand, they are longer and, by consequence, harder to write. If you move your site to another host - not that you'll want to leace TCH - you will probably have to change them all, too, since it's probable that the path to your home directory will change. Relative paths are good because they are shorter and easier to write than absolute paths.But, in my opinion, they're worse than absolute paths, because, using your situation as an example, imagine you'd change the location of "history.php": the relative path would no longer work. Well, this is getting much longer than I expected, so I'll stop here. I think I've explained everything you need to know about this, anyway. I hope it helps

Oh! OK, now I get it! Pat, you probably left the "output" path as it was on an example from sitexpert. That was probably supposed to be changed from "output" to whatever name your folder has. In this case, you told sitexpert to save the menu files into a directory named "menu", so you should have replaced "output" with "menu". Basically, the files you are trying to include are in a directory named "menu", so try it with "menu/head_sitemap.inc", like so: ><?php require_once("menu/head_sitemap.inc"); ?> </HEAD> <BODY BGCOLOR="#ffffff"> <?php require_once("menu/body_sitemap.inc"); ?> That should work

That's odd, PEAR's directory should be in PHP's include paths (and it is), so you shouldn't need to specify anything more than you did... Maybe one of the tech guys can take a look at the PEAR directory and make sure SOAP is installed... though I'm pretty sure it is

Pat, seems like I'm the one who's been dreaming. Or at least sleeping, since I didn't see those SSI includes... Well, you're using SSI includes in a PHP file. I'm not sure if this will work. I think not but on the other hand, I don't see why it wouldn't work. Can anyone say for sure if SSI includes will work inside a PHP file? Anyway, if you went for the PHP option, you should use PHP includes, since the files you're including probably contain PHP code too. Try re-writing your code like this: ><?php require_once("output/head_sitemap.inc"); ?> </HEAD> <BODY BGCOLOR="#ffffff"> <?php require_once("output/body_sitemap.inc"); ?> But from what I've seen, you don't have any "output/head_sitemap.inc" or "output/body_sitemap.inc" files. If I try getting http://www.duff2004.com/output/body_sitemap.inc I get a "404 Not Found" error message. That could be the problem. Are you sure you uploaded those files to the correct directory? Some times we forget that we should upload our web site's stuff into "public_html" and then wonder why things don't work.

Hi Greg, and Welcome to the Family! Well, unfortunately, since this is shared hosting, there's no way you can set up the access rights for the database users You shouldn't have to worry too much about it, though, since you can use a different username and password for your users and the database access. What I mean is that you just need the database username and password if you want to handle it directly. Your users don't need (I think) to know the database username and password because you set those in your code and users will never see it. This way you can provide your users with a certain password that will be checked in your code and the database user/pass are kept safe. If you need some help with this - or anything else - just ask here on the family forums. You'll have an answer to your post before you know

Thanks a lot! It's an interesting script indeed

Pat, I am not sure what the problem could be but from what I can see (the HTML code for each page), there's no code that would create a dynamic menu. I don't have a clue about how that menu system works but I'd say you need to use PHP's inlcludes to include the menu in the pages. Are you doing anything like that? Does that menu system have a readme.txt or some kind of instructions? Is there some place I can look to see what the steps should be in order to set it up? I didn't understand your other question. Could you explain it a bit further?

Seems very interesting, Arvind! Would you like to share the code with the rest of us?

Pat, I believe that SSI and PHP are actually two different things. http://www.wmo.ch/web/www/WDM/Guides/Inter...ossary.html#SSI http://www.php.net And yes, if you need any more help, just ask

Pat, sorry, seems I misunderstood your question. Well, ASP and JSP are not supported on TCH, so you can scrap those out. That leaves you with HTML, SSI and PHP to chose from. I don't know about SSI putting a big strain on servers - actually, I don't think I have ever even used SSI I think I'd go for PHP. It's light, fast and if you ever want to add some functionality to your pages, you have plenty of people to help you

Pat, are you talking about dynamic menus as in menus that are animated? If so, try OpenCube's QuickMenu: http://opencube.com/ or HierMenus: http://www.hiermenuscentral.com

lol No, I'm not using IE. I mean, it's not my default browser but I do have it installed to check if my clients' web sites work well on it. One thing is my personal web site, in which I try to tell people that (IMHO) they could use a better browser than IE. But a client's site is a different thing. I can't risk having someone pay me to make a web site for them and not having it work well on IE, so yes, I do have it installed here on Linux so I can test the web sites I make Tracy, about the images paths, are you sure those are correct? I just tried it again and it still doesn't work. And if I right-click the images, select Properties and copy/paste the image URL into the browser, I get a "404 Not Found" error message By the way, I can't access the Waterscapes, Eagles, Sunsets, Rodeos, Rainbows and Still-Life galleries - I also get a 404 Not Found error for those pages.

I moved this to the pre-sales questions forum to keep things organized (thanks Alan ). About the typo, there's two "your" words.

Tracy, where exactly does that problem (missing images) happen? I visited your site with both Mozilla and IE6 and the only place I found some missing images was inside the galleries - but they're missing in both browsers, not just in IE6. I took a peek at the source code and the problem is that you're missing the leading / on the images paths. For instance, the navbar images: you're referring to them using the URL "navbar/Logo1.jpg". Since the page you're viewing is in http://www.naturalimagesweb.com/gallery/ , that path will tell the browser to look for the "Logo1.jpg" image at http://www.naturalimagesweb.com/gallery/navbar/Logo1.jpg , which doesn't exist. If you use "/navbar/Logo1.jpg" instead of just "navbar/Logo1.jpg", it would direct the browser to http://www.naturalimagesweb.com/navbar/Logo1.jpg and it will work fine. Still, I'm not sure if this is what you were referring to. Is it?

http://www.chrisps.com/index.html is not there, the file is called index.php, not index.html... But it's strange, because I could swear that I clicked the link the first time and it worked... Anyway, http://www.chrisps.com/index.php works fine.

Alan, there's a tiny problem with the links you added: they're opening on the top frame. I suppose you know how to fix that but since I'm feeling helpful today, I'll leave a short explanation anyway It's really easy to fix, just edit the top frame file and for each link, instead of having just <a href="http://domain.com"'>http://domain.com">web'>http://domain.com">web site</a> you should write this <a href="http://domain.com" target="_parent">web site</a> if you want the link to replace your site on the browser window, or this <a href="http://domain.com" target="_blank">web site</a> if you want it to open in a new window. And voilá! OK, I'll go back to work, now

Works fine here, too. Are you sure you have the Flash plugin installed on the browser you're using?

Alan, sorry to hear about your grandfather. I lost my grandfather (my mother's dad) 10 years ago and I still miss him today. It's really hard to lose someone who's close to you Now about the topic... I don't have any links section on my site, so I can't offer a link back to your site but feel free to link to my site if you think it has anything interesting in it. I do have a suggestion for you, though: I would remove the "[...]my site has been scanned using Norton Internet Security 2004, and yes it is up-to-date, with no viruses found[...]" stuff. You see, web pages don't have virus... Some of you might say that McAfee/Norton/whatever once warned you about a website that had a virus/worm/whatever but the truth is: it's not a virus! Some websites may have been programmed in a way that will make your browser crash (as far as I know, such programming will only be effective if the site visitors use IE), or tries to automatically start a download of an executable file (which, in turn, can carry a virus) but this is *not* a virus. A virus is a program that will gain "undesired" access to a system, be it by exploiting a security failure on it - like the ones in Outlook Express, exploited by worms such as the recently released "MyDoom" - or by tricking the user into running the program. After gaining access to the system, the virus will do whatever it was programmed to do - delete files from your hard drive, send itself to everyone on your Outlook Express contact list, etc. Plus - and this is where the big difference lies - a virus will have some way of trying to infect other computers or media. The "original" viruses, the ones back in the good old DOS days, would usually try to infect any unlocked floppy disk you'd read on the infected computer, which, in turn, would infect the next computer where it would be read on. Most of the recent virus usually propagate themselves by means of e-mail messages sent by Outlook Express - this difference in the propagation method is the reason why they're called "worms" and not "viruses". So, in short: HTML, CSS and JavaScript - the programming languages that you use to create a website - are not suitable to create a computer virus, so you don't need to worry about virus in your website. I wrote an article some time ago about why people should use BCC when sending e-mails to multiple recipients. It's related to this virus issue because some virus forward themselves not only to the addresses they find in your Outlook Express contact list but also to addresses they find in messages you have in your mail folders. Here's the link to the article: http://borfast.com/bcc.php I also have another interesting text, if you're interested: http://borfast.com/msie.php It's about Internet Explorer. Anyone who enters my website using IE will be redirected to that page. When I entered your site, I found it funny because you say "[...]if my website looks messed up, or out-of-line to you, I am sorry, I do not test the site in any other browser than Internet Explorer." and on the text I'm talking about, I say the exact opposite: if you do use IE, I don't know how my site will look and I don't know if it will work at all Well, I guess I'm taking too long already. I just wanted to make the suggestion about the virus thing.

Tracy, it's the other way around XHTML needs all tags to be lower-case - and I think DW does convert upper-case tags into lower-case. I could be wrong, though. It's been a long time since I last worked with DW.

If I recall correctly, you can tell DW to automatically format the whole code for you and it will convert all tags to lowercase. I also recall seing an option in DW MX to specify if you want it to write upper- or lower-case tags when you use the WYSIWYG mode. I'm not sure what influence that option has if you chose to write an XHTML document - DW should automatically write lower-case tags.

OK, I was starting to find it weird. I didn't had the time to check it but I was almost sure that you could style an <hr> line with CSS. Unless it was something that only worked on some browsers. I wasn't sure and didn't check it, hence my question. I don't use <hr> much, anyway, so... who cares?