cags

Define doesn't work. That looks more of less correct. With that in place you should be able to take one of your 'pretty' urls, paste it in your address bar and view the correct page. Once that works the final stage is to change how you output the links on your page to match the pretty version. Et Voila, jobs a good un'.

You can't, without serving your js files with PHP. A simple solution would be to simply add them in a JS block in your document head as variables, these will then be available in your other scripts. <script type="text/javascript"> var ROOT_URL = '<?php echo ROOT_URL; ?>'; </script>

Use a full URL, domain inclusive. A common solution in Frameworks is to set a variable / const at the start of your landing page using something along the lines of... define('ROOT_URL', basedir(__FILE__)); Basically you need to store a value in root that's accessible from wherever you need to output a path.

Yes, it is.

http://www.derekmartin.ca/2008/11/06/utf-8-uris-mod_rewrite-and-accents/

You will probably have to use the \x characters for them.

assuming images is in your root... "/images/plus.gif"

The IfModule block will simply stop the server from erroring out if mod_rewrite isn't installed. If you don't get 500 Internal Server Errors without them, then you certainly don't need them. With regards to your 404 issue, it's difficult to say, the rules you have seem pretty apt for what your after. As a useful debug tool I always put R=302 in as a flag when I receive errors like this. That way it will perform the re-direct and you will see in the address bar what file you were attempting to serve. Normally this leads to an obvious reason for the 404. If I had to guess I'd go with it being something to do with relative paths, and try putting a forward slash before the $1.php.

What do you mean that the address for your images is now "http://localhost/freeoglasi/kategorije/1/cars/images/plug.gif"? Do you mean that is the value that's in the src attribute of your image tag? If so then your problem isn't your rewrites directly it is your script, and you need to change the paths you are putting in the src attribute.

Thanks for providing your solution, it could come in handy in the future for somebody else in a similar situation. Although one of the more quiet forums, they still get plenty of daily views by fairly knowledgeable people. The main reason you didn't get a response is likely to be that zeus is pretty rare (I'd never even heard of it). Plus you did solve your own problem in a little over half an hour, which is not exactly a long time for somebody to answer such a question.

You need to edit inc.header.php and change the src paths for your css /images, they need to be paths relative to root not relative to the current file (they should either be full paths beginning with your domain or they should begin with a forward slash. When the 404 document is displayed it appears to the user that it's location is the URI they requested. Therefore if your css path is 'styles/base.css', a request for /somefolder/somefile.html will make the clients browser attempt to download yoursite.com/somefolder/images/base.css, if you simply changed the path to be '/styles/base.css' it would always request yoursite.com/styles/base.css. It can get a little confusing working out the difference between using server relative paths and client relative paths.

RewriteCond's only apply to the RewriteRule directly following them, thus only your first rule applies if the files don't exist. The second rule will apply regardless of it's existence.

It's possible but it starts to get a bit hacky at that point. One way is to 301 redirect all requests to the page that don't have a specific query string, then simply append that query string when you rewrite the URI.

If you want your links to not contain a file extension, you have to remove the file extension. That's all there is too it I'm afraid. All mod_rewrite does is intercepts incoming requests and serves up a specific resource, which you configure based on various patterns. For example, if your site uses php files you could use something like the following (quick example, could be typos)... RewriteEngine On RewriteCond %{REQUEST_URI} !-f RewriteCond %{REQUEST_URI} !-d RewriteRule ^[^.]+$ /%{REQUEST_URI}.php [L] ...this will take all requests to the server for files that don't exist and attempt to serve up a file with that name. So let's say somebody request http://www.domain.com/contact then it would attempt to serve up the file http://www.domain.com/contact.php.

The only way of doing it without an id number is by generating unique slugs based on the name. A common way of doing this is simply replacing non-url safe characters with a hypen, checking if it's unique and then incrementing a counter on the end in cases where it isn't, until you find a unique slug. Alternatively, due to the fairly small chance of you getting the same name on the same day, a lot of people use a date structure in their URL, such as /2011/07/26/my-title-here. The basic idea boils down to the same thing though, you need a value unique for that 'article' that you can query the database for. Once you have that you can bang a unique index on it to make searching quicker and Roberts your aunties brother.

It sounds like Apache isn't configured properly to serve whatever file type your index file is. It is probably a PHP file and PHP isn't set-up correctly. On the plus side, it sounds like Apache is indeed installed successfully

Congratulations... you just did...

I believe that \w will match A-Za-z0-9_ and the + means 'one or more of'. Your patterns with [a-z] will only match a single lowercase letter.

The tilde's in this case are delimiters, they don't have to be a tilde, it can be one of many characters, I forget what the exact requirements are but it's practically anything that isn't a word character I believe. As a rule of thumb the delimiter use should simply be a 'character' that is unlikely to appear in the the pattern you are attempting to match. The delimiters are in place to separate the pattern you are matching from the modifiers. In your case you don't have any modifiers, but you can have for example ... $pattern = '~\b' . $word_escaped . '\b~i'; ... to make the pattern case insensitive. You can find a list of the supported modifiers on the PCRE pages of the manual.

You could look at a component based framework such as Symphony 2, that way you can pick and choose which components to use and which to switch out. I've done some reading on it because it's something we are looking to move to at work (from Kohana), though I can't claim to say I know a great deal about it.

The \b matches word boundaries, that is to say the space between a 'word' character (letter, digit or underscore) and non-word character. The preg_quote function simply escapes the characters so that if you're pattern had, for example \b in it, then it would match the two literal characters \ and b rather than another word boundary.

The top level array represents the capture groups, and the inner arrays are the items in each capture group. Since you don't use a capture group in your pattern you only get the resulting match of the entire pattern. Therefore if you wish to loop through all of the strings that matched the entire pattern you can use ... foreach($strng[0] as $url) { echo $url; }

Check the error reports. If I had to pluck a guess out of the air, I'd say you have RedirectRules in your .htaccess file, and mod_rewrite either disabled, or Apache configured to not allow overrides!

Yup, that should do the trick.

Ahh, well given the fact that you do in fact want all the pages to end up at the same page, then yes, that does make a bit more sense. Something like this should do the job... RewriteCond %{QUERY_STRING} user=[a-zA-Z0-9_-]+ RewriteRule ^profile.php$ / [R=301,L] ... though by the sounds of it you don't even need that much, since you aren't actually using the username, is there a reason you are matching against it in the query? Can you not just redirect any requests to profile.php to the home page?