IP.Content 2.0 Dev Update: Friendly URLs for Databases

[bfarber]

IP.Content is a complex framework that allows you to create and manage website content in many different ways. You can embed blocks and databases into pages, and pages can be wrapped by templates. You can define page names and use friendly URLs through the IP.Board built-in FURL system, you can use friendly URL's through the included index.php file with IP.Content (for instance, if you want your website in the root of your domain, and the forums in a subfolder), or you can optionally not use friendly URLs at all. Because of the many configuration options, and the fact that you are already embedding a database within another friendly URL system of sorts (given that you define the filename of your page already), friendly URLs were not supported in IP.Content 1.


They will be in 2.x, however.


We have added support for databases in IP.Content 2.x to utilize friendly URLs. To make use of this support, you will need to be using an existing friendly URL method (accessing IP.Content through the included index.php file, or using IP.Board friendly URLs).

The index page of a database lists the categories contained within the database, and is accessed by accessing the page the database is embedded on. For example, if you embed your database on a page called "database.html", then you may access your category index page at

http://domain.com/database.html

In IP.Content 1.x, if you clicked on a category from this page, you would see a URL similar to the following

http://domain.com/database.html?category=1

Arguably, the URL is still "friendly", but "?category=1" doesn't really tell you much about the link you are clicking on. In IP.Content 2.x, you will now define the friendly URL name for the category by editing the category in the ACP. The upgrade process will automatically set a friendly URL name for your categories based on the category title, but you have free-reign to go back through and set the categories to be accessed as a different name if you wish. If I set the category 1 friendly URL title to be "ipb-rocks" for instance, the URL to the category is now

http://domain.com/database.html/_/ipb-rocks

Because categories are defined by administrators and we are able to do error checking while saving your category configurations, categories do not require any additional information in the URL (such as the category ID).

This page will list the records stored in the category. In IP.Content 1 those records would be accessed as follows:

http://domain.com/database.html?record=1

Again, this isn't unfriendly, but we can do a little better. Similar to topics in the forums, records will automatically inherit their title based on the specified title for the record. For instance, if the record title is "IP.Content is cool!", it will be automatically rewritten to the following URL

http://domain.com/database.html/_/ipb-rocks/ipcontent-is-cool-r1

In this instance, because titles can be duplicated and we wouldn't want to restrict record titles purely to prevent URL conflicts, we must add a marker with the ID to the end of the URL. IP.Content in turn uses this information to load up the proper record when this URL is requested. This is pretty useful in and of itself, however we went a step further.

IP.Content is used by many different customers in many different fashions. On some sites, anyone can submit to the database. On some sites, only administrators submit to the database. Because of the different configuration options, and because some databases are small and very controlled by nature, we knew that some administrators would like to remove the record ID from the end of the URL. So we built in support to do just that. If you would like to remove the "-r1" from the end of the URL in the last example, you need only login to the ACP, load up the record to edit it, and within the ACP you will have the option to specify the friendly URL for this specific record. If you manually specify a friendly URL for the record, it overrides the dynamic friendly URL and is used instead. You will not be able to set this same friendly URL for any other record, naturally, but you can edit the URLs at any time should you need to. Thus, you can turn the above record into the following URL

http://domain.com/database.html/_/ipb-rocks/ipcontent-is-cool

You may have already noticed, but it's important to note that IP.Content utilizes the category hierarchy within the URL for records, including for any sub-categories you may have configured. If you do not utilize categories for your database, that's fine as well - IP.Content will already know this and omit the category from the URL without issue.



While not related to the friendly URLs, there's something else I'd like to point out while we're discussing friendly URLs in IP.Content. You are not required to specify an extension for the pages you create in IP.Content, if you don't want to. If you didn't realize this, you can rename "database.html", in our example, to just "database" and the page will continue to function just fine. If you did so, your URL would become

http://domain.com/database/_/ipb-rocks/ipcontent-is-cool

I know some of you are going to ask about the "/_/" marker in the URLs posted above. It is not a typo. Because of the complexity and many configuration possiblities (pages can be in folders, which can be subfolders, with or without an extension, and so on), IP.Content requires some sort of "marker" in the URL so that it knows when the rest of the parameters are database information. We thought about setting some sort of word for this marker (i.e. "news") but quickly realized this isn't feasible, because everyone uses their databases for different purposes, and many of our customers do not speak English natively. Additionally, you may run one more than one database, however the marker itself is global to IP.Content. While the marker will ship as "/_/" in IP.Content 2.0, you can change it if you desire by editing a constant in an IP.Content file. We felt that having this constant was the the best way to ensure you had control over the marker, should you wish to change it, given that we cannot store this information as an ACP setting for technical reasons.



Your requests for friendly URLs in IP.Content 2.x have been heard. They will be available, and will work right out of the box based upon your existing configuration. We have much more in store, so stay tuned!

View full blog entry