cags

I dont' really understand why you are using RewriteCond's for this anyway. They aren't required, it can be done purely with a RewriteRule, you are just forcing two checks.

Try adding the L flag to the first one, that way any pattern that matches shouldn't progress further through the file. The only way it would is if your rewritten path was a redirect (which it doesn't appear to be).

You will need to ensure that you have wildcard sub-domains set on your DNS, and that they are set to go to the same VirtualHost, you will then simply need something like this... RewriteCond %{HTTP_HOST} (.*)\.domain\.com RewriteRule ^$ /page.php?a=%1 [QSA,L] The RewriteCond capture the subdomain, the RewriteRule matches empty strings (you may wish to amend that part) and rewrite it to the format you requested. The QSA will ensure that the QUERY_STRING from the original URL get's persisted.

If you create a boiled down example and run it on the same server does $_FILE remain empty? i.e. if you have nothing on the page but a form with a file input.

The Rewrite rule you have shown does not match the REQUEST_URI /articles/. What you are seeing is nothing to do with mod_rewrite. You are requesting a path to a directory on the server so your server is doing what it's obviously configured to do and showing it's contents. If you don't want this to happen you need to disable indexes. Options -Indexes

if you always wish to remove the first three characters you should probably consider substr.

Personally I'd bet one one of two things. Your serve uses symlinks and you don't have FollowSymLinks enabled, or perhaps more likely you have the wrong RewriteBase. Try removing the RewriteBase directive and apply a forward slash to the start of the second half of your rule (/view-directory/...).

You have a mixture of different methods applied in your reged. Sounds like you will need negative look ahead and alternation. Give this a try. /%(?!20|30|5B)/i

It's almost certainly to do with escaping of the string. Depending on how you are running the search you probably just need more slashes. In pure regex \$ will match a dollar sign. But if you are using that in a command line tool, you likely have to escape the slash for that too. You can easily end up with strings requiring 4 slashes in order to escape them correctly to allow the correct number to make it through to the actual regex parser.

Is there something more dramatic that you just haven't mentioned, because I really don't see why regex would be used for this. You could achieve what your after simply by str_replace'ing FROM users with FROM users WHERE ...

My point is, you moved the goal posts, then tried to claim they'd been there all along.

You never mentioned in your original post that corporate/5 should go to corporate/5.php, you said it should go to corporate/page5.php. Either way you have enough information in this post to work out what you need. With a rudimentary understanding of regex you should be able to achieve the results you are after. Give it a fair shot, if you get stuck, come back with what you have and I'll maybe help some more.

Either you don't have mod_rewrite enabled on your server, or you are getting an infinite redirect rule (which I don't think you should, but it's sounds like it's causing an internal redirect rather than rewrite. RewriteEngine On RewriteCond %{REQUEST_URI} !-f RewriteCond %{REQUEST_URI} !-d RewriteRule ^([^/.]+)/?$ /$1.php [L] Should fix the first one, by redirecting only if the request is for a file/directory that doesn't exist. If you want to exclude directory names that don't exist then you will have to add another cond in to check if it matches that such as RewriteCond %{REQUEST_URI} !^foobar to exclude foobar from the redirect. As for your other question about page could be other stuff, I have no idea what you are after.

Just swtich the corporate in the first half for ([^/]+) and in the second half to $1 (and switch $1 to $2 in the second rule).

RewriteRule ^corporate/?$ /corporate.php [L] RewriteRule ^corporate/(\d+)/?$ /corporate/page$1.php [L]

Actually that matches two, you are just mis-interpreting the returned data. If you replace the foreach loop with a print_r or var_dump, you will see that $matches is actually an array that contains an array with two matches in it. The way preg_match_all works is to return an array that contains an array of all the full matches (which is $matches[0]) plus an array for every capture group in the pattern. If you actually want to see what you matched it would be... foreach ($matches[0] as $match) { echo $match; }

Pretty certain it's wrong. But you don't give any indication as to what you are attempting to do.

It's certainly not going to work with just what you have. You could add another rule to make that rewrite, the problem with doing that is that you end up with an infinite loop. When somebody visits existing they get redirected to new, which get's rewritten to existing which gets redirected to new... and you end up with an infinite loop. There are hacky ways around it, but I'm yet to come across a neat way.

More details required. The rule you have looks like it will successfully serve up /blog.php?post_id=title-of-the-blog-post if the user requests /blog/title-of-the-blog-post , if you are expecting it to do more than that, it won't.

Do you actually have a files folder in the root directory of your site? It sounds like that is the case and that the server is restricting access to the directory.

Have you checked your apache log, this will likely contain the answer.

As thorpe says, your includes should be a relative file path to where the actual served file is. So since your ugly path is article.php, the include statement within should be a relative file path to that. Assuming article was in root for example and you have a header.php in an includes folder... include 'includes/header.php'; This is not to be confused with the path for css/js/image files though. Since these are requested from the clients browser, which have no idea of the file structure, any src attribute in your file should be a URI path relative to either root (simplest), or the pretty url (get's difficult if you wish to include a css file in your header.php for example, because you could be using your header.php file from different URI 'depths'). <!-- relative to your root directory --> <script type="text/javascript" src="/assets/js/jquery.js" /> <!-- full path --> <script type="http://www.example.com/assets/js/jquery.js" /> These both obviously assume that you have an assets folder in your DOCUMENT_ROOT folder.

Saying it doesn't work, without any more information is about as useful as going to a doctors and saying you are unwell. They know that, that's why you are there, without a description of the symptoms you are never going to receive an informed answer. Sensible responses would have been along the lines of... "I get a 404 page from my browser" "I get a 500 page from my browser" "I see a blank page" "The URL in the address bar changes, but it shows http://www.badgersftw.com, any idea why?" If you don't help us help you, then we either won't be able to help, or just plain won't bother.

The simple answer to your question is yes. If you don't have a static IP address (don't know where you are from, but most people around here don't), a fast internet connection (again, broadband speeds aren't bad here, but nowhere near the upstream speed for running a decent web-server, then you probably don't want to be.