Hello! This is a simple tutorial that will show you how to have cleaner URLs for your maplestory CMS! Most sites have a url structure so that every page is like this:
An easy way to make cleaner looking URLs is to use the Rewrite Module for Apache. To have cleaner URLs, you must have that module activated. In wamp, you can do this by clicking the icon, clicking Apache, then Apache Modules, and then selecting "rewrite_module."
After doing this, open up notepad, and then save the file. When saving the file, change the file name to ".htaccess"
Change the "Save as type" to "All Files"
Once you have done this, open up your .htaccess file with your favorite text editor, and copy and paste this text:
Code:
RewriteEngine On
RewriteRule ^register index.php?page=register
RewriteRule ^downloads index.php?page=downloads
RewriteRule ^rankings index.php?page=rankings
RewriteRule ^donate index.php?page=donate
This will change all your URLs from index.php?page=pagename to domain.com/pagename
If you have more/other pages, you can follow the pattern.
If you have any questions, comments, or a better way to do this, comment below!
Your .htaccess does indeed generate "cleaner URLs" but in my opinion, there are quite a few problems with the above .htaccess code.
Firstly, there is an issue with maintaining such routes. If for example you are building a content management system, you can not expect your clients (aka the users) to modify the .htaccess code. They require a much more user-friendly approach when it comes to let's say... adding pages or removing them. The method you provide for "cleaner URLs" is an oversimplification of route handling and makes your source code dependent on the .htaccess.
The second problem is that ALL HTTP GET query strings will be omitted besides "?page=...". Now, this can come as a benefit and as a disadvantage. The plus side is that you are practising security through obscurity in that you are closing off all potential loopholes that GET query strings may present - they may be modified by the user or may even contain user submitted data (potential MySQL injection, directory traversing, etc). On the contrary, you are now only limited to using POST requests when dealing with the URIs listed in your .htaccess. How will you go about carrying out pagination in your rankings page? Sure, you can submit a POST request each time a user selects a different page or filter type, but that is not exactly RESTful and the pages generated based on the POST payload will not be cached in comparison to those generated by GET requests and thus there will be a decreased performance. I quote from RFC 2616 Fielding, et al:
GET said:
The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process.
POST said:
The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:
- Annotation of existing resources;
- Posting a message to a bulletin board, newsgroup, mailing list,or similar group of articles;
- Providing a block of data, such as the result of submitting aform, to a data-handling process;
- Extending a database through an append operation.
Essentially:
Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.
Hypothetically speaking, if I attack a page with GET requests, nothing on the server should change. The same result should be yielded for a certain operation - correct me if I am wrong, my explanation is not terrific.
There are a few solutions you can take to address the above problems. The latter can be easily resolved through the addition of a QSA flag which:
Appends any query string from the original request URL to any query string created in the rewrite target
But that would mean goodbye to security through obscurity...
Taken together, I believe aaronweiss' method is the best and personally, the recommended approach I would say as it addresses both problems I highlighted above. His method will allow routes to added or removed on the go without any changes being made to the .htaccess. You can even use regular expression to match the parts of the URI and route the request to its assigned controller (if you are following an MVC approach) or its assigned resource and/or method (if you are following the RMR approach). The second issue can also be addressed as once again, you can use regular expression to match for page numbers of filter types, for example: /ranking/all/1/ or... /ranking/job/thief/1 and so on.
Consequently, you will gain all benefits. Security through obscurity, caching (performance) and maintainability. This method goes hand in hand with the MVC and RMR architecture so your end result will most likely be a well organised and structured code that is easy to work with.
Either way would work, I suppose. But pretty much all CMS's that have been released here use the $_GET model.
Yours does too... you are passing the page name into $_GET['page'] so you will probably end up with the usual switch case routing system which is extremely redundant and if not, you will possibly end up autoloading with little room to expand on the routes (e.g. pagination).
Just a side note, you could have simplified your code to:
Code:
RewriteRule ^(.*)$ index.php?page=$1
Or you could replace (.*) with a list of accepted pages separated by |.
Also, I just noticed a third problem in your code. You did not specify the "end of string" through the use of $. So even if I visit: domain.com/registerlololherpderp123 I will be redirected to the registration page. Forgive me if this is what you intended on doing... it just doesn't seem right.
Code:
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}\.php -f
RewriteRule ^(.*)$ $1.php
If you don't have any URL structure on your CMS (most older CMS' and some of the newer CMS'), use the above on your htaccess file to hide the php extension to have the same effect as greenelfx's thingymabob.
Uhm no. I don't see any point in suppressing the PHP extension in your case. There may be potential collisions in the directory URL and the URI. Also, it does not really have the same effect as greenelfx's .htaccess as his code suggests a centralised routing system while yours suggest a decentralised one - each route has its own file.
--
I apologise for the lengthy post. I may have made a few mistakes here and there (both grammatical and web development wise) but I'll double check when I wake up as I've been awake for some time now :\