cags

By you saying you've tried that I'm going to go ahead and assume you mean as a RewriteRule. In order to make redirects based on a query string you will need to use RewriteCond's. As a rough guide it can be done something along these lines... RewriteCond %{QUERY_STRING} e=([^&]+) RewriteRule ^contact\.php %1.html ... please take note though that this expects links on your site to be of the form contact.php?e=siemens and that you actually have a file on your system that is called siemens.html.

The first half of a RewriteRule is matched against the REQUEST_URI, the query string (part after the question mark) is not include in this. Why do you wish to redirect all profile page requests to the homepage?

It sounds to me like there might be some confusion in this thread. If a request to example.com/about.php returns the file, then it sounds to me like public_html/example.com is the document root, not public_html as would be the standard (generally speaking i'd set that up as example.com/public_html). If this indeed the case and you are putting the .htaccess file outside the document root then it is not evening being parsed. One way to checkout would be to place the following in the .htaccess file... RewriteEngine On RewriteRule .* http://www.google.com [R=302,L] ... if you can request a page on your site without getting sent to google, the file isn't being parsed. It seems to me, assuming I'm understanding your description correctly, that the .htaccess file should be in folder public_html/example.com/ along with your about.php file (this is essentially what wildteen88 said, just thought I'd clarify the reason).

The question mark in your regex pattern makes the capture group optional, which means an empty URI will match. Simply removing the question mark will probably solve it.

Is the session save path writeable by the Apache user?

Is there a particular reason you don't want to use jQuery, it will make life easier being able to use it's DOM manipulation tools. You could of course just download fancybox or lightbox implementations, but again you say you don't want to do this. The actual displaying of an overlay is just a case of giving an element a z-index higher than everything on the page, and making it fill the screen, there are a couple of ways of doing this, depending on taste and how much browser support you want. Making it display is just a case of adding a click event to the image, and hiding it with a click event on the cross. You can either have the overlay content on the page the whole time, but with display none, then simply use javascript to set it's display value, or you can make an AJAX request to fetch the actual data from the server. The possibilities are endless and without more details there's not a lot we can do to help short of writing something for you (which we don't do) that could be in-appropriate anyway. On a side note the JS stuff should perhaps be a seperate thread in the JavaScript board, linking to this one if you see it as relevant.

Wrap the two icons in a div, give it position: absolute and bottom:0, then make sure that the page 'container' div has position: relative, should place it in the right place.

I'm not really sure TBH. I can't seem to find anything much on error log's being generated after a successful redirect, which seems to indicate that it's failing for some reason, but I know of no reason a .htaccess file would intermittently fail. What type of server are you running this on, do you have access to try moving the code into the vhost rather than a .htaccess file. I can't see it making much difference, but may be an interesting experiment.

Is the .htaccess file in question stored in your Root directory? Do you get an entry appear in the error log every time you attempt to view one of the aforementioned pages? As an outside chance, do any of the resources included on those pages throw 404 errors (the Net tab in FireBug will highlight this for you)?

You could try simply forbidding any request for a file that doesn't exist. Depending on whether you are actually using redirect as part of your web application though this could present problems. If you are not, then something like... RewriteCond %{REQUEST_FILENAME} -f RewriteCond %{REQUEST_FILENAME} -d RewriteRule .* - [F] ... may work. I'm not sure if it will prevent your server crashing. If you need redirect rules, then you should be able to accommodate them, but we'd need to see them to have any clue of how to fix the issue.

The RewriteCond you have redirects any request that isn't for a directory. You therefore request example.com/foo, which successfully re-directs to example.com/index.php/foo, which of course is itself not a directory, thus it will get re-directed. Therefore you need to either also stop it re-writing the index page, or more likely (assuming you will have other files on your sever, like images, css etc.), you need to not redirect requests for actual files. RewriteCond %{REQUEST_FILENAME} -f RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^(.*)$ /index.php/$1

As far as I can remember NC stands for NoCase which basically means make the Regex pattern non-case sensitive. Since your Regex pattern is empty, there's not a great deal of point leaving that one in there. Glad you got it working though.

Sticking something like this in a .htaccess file in your root directory should do the job... RewriteEngine On RewriteRule ^$ /landing_page.php [R=301,L] Alternatively you could consider renaming the landing_page.php to index.php and move the home page into www.mysite.com/home/

I'm assuming that print_r at the top of the page is the $_GET array. On the first page you linked it only contains 2 items, PID and BID, this being so it can't be the two rules you posted clashing/catching the URL otherwise the array would contain a cat value. The URL is therefore matching a rule earlier in the file. You must have another rule(s) in there that only matches against two capture groups. The two rules you posted cannot clash with each other as one has themes.php as a hard code ending and the other contains themes-pg as hardcoded value.

If you don't use sub-domains you could go for something like this... RewriteEngine On RewriteCond %{HTTP_HOST} !^www RewriteRule .* http://www\.%{HTTP_HOST}%{REQUEST_URI} [R=301,L] ...or you could try... RewriteEngine On RewriteCond %{HTTP_HOST} ^mydomin.com RewriteRule ^(.*)$ http://www.mydomain.com/$1 [R=301,L] ...or any number of other solutions depending on the exact situation.

Neither of those rules by themselves will cause a redirect, if the address in the browser is changing then it's being caused by something else.

It was purely a hypothesis, I'm not entirely surprised it didn't work, though I couldn't tell you the reason, I was just making a suggestion on the solution you'd already tried. You could just check if the requested path ends with a forward slash. RewriteRule /$ http://hostbox.us/ [L,R]

The second half of the RewriteRule is the path you will be redirected to. In the case of requinix's code / represents document root. If the .htaccess file is on a sub-domain this will refer to the document root of the sub-domain. If you wish to go to the home page of main domain, just swap the forward slash out with your domain name. RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^ http://www.mysite.com/[L,R]

That's because, as far as I can see, that code would cause an infinite loop. Using your example of /buying, it would get redirected to /buying.php, this request to /buying.php will then hit the server, getting rewritten (as opposed to redirected) to /buying, which will get rewritten to /buying.php... I'm sure you get the picture. Basically what you are trying to do is have your cake and eat it too. But hey, as I always say, you can't eat your cake unless you have it. What you will need to do is to somehow prevent the rewrite from continuously looping. One way of doing this would be to append something to the url and check for it. RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{QUERY_STRING} !rewritten=1 RewriteRule ^([^/]+/)*[^.]+$ /$0.php [L,R] RewriteRule ^(([^/]+/)*[^.]+)\.php$ $1?rewritten=1 [L]

Where are the files stored on your server, and where is the .htaccess file kept?

You mean $_GET['number'] is empty? The code you have looks correct. You could add [R=302] as a temporary measure to see where the URL is getting forwarded to.

Either look into positive look-behind assersions, or cheat and do it the easy way, capture the word function as it's own capture group and make the replacement.. $1<span style="font-weight:bold;">$2</span>

No problem, glad it's fixed. I should also point out that the two RewriteCond's at the start of the file are actually pretty pointless. RewriteCond's only apply to the RewriteRule directly following them. The objective of the Cond's is to make a Rule get skipped if a file doesn't exist, as such the two Conditions would be more properly located before the last RewriteRule you have. This would allow people to access files that actually exists on the server without getting redirected. Of course if all files that don't have a rule associated shouldn't be accessible then you could just scrap the Cond's altogether.

Good News, I've spotted what's wrong with your post. It's the Massive, garish yellow writing.

It sounds like you are simply trying to get the auto_increment value of the record you just inserted, if this is the case the mysql_insert_id will do this for you with a lot less effort (and more accuracy) than attempting it yourself. $querya = "INSERT INTO vtindex (vtindex_type, vtindex_sesid) VALUES ('$type', '$sesid')"; $resulta = mysql_query($querya); $newObjid = mysql_last_insert_id(); I could have misinterpreted, it's early.