cags

Use the i modifier.

No it is not possible. You cannot have the title in the URL and extract from the database based on the ID without also having the ID in the URL. One approach that some sites use is to have /id-title and use a rule such as ^(\d+)-[a-zA-Z0-9-]+/?$. If you echo out your URIs in this style you then have the ID you need to query your database. The other approach, which leaves a cleaner URL (as you don't need the ID at all) is to add a permalink/slug field to your database and query the database based on that instead of ID.

1) It's not entirely clear what you mean here. The combination you have there will redirect any page request to the mypage.com domain to the URL specified (i.e. http://www.mypage.com/main/about-us/%{REQUEST_URI}), is that really what you wish to do? Either way, if you want to also match requests to the www. domain then you can use... RewriteCond %{HTTP_HOST} ^(www\.)?mypage.com [NC] But bare in mind this will cause a redirect loop. If for example you requested http://www.mypage.com/foo, Apache would do a 301 redirect to http://www.mypage.com/main/about-us/foo. Since the %{REQUEST_URI} will also match the .* pattern you are using this will then get redirected to http://www.mypage.com/main/about-us/main/about-us/foo and so forth, continually adding in main/about-us/ until the server hits it's redirect limit and throws a 500 server error. 2) There is no reason why that should display anything other than a blank page as you are not echo'ing out anything, you are simply sending a 404 response code to the client. This is not the same as Apache triggering a 404 error and redirecting to a 404 error page. The header you are using is what should be used for creating custom 404 events. If variable can only be 1 of 4 values you would be better off checking this before PHP is invoked, using something like... RewriteCond %{REQUEST_URI} ^(var1|var2|var3|var4) // whatever rewrite rule This way you will only be rewriting the valid URLs and all other URLs will throw the 404 error.

Your post in the freelance board doesn't once state explicitly (nor even implies IMO) that you will simply be doing the design side of things. You advertise that you will make a 'custom website'. Your 'About Me' section states that you are a 'web designer / developer' and also further down on the page you state 'PHP is the main language I use for the websites I create.'. Your resume claims you have created two complete database driven sites. Overall I would say you are giving the impression you are capable of something which you are clearly not. You should consider advertising yourself as a web designer and then perhaps mention that you have basic experience in PHP. P.S. Just out of interest, how old are you? Your site seems to imply that you graduated with a degree in 1997, which would seem to make you at the minimum 30. This really seem at odds with you clause of "My tutor must be male because I have a girlfriend" in your tutor post. Not to mention it also seems at odds with the amount of money that you claim you need to earn in order to live.

Sounds more like a problem with the way you are outputting links on your site than the actual RewriteRules you are employing. If you are using relative links and you have a RewriteRule that is more than one directory deep you will run into issues. Make all the URLs absolute.

You can't change that rule to achieve that result. Just add another rule.

The mod_rewrite package is capable of working on the Windows platform just fine, I use it on my localhost (Windows 7, previously Windows XP). It does indeed sound like they are jerking you around. The thing I don't understand though, is the fact that most hosting companies charge extra for windows based services due to licensing costs, thus they are almost asking you to downgrade, which sounds a little strange. Perhaps it is a limitation in the way they have things set up, but it's certainly not a limitation which stems purely from a windows based server.

If you try... echo '<pre>'; echo $_POST['mixembedlink']; echo '</pre>'; ...does the output look exactly the same as what you are pasting in the input? I'm guessing you've got something like magic_quotes enabled and it's inserting backslashes into the string, thus causing it to not match the pattern.

Technically the exact translation of that code would be... $text = preg_replace("#[^0-9]#", "", $text); The i modifier makes the match case insensitive, which ereg_replace isn't (that's what eregi_replace was for). Having said that, it's purely academic since you have nothing in your pattern that would be affected by case sensitivity.

Sounds like essentially the same problem/solution as before, it sounds like you are echo'ing out a href with a path of 'page/something', any path that is interpreted on the client side needs to be absolute.

The problem is with your HTML not your rewrites. You almost certainly have something along the lines of... <script type="text/javascript" src="js/cool_mojo.js"></script> Despite the fact you have rewritten the file on the server side, the client has no way of knowing this. All the browser knows is that it it requested '/page/something', so when it encounters a path of 'js/cool_mojo.js', it thinks the path is '/page/js/cool_mojo.js'. The solution to your problem is to simply use paths relative to the root '/' a.k.a absolute paths. <script type="text/javascript" src="/js/cool_mojo.js"></script>

Then it clearly isn't a 'Facebook' field as you indicated it as.

ProjectFears answer looks roughly correct. The main problem with your original code was the placing of backslashes before the fullstops. This negates it's special meaning of 'catch-all' and makes \.* match 0 or more fullstop characters.

If it is a Facebook field, you really shouldn't be allowing/expecting the user to type in the http://www.facebook.com/ part, they should only be typing in their profile name, which can be matched with a very simple pattern. I'm not sure on the exact requirements, but it's probably al-num with dash.

That's a matter of opinion. Since it only applies to the content of that folder, why would placing it in the root folder make any more organisation sense? From a pure ease of use standpoint, keeping your rules all together may make sense, as I say, it's a matter of opinion. For performance reason it should probably be placed within a conf file.

Tables are satan, you really should... oh wait... This is done with mod_rewrite, which is an Apache module that you must have activated. You will then simple need to create a .htaccess file for you site that contains the approriate rewrite rules. And then, and this is important, you update all links in your scripts to point to the 'pretty URL' (but don't change anything about how you are working with the $_GET variables, just the output of your links). A simple example of the sort of thing you would need for this task. <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / #check not a real file or directory RewriteCond %{REQUEST_URI} !-f RewriteCond %{REQUEST_URI} !-d #rewrite the url to where the actual file is RewriteRule ^([a-zA-Z0-9_-]+)$ master?contentpage=$1 </IfModules>

There is no reason you can't locate the .htaccess file within the profile folder. You just have to bare in mind that you no longer need to match the profile section as this will have been stripped off the URL you are comparing.

There's a green button in the bottom left of threads you started, labelled 'Mark Solved'.

Several of the user submitted comments on that page demonstrate the use, clicking through a few pages will give other examples, you are already using the e modifier.

The . capture all special character doesn't match newline characters unless you specify the s modifier.

\[ - matches a square bracket (the backslash escapes it because otheriwse it will have a special meaning). \w+ - matches one or more word characters a single space character will match a single space character or \s will match a whitespace character, or if you wish it to be a bit more viewable [ ] will match a space. You should be able to come up with something from there. Post what you get if you can't figure it and we'll see where we can go from there.

Just to offer up a fresh perspective. I'm also interested in doing this as a career, I'm degree educated (which frankly means squat in terms of knowledge, but it *should* demonstrate the capacity to learn) though not in web technologies per-se as it was a Computing Science degree. Over the last few months I've applied to maybe a dozen jobs in my region (East Midlands, UK), all of which have been for 'Junior Developer', all of which have said 'Must have 1-2 years commercial experience'. I've not heard back from a single one.

In the form processing script you should be able to check $_SERVER['HTTP_REFERER'] is equal to your submit form. This won't however necessarily prevent SPAM.

a.) RewriteCond's only apply to the RewriteRule directly below them. b.) There seems a lot of inconsistencies in your rules, your first RewriteRule redirects to a path beginning with a forward slash, whereas your others don't. This is likly supposed to be there as you don't have a RewriteBase directive.

It got there through some vulnerability or other, most likely your computer being infected with something and the FTP. But it could be a problem with the security of your host or your scripts. It basically redirects all requests to your site that were directed there from any of the listed sites, that doesn't have the listed words in the user agent and redirects them to the link at the bottom. Based on the expansive list I would guess it's purpose is supposed to be to hijack bots from your site. Having said that it appears to also ignore user agents with the words bt, yahoo or google in them.