Follow these steps to get rid of the index.php from your URLs:
Log in to concrete5.
Click on the Intelligent Search box in the top-right corner.
Type
pretty, and while you type, concrete5 searches for the correct entry. Once found, click on Pretty URLs.Check Enable Pretty URLs and hit on Save; you should see the following screen:
concrete5 should have created a file called
.htaccessin the root of your website (C:\BitNami\wampstack-5.4.10-0\apache2\htdocs\.htaccess). This is the file where the rewrite rules are stored that removeindex.phpfrom the URLs.
Congratulations, you're done! concrete5 is running and you've also activated some options to improve the behavior of concrete5.
You've enabled pretty URLs, which uses the Apache mod_rewrite module to rewrite URLs. You can now open a subpage by entering http://localhost/about/ without having index.php in the address. In case you'd like to know more about this Apache feature, this is the official documentation:
http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html
.htaccess
is a configuration file most commonly used by Apache to configure Apache modules on a directory level. It's a simple text file you can open with any text editor of your choice. If you haven't worked with Apache before, the content might be a bit confusing but concrete5 took care of it. You shouldn't have to modify anything on your own in this file.
Note
Pretty URLs can also be used with Microsoft IIS but you need to install a rewrite filter first.
If you want to try it on your own, you can find a solid and free rewrite filter at this address: http://iirf.codeplex.com/.
As mentioned previously, there are a lot of folders in concrete5. Most of these top level folders are empty—resist the temptation to delete these as they are required for customizations. To give you a head start, here's a short list of the most important folders:
Folder | Explanation |
|---|---|
| You can find custom blocks and block templates in this folder. You'll learn more about blocks in the next few chapters. |
| Probably the most important part, this is where all core files, the actual CMS is located. Never update anything in this folder. |
| The folder where concrete5 puts the configuration files. |
| The file manager stores your files in this directory. |
| This is where you have to put add-ons if you install them manually. |
| The concrete5 auto update feature puts the new core in this directory. Never update anything in this folder. |
There are a few more folders but you probably won't need them unless you dive deep into concrete5. There's one important thing to remember when working with concrete5: The directory concrete looks a lot like the root directory, but never change anything in the concrete directory. You'll find several directories in both places. That's because you can override a single file by placing it in the same structure in the top level.
Here's one example without going into too much detail. Later in this book, we're going to work with a block called content block, a few times. This block basically adds a formatted text to your page. The actual output is printed from this file: /concrete/blocks/content/view.php. How can we change that file without causing any problems with updates? Simply copy the file and place it here: /blocks/content/view.php. The structure is the same; there's just no concrete in the path. You'll have to create some directories first, but at the end, you just copy and paste a file and can then change
its content.
As we've mentioned previously, every request to a page in concrete5 is forwarded to index.php. You might be able to see this by looking at the URL which starts with index.php, but if you enabled pretty URLs, this is hidden by some Apache mod_rewrite instructions. No matter which option you're using, index.php
is always involved.
The actual logic is located in a file included by index.php, which you can find in concrete/dispatcher.php. Every time you request a page, the code of the dispatcher is executed. If you want to dig deeper into concrete5, you'll want to have a closer look at this file at some point. For now, let's just have a look at this quick summary of what happens in the dispatcher:
Initializing the error handling
Fetching all constants and configurations necessary for the site
Loading the database classes and establishing a connection
Creation of a session necessary to remember things such as login information
Loading all settings related to localization
Checking events that have to be run at some point
Parsing of the URL and fetching the correct object from the database related to the current URL
Rendering of the page object as well as all its blocks
You can find more information about the dispatcher flow on this page: http://www.concrete5.org/documentation/introduction/dispatcher-and-application-flow/.