Occasionally we get questions from people who have installed mojoPortal content management system and created pages in their site asking why they can't find their pages on disk. The reason is because CMS pages that you create in mojoPortal do not correspond to files on disk, mojoPortal CMS stores its data (other than user uploaded files such as images) in the database. The HTML output for pages is created on the fly from the database content and served to the web browser whenever the page is requested.

All the CMS pages, that is the pages in the main menu, are served by yoursiteroot/Default.aspx?pageid where pageid is an integer corresponding to a row in the mp_Pages table in the database. By the magic of url re-writing you will see friendlier urls in the browser like home.aspx or whatever-you-name-your-page.aspx (you can also use extensionless urls without the .aspx extension). These friendly urls are mapped to their real url Default.aspx?pageid=x, so when a request for the friendly url comes in it is re-written to the real url on the server but you see the friendly url in the browser. You can look at the url mappings from Administration > Advanced Tools > Url Manager, which shows all of the friendly urls and the real urls they map to. Of course there are also a lot of physical .aspx pages on disk for administrative features, here we are discussing only CMS pages which are virtual pages created by users.

So Default.aspx is the real page that serves all of the CMS pages. Basically it loads the layout.master (which is like the outer skeleton of html) from your skin and there are up to 5 content regions available on any given CMS page where features can be loaded. Which features are loaded and the content for individual features also comes from the database. All features consist of at least a UserControl (ie a .ascx file), and they may also link to feature specific supporting pages. Simple features such as the Bing Map feature for example may consist of only the UserControl, but more complex features like the Blog and Forums may have several supporting pages. When features link to their supporting pages they must pass in the pageid and ModuleId in order to keep the context of the page and the roles and permissions of the page and the feature instance (also known as module, each feature instance has a unique ModuleId passed in the url as &mid=y). There are helper methods available that features may use to enforce the role security, these methods verify that the feature does exist on the page to prevent any escalation of privileges by url manipulation. You can study the source code of included features to see how the permissions are enforced.

Individual features may also use friendly urls for feature specific supporting page urls. For example, the Blog feature has a UserControl like any other feature, and the UserControl is loaded into a CMS page, but it also has supporting pages. The UserControl has a list of blog posts, but each blog post has its own detail page served by /Blog/BlogView.aspx?pageid=x&mid=y&ItemID=z (where ItemID is the ID of the individual blog post), if you click the title of a blog post in the list it goes to this page, but again since it uses friendly urls mapped to the real url, what you see for the url in the browser is the friendly url /your-blog-post-title.aspx. On the other hand, the Forums feature uses supporting pages but does not use friendly urls so it is easier to see how the parameters are passed around in the urls when you navigate around in the forums.
 

Last Updated 2011-04-23 by Joe Audette