"Here's all the patterns that every project needs!"

"All patterns are bad and you should feel bad if you use them!"

In this post I will talk about what Architectural Patterns are, when they matter, when to use them and when not to.

I will list out a few patterns in a way that I hope will share understanding rather than dogmatic positions that are often held by tech influencers on social media.

What Are Architectural Patterns?

An architectural pattern is a solution to a specific problem that arises in the design of a project. They come in the form of separating concerns, grouping functionality, abstracting implementation details, and dictating conventions for the team to use.

Patterns can be as simple as breaking features into predictable functions, or to complex layers that handle a multitude of use cases.

When Should One Use Patterns?

When you find your code being hard to navigate, disorganized, difficult to maintain, or having trouble on-boarding new developers, using patterns can make some sense of the chaos.

If you find that your project has a problem, sometimes a pattern will resolve your problem. If your project doesn't have the problem that the pattern addresses, or if you don't understand what problem the pattern address, don't use the pattern.

It's as simple as that.

After 16 years of experience with many CMSs (Content Management Systems), I have found that they benefit greatly from Architectural Patterns, or that the lack of patterns can hinder growth and modernization over the years.

Of all the CMSs I have experience with, mojoPortal is the one I know most about, is dearest to my heart, and the CMS that I will use to showcase my position on patterns.

"I Don't Feel Like I Need Patterns"

This is a good indicator that you don't need patterns. If you are a solo developer, are in a small team, or it's just a side project, there might not be a need for you to even consider a pattern.

If you have a project that later in its lifetime you feel like you would benefit from a pattern, refactoring is always an option.

What are Common Patterns and the Problems They Solve?

There are so many that I couldn't possibly list them, but I'll list a few I've had experience with, and some that I believe to have value in the CMS realm.

Layered (N-Tier) Architecture

If you're familiar with mojoPortal, it mostly implements this pattern.

The idea behind this pattern is to separate functionality concerns into these project layers:

The Data Access Layer holds all implementation code for storing and manipulating data. It becomes the only API for the application to interface with your data, be it from a file, a database engine, or another system.

The Business Layer is the only layer that references the Data Access Layer. It holds domain entities (classes that represent tables in a database for instance) and the logic to bring the data together in code representations of the application features.

The Presentation (Web) Layer is the only layer that references the Business Layer. This layer is for "presenting" the features in the application. It could be a Windows Application or a Web Application, but the main thing it does is give a user interface to the code features from the Business layer.

The reason I said mojoPortal "mostly" implemented this pattern is because while the project is split into the proper layers, a lot of the business logic wound up in the Web (Presentation) Layer. This has made it very difficult to attempt to migrate away from the Web Forms framework it was built on to a more modern and capable framework.

The pros of this pattern are everything is grouped in a logical fashion and you know where everything belongs.

The cons of this pattern are that every layer is tightly coupled to the previous layer. This can be difficult later down the road when replacing dependencies or dealing with providers for services throughout the application. This leads into the next pattern.

Clean Architecture

The purpose of this pattern is much like the previous pattern, but with some tweaks and the implementation of another pattern to facilitate changes to make up for the previous pattern's downfalls.

Much like the Layered Architecture pattern, the application is separated into several projects.

It differs on some key points.

1. All interaction between layers is done through the use of contract interfaces.
   What this means is unlike layered architecture, instead of directly referencing the implementation of a service, you reference the interface the service implements. This allows for easily swapping out the implementation if needed.
2. The layer references are moved around a bit. Rather than each project pointing to the previous project, the projects are placed in an encircling shape, all pointing inward or towards each other in their layer.

The Layers are as such:

The Domain Layer is the ultimate authority of the entire application. It contains all the domain concerns and contracts for the application with no references to any internal or external dependencies. All other layers can use this layer. This layer is often coupled with the Domain Driven Design pattern, but it's not required.

The Application Layer contains the business logic of the application and the contract interfaces that are to be implemented in the Infrastructure layer. Often times this is where the CQRS and/or Vertical Slice patterns are used, but it's not required.

The Infrastructure Layer is where all implementations for the contracted services in the Application are kept. All external dependencies/libraries are abstracted here, allowing for easy replacement from one library to another if needed. An example would be if your project started by supporting SQL Server but later a migration to PostgreSQL was in order, the only assembly that would need to be edited or replaced would be the Infrastructure assembly.

Sometimes the Infrastructure Layer will break out only the database concerns into its own Persistence Layer(s), keeping the database specific code in it's own layer(s), but this is not required.

The Presentation Layer brings everything together through the use of the Inversion of Control Pattern. This allows each layer to register services in the IoC container using the interface contracts and keeping the implementation details hidden from the application. The IoC container handles the dependencies for all services that are registered to it, allowing the system to keep track of lifecycles and dispose of objects so that the implementation reference is kept in one location.

A cool thing about Clean Architecture is that one could have multiple Presentation Layers but share all the core functionality from the Application Layer. Do you need a multi-page website but want to administrate it through a mobile app? The answer could be two Presentation Layers, an MVC/Razor Pages layer for the website, and a Web API layer in conjunction with the mobile app for administration.

The pros of this pattern are that it's incredibly versatile while enforcing strict separation of concerns and external dependencies allowing for a very long-lived application.

The cons of this pattern are that it's moderately complicated, where boilerplate could become monotonous if the application doesn't need to use the pattern.

mojoPortal would have benefited a lot from this pattern being implemented properly, as migrating to .NET (Core) from .NET Framework would have consisted of replacing the Infrastructure layer using the same Application Layer contracts, and rebuilding the Presentation Layer in a .NET (Core) UI framework. The majority of the application wouldn't change.

More Reading:

• The Clean Architecture - The Clean Code Blog [Uncle Bob]
• Clean Architecture - Medium
• Domain-driven Design - Wikipedia

The Repository and Unit of Work Patterns

The Repository pattern is an excellent pattern for data access. The Unit of Work pattern compliments the Repository pattern by allowing for bundles transactions for data integrity.

The Repository pattern's goal is to abstract repeated logic for data manipulation and querying. It allows you to have a single "GetById" method that works for all tables with the code being written once. It keeps your code DRY and makes it easy to do things like adding global query filters for features like soft deletion.

The Unit of Work pattern creates a "unit of work" for each action you take when mutating data. If you need to save a blog post, but it needs a new category that does not exist, the UoW will prevent bad data from being saved if creating the category fails by not saving the blog post. It's an interface for database transactions, if you're familiar with how those work.

Some people raise issue to the Repository (and Unit of Work) pattern when using Entity Framework, as Entity Framework implements its own versions of those patterns. This is completely understandable for application that will realistically never wish to change the library that connects to the database. However, from experience, I would rather have everything in my application have its own contracts to facilitate that possibility of change.

mojoPortal's Data Access layers all use ADO.NET, and their contracts are the implementations, which has made changing to something like Entity Framework for easy migrations and multiple database providers very hard. If the Repository pattern was between the layers, replacement would be a much more feasible.

More Reading:

• Repository Pattern - DevIQ
• Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application - Microsoft

The Query Specification Pattern

The Query Specification pattern is another pattern used in tandem with the repository pattern. It allows us to create domain level specifications that we can use in the Application Layer without having to expose an implementation's API.

For instance, we can create a "GetBookWithAuthors" specification that just takes a Book ID, and pass the specification to the Repository's "FirstOrDefaultAsync" method that will be sure that the underlying data access code will return the appropriate Book with Authors for that book.

More Reading:

• The Specification Pattern in DDD .NET Core - Medium
• Specification Pattern - DevIQ

Plugin Architecture Pattern

The Plugin Architecture Pattern is a pattern that facilitates the ability to add or change functionality of the application with the use of third party bundled code. Most CMSs support this pattern, mojoPortal has its own way of handling modules (plugins) that achieve the same goal.

It's quite simple, the main application provides a set of APIs (the Plugin Interface) that a plugin developer can implement in their plugin, and then register their code with the Plugin Manager, which is responsible for loading and running the Plugin code.

More Reading:

• Create a .NET Core application with plugins - Microsoft
• Plugin Architecture Pattern Overview (.NET) - Nash Tech

Bringing it all Together

By using the Clean Architectural pattern, we have a good foundation to allow us to plug and play any implementations through the use of contract interfaces and Dependency Injection. In the event that the database code needs to be swapped out, a third party library needs to be replaced due to a security vulnerability, or having the ability to provide different implementations for selection through the application's settings, this will help facilitate these use cases.

Using the Repository, Unit of Work, and Query Specification patterns we can prevent repeating code for querying data and we abstract away data query implementation, and it allows us to support or swap database providers at runtime.

The Plugin pattern allows for us to expand the application in any way that is needed. Be it adding new features (Blog, Forums, Event Calendar, CRM, etc.) or modifying an existing feature (swapping out authentication methods, listening for events to modify data, etc.) it makes the application as flexible as possible.

Conclusion

These are what I believe are the foundational building blocks for a CMS like the next version of mojoPortal could use, and who knows? I might be doing just that. 😉

Does that mean that all applications should use Clean Architecture or the Repository patterns? Clearly not.

Patterns are like shoes, if they fit and do the job that you have a need for, use them, otherwise don't. Just don't make the mistake that if your application doesn't need patterns that no one needs patterns, as many people on the internet so readily declare.

Media wishing to learn more about this event, please send all questions to  

FOR IMMEDIATE PUBLIC RELEASE:

i7MEDIA has purchased mojoPortal and all of its commercial modules

Kearney, Mo (Feb 6,  2017) - It is an exciting day for the mojoPortal project! i7MEDIA, a longtime supporter of the mojoPortal project, has completed the purchase of the open source project and the commercial modules available on the mojoPortal website from Source Tree Solutions.

Joe Davis, i7MEDIA President, has been strong supporter of mojoPortal since 2008. Joe built his business around this versatile and user-friendly content management system. i7MEDIA, is dedicated to furthering the development of mojoPortal and its tools.

Rest assured mojoPortal will remain an open source project and there are no plans to change that. However, I7MEDIA has plans for expanding mojoPortal to help it stay relevant and provide the very best .NET CMS platform on the market today. 

Joe Audette, of Source Tree Solutions, is very enthusiastic about the new life of mojoPortal:

Joe Davis and i7MEDIA have always been the most qualified consultants for mojoPortal other than myself, and I've always had great confidence in referring customers and projects to them over the years.  Joe Davis has been a good friend and has been my go to guy when I needed to refer a customer or project that I did not have the capacity for. Whether you need design help, hosting, or custom feature development, i7MEDIA is the team you want with years of experience. mojoPortal was my baby for over a decade, and I am very glad to know my baby is in good hands! Long live mojoPortal! Joe Audette, mojoPortal Founder

mojoPortal has always been easy for users to add and manage their content. Over the past few years, though, it has fallen behind other systems which have taken more modern approaches to management and more fully utilized the capabilities of modern browsers. i7MEDIA has developed add-on features for mojoPortal which make content management easier and they are working on packaging these features for the masses to use.

Development of add-ons for mojoPortal isn't necessarily hard but there is a bit of a learning curve and quite a few steps one must take to prepare a working development environment. The focus will be on cutting down on the number of steps and making the process easier overall. They will also explore possible MVC and WebApi implementations of some features, especially administration features like the File Manager. 

It has always been possible to create beautiful sites with mojoPortal but the built-in skins were not good examples. i7MEDIA is working on providing newer skins to help showcase the power or mojoPotral.  i7MEDIA is committed to making sure that mojoPortal is seen as a designer-friendly CMS. 

A new version of mojoPortal is scheduled for release in the next couple of weeks with several small fixes, a few clean bootstrap-based skins and a brand-new file manager to replace both of the current file managers and the link and image picker used in the WYSIWYG editors. That's right, one file manager that does it all. 

For the latest news, check out mojoPortal’s Facebook and Twitter feeds.

As you may know, Joe Audette, founder and chief developer of mojoPortal, has announced that he will no longer be developing mojoPortal.

In the 7+ years I have known Joe and worked with mojoPortal, i7MEDIA has become the most trusted and experienced mojoPortal consultancy in the world. We have happy clients on every continent except Antarctica ranging in size from small start-ups to major international corporations and organizations. We've built and helped others build hundreds of mojoPortal sites. Most of our projects involving mojoPortal are still operational and we're adding more even as I'm writing this post.

Technology moves fast and that's a good thing, but sometimes it can move at a pace which can cause businesses to lose money if they're not careful. Whether a small company spends a few thousand dollars to build a nice website and customer portal or a large one spends several thousand dollars, scrapping what they have and building new just because there's a new technology (or even not new but more popular) doesn't make business sense.

We have a lot of clients who are using perfectly good and reliable WebForms systems like mojoPortal. We take a great deal of pride in the support we provide to our clients so we will be supporting and even providing enhancements to mojoPortal until we don't have any clients needing it anymore. After speaking with several of our clients over the past couple of months I can tell you, definitively, that we'll be supporting mojoPortal for quite a long while and that's fine by me and my team of mojoPortal experts.

So, if you're using mojoPortal already and you are looking for support, we will help you. If you're considering using mojoPortal because of its rich feature set, we will help you. Contact us today so we can help you!

The Canon

The process for upgrading mojoPortal is no different if you are upgrading from a really old version or a relatively new version. mojoPortal doesn't have "minor" updates or "major" upgrades. The terms update and upgrade can be used interchangeably when referring to mojoPortal. Version numbers don't mean much, version 2.4.0.0 didn't necessarily contain any more new features or bug fixes than 2.3.7.2. The version numbers increase by 0.0.0.1 each time a database change or a set of database changes is needed. There are never "upgrade" or "update" packages released by mojoPortal. All releases packages contain a full installation which if copied to an existing site will upgrade the site. If you do not backup your site and database before upgrading, you are not being responsible.

Process Overview

1. Take the Site Offline
2. Backup the Site Files and Database
3. Prepare the web.config File
4. Copy New Files to the Site
5. Bring the Site Online
6. Run the Setup Page
7. Make Skin Changes if Needed

Take the Site Offline

You want to do this prior to backing up the site because once the site is offline, no one can make any changes to it. If you were to backup the site before taking it offline, someone could make a change which is not backed up.

To take the site offline, add an "App_Offline.htm" file to the root of the site. The root of the site is the same location where the web.config file resides. You can download an example App_Offline.htm here.

Backing up

There are many, many ways to backup files and databases. We will cover two methods for backing up files and two methods for backing up databases (one for MSSQL and one for MySQL).

Backing up Files When You Have Access to the Server's Desktop

Use this method if you have access to the servers desktop. If you don't have access to the servers desktop, use the FTP method.

In general, you will want to browse to the location of your site files. If you do not know what this is, you should contact your server admin or, if you are familiar with IIS, check the physical path for the site in IIS. Once you have located the site files, select all of them and create a zip file of them. We use 7-Zip but you can use whatever you like.

Backing up Files with FTP

Download a good FTP client which provides verbose logging and an easy way to retry operations which may have failed. We use FileZilla and recommend it above any other FTP client.

Open your FTP client and connect to your server. Download all of the files in your site to a directory on your computer. Check the FTP Client's log for any failures and re-download any files which did not download properly.

Backing up MSSQL Database in SQL Server Management Studio

Use this method if you have access to the database using SQL Server Management Studio (SSMS). Some hosting providers provide this access but the more security minded hosting providers (like i7MEDIA) do not. If you cannot access the database with SSMS, use your hosting providers control panel tools to back up your database. If you are an i7MEDIA customer, follow the instructions in our "Backing up and Restoring SQL Server Databases" knowledge base article.

Create the Backup

1. Open SSMS and connect to the database server hosting the database.
2. Right-click the database in the Object Explorer of SSMS and then select Tasks > Back Up. For further instructions, read the "Create a Full Database Backup" article on the MSDN website.

Backing up MySQL Database using MySQL Workbench

Use this method if you have access to the database using MySQL Workbench. Some hosting providers provide this access but the more security minded hosting providers (like i7MEDIA) do not. If you cannot access the database with MySQL Workbench, use your hosting providers control panel tools to back up your database. Many hosting providers do provide access to a tool called PHPMyAdmin which you can use to back up your database as well. If you are an i7MEDIA customer, follow the instructions in our "Backing up and Restoring MySQL Server Databases" knowledgebase article.

Create the Backup

1. Open MySQL Workbench and connect to the database server hosting the database.
2. Select "Data Export" under "Management" in the Navigator.
3. Select the database in the "Object Selection" panel.
4. Select your desired options in the Options section and click the "Start Export" button. Note: do not select the "Skip table data" option because you will not end up with any of your site data if you do select this option.

Prepare the web.config File

You should use the web.config file which comes with the mojoPortal release. This cannot be stressed enough because trying to compare every line of your old web.config file and the new one will take a long time and you may miss something. Nearly all of the settings you might change should be done in the user.config file anyway so you shouldn't have many changes to the web.config file in the first place. A few exceptions to this rule are listed below:

machineKey

The machineKey is used for encryption and decryption of authentication cookie data and view-state data. In mojoPortal it is also used for encryption and decryption of stored passwords if the Password Storage option is set to "Encrypted." You should copy this from your previous web.config file to the new web.config file. Read our "Separating Sections From the mojoPortal web.config File" article if you have a lot of sites and don't want to modify the new web.config for each of them.

Keys Related to Large File Uploads

The httpRuntime and requestFiltering elements in the web.config help with the support of large file uploads. If you have made changes to these elements, you will need to copy those changes to the new web.config file. Read the Supporting Large File Uploads article in the mojoPortal documentation for more information on this topic.

Keys Related to Error Pages

The configuration of custom and http error pages for a website hosted in IIS is saved in the web.config file. If you have changed these settings from the default values, you'll need to copy them over to the new web.config file. The customErrors element contains the settings for handling .net related errors and the httpErrors element contains the settings for handling http errors (e.g., 404). Tip: take a look at our article "Pretifying the mojoPortal Error Page" for information on how to modify the .net error page.

If you have several items which cannot go in the user.config file, you should keep them saved in some kind of notes file with the site. For best security, save your notes file with a .config extension to prevent it from being download via the web.

Note: this is an upgrade, not a new install so you should not copy create a new user.config file.

Copy New Files to the Site

If you have access to the servers desktop you can simply copy the files from the release (with changes made to the web.config) to the location of your site files in the order listed below. When prompted to with the option merge existing folders or not, select "yes." When prompted to "Copy and Replace" for existing files or "Don't copy," check the "Do this for all conflicts" checkbox and then click the "Copy and Replace" option.

If you are accessing the site with FTP, again be sure you are using a good FTP client. Using the FTP client, upload all of the files in the order listed below. When prompted to overwrite existing files, choose whichever option overwrites the existing files.

Order to Copy or Upload New Files/Folders

1. Setup folder
2. ClientScript folder
3. Data folder
4. All other files and folders

Bring the Site Online

The site was taken offline by adding the App_Offline.htm file to the root of the site. To bring the site back online, all you need to do is rename or move the file. We generally customize our App_Offline.htm files with customer logos so we simply rename the file to App_Offline.config instead of moving it elsewhere.

Run the Setup Page

The setup page runs all of the database scripts for all of the features which have database changes. It also processes all of the feature configuration files which control what settings you see on the settings page for module instances.

To run the setup page, open a web browser and go to http://www.yourwebsite.url/Setup/Default.aspx. Once all of the scripts run, you will see a summary at the bottom of the page along with a link to the site.

If you see any errors, you will need to address them. Generally, you shouldn't see any errors but we have compiled a short list of the most common errors.

Setup is disabled. To continue, please set DisableSetup to false in Web.config.

This is showing up because the DisableSetup key in the web.config or user.config file has been set to true. If you were logged in to the site prior to upgrading, you will not see this error. To get around this, open the user.config file and change the setting to false. Next, open the web.config file and add a space to the bottom of the file. Finally, reload the setup page.

The system cannot connect to the MSSQL database. Please check your connection string.

The Connection String key in the user.config file is not correct. This error is always accompanied by more detailed information to help you troubleshoot the problem. If the database server can be accessed, it will state something to the effect of "...error occurred while establishing a connection..." If the database name, username or password is incorrect, it will state something to the effect of "the login failed."

Make Skin Changes if Needed

The skins in the mojoPortal release packages are not copied over the skins used by sites (located in \Data\Sites\[sitenum]\skins). The skins located \Data\Skins are updated or appended with the updated or new files from the release package. If you are using a skin which came with mojoPortal and have not modified it, you can copy it from \Data\Skins to \Data\Sites\[sitenum]\skins.

If you are using a custom skin or you have modified a packaged skin, you should check the "Important Skin Changes" article in the mojoPortal Documentation for details on any changes you need to make to your skin to support the new release. You will want to check the details of every version between your old version and the new version you are installing. This is rather easy as the changes are listed in descending order in the article and there aren't very many.

Summary

See, it's rather simple. You don't need to worry about database scripts, different methods for minor or major versions, lots of file merging or anything like that. Really, all you need to do is create a backup and copy over the new files.

If you run into problems, check out the mojoPortal Forums. Do a search for your issue before posting because someone else may have already reported the problem and resolution has been provided by the community.

Want someone else to do it?

If you would rather have someone else handle upgrades for you, check out our Upgrade Service.

Want to learn more about mojoPortal?

If you enjoyed this guide and would like to learn more about mojoPortal, check out our Training Classes.

SwiftBlue is the first in a series of template skins developed by i7MEDIA for mojoPortal. It was designed as a contribution to the mojoPortal community and the html5mojo project. SwiftBlue has been created with semantics-friendly HTML5 Markup.

Check out the live demo website to see what your mojoPortal website could look like today!

Features

As with all i7MEDIA Skins, SwiftBlue has detailed style for every feature found in mojoPortal, most notably for the Event Calendar, Event Calendar Pro, Blog, Forums, Feed manager, and jPlayer Media Players.

Other features include:

• Support for a number of content templates is included in SwiftBlue. Using these templates makes it easy to make your data appear on the page in a nice professional format. It doesn't cover everything, but it will help you with the basics so you can spend more time perfecting your content and less time worrying about basic layout.
• SwiftBlue is HTML5 friendly. Not sure what this means? We explain more on the live demo site.
• Custom styled dedicated Sign in and Register pages, this way potential users don't have to sort through the regular page content to find what they need to interact with the site.
• A fancy User Bar based on Twitter Bootstrap. The bar includes a lot of features, links to mojoPortal, member profiles, and the ability for administrators to toggle the settings and edit links - this way you can see your site the way your users do. But mostly it's just beautiful.

Support

The SwiftBlue help center is built to ensure that your time working with SwiftBlue is successful.
The skin help center covers topics like:

• Installation of SwiftBlue
• A basic introduction to CSS Classes and how they effect you in mojoPortal
• An explanation of how to use the SwiftBlue Content Templates
• A FAQ to answer common questions about SwiftBlue

And if that's not enough, we've set up an easy way for you to request help or report a bug. Check out the SwiftBlue Skin-Help center now.

SwiftBlue is just another way you can make your mojoPortal site shine with a little help from i7MEDIA.
Interested? Check out the SwiftBlue live demo site

Well, here's an extremely easy way to hide the links without sacrificing the usability of mojoPortal. This solution is completely skin based so it doesn't require any additions to the mojoPortal core.

First, we add the following to our skin script (see "Optimize Your mojoPortal Skin Scripts" for more info):

function HideEditLinks() {
	$(".modulelinks").hide();
	$(".ModuleEditLink").hide();
}

function ShowEditLinks() {
	$(".modulelinks").show();
	$(".ModuleEditLink").show();
}

$(document).ready(function() {
	var editLinksState = Get_Cookie('editLinksState');
	if (editLinksState != null) {
		if (editLinksState == 'hidden') {
			HideEditLinks();
		}
		if (editLinksState == 'visible') {
			ShowEditLinks();
		}
	}

	$("a#togglemodulelinks").click(function() {
		editLinksState = Get_Cookie('editLinksState');
		if (editLinksState == null || editLinksState == 'visible') {
			HideEditLinks();
			Set_Cookie('editLinksState', 'hidden')
		} else if (editLinksState == 'hidden') {
			ShowEditLinks();
			Set_Cookie('editLinksState', 'visible')
		}
	});
});

Second, we add the following inside the AutoHidePanel in the layout.master:

<a href="#" rel="nofollow" id="togglemodulelinks">Toggle Edit Links</a>

The code above simply hides the links if they're shown and displays them if they're hidden.

Placement of the "Toggle Edit Links" link can be done with CSS but it should definitely be inside of the AutoHidePanel. The AutoHidePanel will ensure that the link isn't shown unless one of the Admin Toolbar items is shown. You could add another AutoHidePanel to the layout.master but there's no point in increasing page load if you don't have to.

Happy mojo-ing!

Here's the code for it:

<portal:WelcomeMessage id="WelcomeMessage" runat="server"
	CssClass="greetinglink"
	RenderAsListItem="true"
	OverrideFormat="Welcome, <a id='lnkMyAccount' href='https://i7media.com/Secure/UserProfile.aspx' title='Manage your User Account'>{0}</a>" />

The {0} is where the user name will be placed.

And that's that. Happy mojo-ing!

Create the Skin Script and call it from the layout.master

1. Create a new js file in your skin directory, I usually name it skinscript.js.
2. Add your javascript to the new file. Don't use <script> tags, you don't need them in javascript files.
3. Add the following to your layout.master. I usually add this right after the <asp:ScriptManager control.

   <portal:SkinFolderScript ID="sfs1" runat="server" ScriptFileName="skinscript.js" AddToCombinedScript="true" />

Copy all the scripts from your layout.master to the Skin Script

This is the part that can be a little bit tricky because not all scripts are going to work properly when combined with other scripts. If you copy the scripts to your new file one at a time and test the result, you'll find those pesky ones that will not cooperate. Just leave them in the layout.master, or if you're feeling froggy, rewrite them so they can be combined.

A note about SuperFish

Most of our skins use a SuperFish menu but the scripts for the SuperFishmenu come in two parts. One is the static script that is in the ClientScript directory which contains all of the SuperFish magic. The other is an initialization script that is loaded in the layout.master of the skin. Typically, these are loaded by adding the layout.master a <portal:SiteScript control to load the main SuperFish script and then a <script> element with a bit of jQuery to initialize the SuperFish menu. We decided to use the jQuery .getScript() method to load the main script from our Skin Script. Using this method allows us to initialize the SuperFish menu only if the main script is loaded properly.

A Sample Skin Script

The script below is what we use for starting our skin scripts. It includes the JavaScript for the Administration Toolbar Menu, SuperFish Menu and a neat bit of jQuery that will give the "Add File" button in the Shared Files module a hover state. The script is written out long-form so you can easily see what it does. I suggest that you minify the script before using it in production.

//  ========== 
//  = This file stores all of the scripts that would normally be placed inside the layout.master
//  = Use the following syntax for referencing this script from the layout.master.
//  = 
//  ==========

/*Standard JavaScript */

function HideMenuToolbar() {
	$("#toolbar").fadeOut();
	$("#toolbarbut").fadeIn("slow");
}

function ShowMenuToolbar() {
	$("#toolbar").fadeIn();
	$("#toolbarbut").fadeOut("slow");
}


/* jQuery Scripts */
$(document).ready(function() {

	/* Admin Toolbar */
	$("span.downarr a").click(function() {
		HideMenuToolbar();
		Set_Cookie('openstate', 'closed')
	});
	$("span.showbar a").click(function() {
		ShowMenuToolbar();
		Set_Cookie('openstate', 'open')
	});
	$("span.downarr a, span.showbar a").click(function() {
		return false;
	});
	var openState = Get_Cookie('openstate');
	if (openState != null) {
		if (openState == 'closed') {
			HideMenuToolbar();
		}
		if (openState == 'open') {
			ShowMenuToolbar();
		}
	}

	/* Superfish Menu */
	/* Get Superfish mojoPortal Script */
	$.getScript("/ClientScript/jqmojo/mojosuperfish.js", function() {
		$("ul.sf-menu").supersubs({
			minWidth: 1,
			maxWidth: 27,
			extraWidth: .2
		}).superfish({
			pathClass: 'current',
			pathLevels: 0,
			delay: 500,
			animation: {
				opacity: 'show',
				height: 'show'
			},
			speed: 200,
			dropShadows: false,
			autoArrows: true
		});
	});
	/* This will make the Shared Files "Add File" button have a hover state */
	$("div.uploadpanel > div > input + div + div").hover(
		function() {
			$("div.uploadpanel div .jqbutton").addClass("ui-state-hover")
		},
		function() {
			$("div.uploadpanel div .jqbutton").removeClass("ui-state-hover")
		});
});

Further Reading

If you're serious about optimizing the speed of your mojoPortal site, I highly suggest you read the "Improving Your YSlow or Page Speed Score" article in the mojoPortal Documentation.

Happy mojo-ing!

Form Wizard Pro (FWP) is a great tool for creating ad-hoc style forms on the fly in mojoPortal. One feature that makes FWP so great is the ability to import and export Form Definitions and individual Questions.

Exporting a Question

Exporting a Question is very simple, just click the "Export Question" link next to the question in the "Edit Form" screen. The file will be named like "FWP-Instance-NameYYYYMMDDHHMMSS-q.config." This includes the name of the FWP instance, the exact date and time you clicked the export link, and a "-q" to let you know this file is a Question, not an entire form. You can of course change the name of the file without causing any problems for importing the question later.

Exporting a Form

Exporting an entire Form is also very simple, just click the "Export Form Definition" button at the bottom of the "Edit Form" screen. The file will be named like "FWP-Instance-NameYYYMMDDHHMMSS.config." This includes the name of the FWP instance and the exact date and time you clicked the export button. Again, changing the name doesn't harm anything.

Importing a Question or Form

Importing a Question is very straightforward. Simply click the "Browse" button and select a Question definition file from your computer and then click the "Import Question" button. You'll see the question added to the "Edit Form" screen.

You can import a Form Definition the same way you import a Question, except that you will want to select a Form definition file and click the "Import Form Definition" button. One very important thing to keep in mind is that importing a Form will erase all of the questions you already have on your form. Any data that has been submitted to the form will still be intact but the questions corresponding to the data will be gone so the data will be "orphaned" so you may not know what all of the responses mean.

Some Form Definitions For You

Download

Happy mojo-ing!

For introductory information on the LoginView control, please review the MSDN Documentation for it.

An example scenario is: The client wants to display a Login control on every page and when the user is logged in, some links should be present in place of the login control. A title should be present above the control with the text "Please Sign In: " for Anonymous Users and the text "Welcome Back" for Authenticated Users.

For this scenario, the solution would be to place a LoginView control in the layout.master with the mp:Login control and "Returning Visitors ..." title inside the AnonymousTemplate. The links and the "Welcome Back" title will be placed in the LoggedInTemplate. You may recognize that the Portal:WelcomeMessage control uses the OverrideFormat property as discussed in our Customizing mojoPortal's Welcome Message for Logged In Users article.

<asp:LoginView id="lv1" runat="server">
	<AnonymousTemplate>
		<h2 class="moduletitle">Please Sign In:</h2>
		<mp:Login ID="login1" runat="server" SetRedirectUrl="false" />
	</AnonymousTemplate>
	<LoggedInTemplate>
		<h2 class="moduletitle">
			<portal:WelcomeMessage id="WelcomeMessage1" runat="server" 
				RenderAsListItem="false" 
				OverrideFormat="Welcome Back {0}" 
				CssClass=" "
			/>
		</h2>
		<ul>
			<li><asp:HyperLink id="lnk1" runat="server" NavigateUrl="~/members-only-articles.aspx" Text="Articles"/></li>
			<li><asp:HyperLink id="lnk2" runat="server" NavigateUrl="~/members-only-downloads.aspx" Text="Downloads"/></li>
			<li><asp:HyperLink id="lnk3" runat="server" NavigateUrl="~/members-only-forums.aspx" Text="Forums"/></li>
			<portal:LogoutLink id="LogoutLink1" runat="server" RenderAsListItem="true" ListItemCSS=" " CssClass=" "/>
		</ul>
	</LoggedInTemplate>
</asp:LoginView>

The result can be something like this:

Anonymous

Authenticated

Happy mojo-ing!

​Well, if you have mojoPortal 2.3.6.1 or higher, it is quite easy. You can override it in your skin's layout.master file by setting a property on <portal:WelcomeMessage like this:

OverrideFormat="My name is {0}", or if you only want the user name then you could put OverrideFormat="{0}"

The {0} is replaced by the user's display name.

I prefer OverrideFormat="Welcome Back, {0}" which displays "Welcome Back, Joe Davis" very nicely.

Hope this helps you out. If it did, please spread the word through Twitter or Facebook!

Happy mojo-ing,
Joe Davis

Are there any other topics you would like to see in the documentation? If so, send us an email and we will do our best to take care of it for you.

Using GreyBox

mojoPortal comes bundled with Greybox which is a great in-site pop-up utility that can be used for displaying images and even other webpages in an in-site pop-up. It is used in the image galleries, help system, skin previewer, and a lot of other areas of mojoPortal

You might be interested to know that you can use GreyBox in your mojoPortal site without utilizing the ImageGallery or other features of mojoPortal that use it. Simply add the rel="gb_image[]" or rel="gb_page[]" property to any link and the the link target will open in a GreyBox pop-up window.

For example, clicking the thumbnail below will open the full-size image in a GreyBox window:

<a href="https://i7media.com/Data/Sites/1/blogdata/lightbox-dsc06798-full.jpg" rel="gb_image[]" title="4th &amp; Broadway, San Diego, CA (C) Joe Davis">
	<img alt="" src="https://i7media.com/Data/Sites/1/blogdata/lightbox-dsc06798-thumb.jpg" width="133" height="100" />
</a>

The link below will open the mojoPortal website in a fullscreen GreyBox window:

<a href="http://www.mojoportal.com" rel="gb_page_fs[]" title="mojoPortal, The World's Greatest .NET CMS">Open mojoPortal in GreyBox</a>

Open mojoPortal in GreyBox

There are a lot of other neat things you can do with GreyBox that you may not be aware of so I recommend checking out the GreyBox website for more helpful hints.

Using LightBox with MojoPortal

Some people like other utilities like LightBox (the jQuery version), for example. I will demonstrate to you how to use LightBox alongside GreyBox with mojoPortal.

The Setup

1. The first step to using LightBox is to download the jQuery-LightBox release from http://leandrovieira.com/projects/jquery/lightbox/. Once you have downloaded the release, extract it to your local hard drive.
2. Using your favorite FTP client (mine is FileZilla):
   1. Create a new directory under \ClientScript named lightbox and upload jquery.lightbox-0.5.min.js, jquery.lightbox-0.5.css and the images directory included in the zip to this new directory.
   2. Browse to the directory containing your site's skin (\data\sites\[SiteNumber]\skins\NameOfSkin and download the layout.master file.
3. Using your favorite HTML editor (mine is Notepad++):
   1. Add the following lines to the layout.master directly after the <asp:ScriptManager control

      <link href="https://i7media.com/ClientScript/lightbox/jquery.lightbox-0.5.css" type="text/css" rel="stylesheet" />
      <script type="text/javascript" src="https://i7media.com/ClientScript/lightbox/jquery.lightbox-0.5.pack.js"></script>
      <script type="text/javascript">
      	$(document).ready(function(){
      		$('a.lightbox').lightBox({
      			imageLoading:	'/ClientScript/lightbox/images/lightbox-ico-loading.gif',
      			imageBtnClose:	'/ClientScript/lightbox/images/lightbox-btn-close.gif',
      			imageBtnPrev:	'/ClientScript/lightbox/images/lightbox-btn-prev.gif',
      			imageBtnNext:	'/ClientScript/lightbox/images/lightbox-btn-next.gif'
      		});
      	});
      </script>

4. Back in your FTP client, upload the modified layout.master file.

Using LightBox

Now to use LightBox, all you need to do is add lightbox as a class on any link that you want to open in a LightBox pop-up. For Example:

<a href="images/image-1.jpg" class="lightbox" title="my caption">
	<img src="images/image-1-thumb.jpg">
</a>

You can see more examples on the LightBox website.

See It In Action

Some Friendly Words of Caution

Including additional javascript files in your site will make it run slower. The difference in speed may be negligible when adding just one script but don't get carried away.

Also, you may have noticed that I put the CSS and Images in the ClientScript\lightbox directory. I did this because I couldn't get the LightBox to work properly with those items in the \Data\Style directory like they should be. Also, I couldn't get the script to work with the CSS being loaded from the CSSHandler so I had to put a reference to the CSS file in the layout.master. This should not be done without thoroughly testing your site and making every attempt to put the CSS file where it belongs, in the CSSHandler's style.config.

Conclusion

In the end, I prefer GreyBox primarily because it is already built-in to mojoPortal and it does more than LightBox. If you find that you want to use something along with GreyBox, you can adapt this post to whatever tool you decide to use. It should help get you on your way.

Happy mojo-ing!

This is really nice for the community as we don't have to worry about renewing our licenses and purchasing upgrades. Pay for it once and forget it. Sounds pretty darn good to me.

I have from time to time needed to show a page's title within the content as a heading. The controls that come with mojoPortal don't really allow for this but I have come up with a handy little control that will show the Page Title on the page and allow you to choose how the text is rendered.

To get started, create two files; PageTitle.ascx and PageTitle.ascx.cs. Place both of these files in the <siteroot>\Controls\Custom directory (Note: You will have to create the "custom" directory). The code for the files is as follows:

<%@ Control Language="C#" AutoEventWireup="true" CodeFile="PageTitle.ascx.cs" ClassName="PageTitle.ascx" Inherits="Controls_PageTitle" %>
<asp:literal ID="litPageTitle" runat="server" />

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using mojoPortal.Web;
using mojoPortal.Web.UI;
using mojoPortal.Web.Framework;
using mojoPortal.Business;
using mojoPortal.Business.WebHelpers;

public partial class Controls_PageTitle : System.Web.UI.UserControl
{
	protected void Page_Load(object sender, EventArgs e)
	{
		PopulateControls();
	}

	private void PopulateControls()
	{
		PageSettings currentPage = CacheHelper.GetCurrentPage();
		if(currentPage == null){ return; }
		if(currentPage.PageTitle == "")
			litPageTitle.Text = currentPage.PageName;
			else
				litPageTitle.Text = currentPage.PageTitle;
	}
}

To use the control, place the following in your layout.master directly after <%@ Master...

<%@ Register Src="~/Controls/custom/PageTitle.ascx" TagName="PageTitle" TagPrefix="cc1" %>

Now place the following where you want the Page Title to appear in the layout.master.

<cc1:PageTitle id="PageTitle1" runat="server" />

Come back soon to see a full description of how this all works.
I have decided not to describe the full functionality of this control as it is fairly self-explanatory and because Joe Audette has implemented this functionality into mojoPortal. You can use the <portal:PageTitle control after the next release.

Happy mojo-ing.

If you follow Joe's directions or you are using a skin that came with 2.3.3.4 with the toolbar enabled, you will have a toolbar that looks like this:

While this serves a perfectly good function, there are a few things about it I don't like. It is gray and there are no icons depicting the links. I happen to like icons and bright colors so, I came up with this:

Skinning the toolbar was very easy because it is all controlled by CSS. This article is meant to help you understand how to skin the toolbar but if you like what I've done, you can just download it here.

Create a copy of the jqtoolbar UI resources

The CSS and images for the toolbar are located in the \Data\style\jqtoolbar directory. The CSS is in the style.css file so I created a copy of this file and named it style-7.css.

Set site skin to use new CSS file

For the skin to use the new css file (style-7.css), I had to change the line below in my style.config file located inside of my skin directory (\data\sites\1\skins\myskin). Notice I am referencing style-i7.css and not style.css.

<file cssvpath="/Data/style/jqtoolbar/style-i7.css" imagebasevpath="/Data/style/jqtoolbar/">none</file>

Change the background color of the toolbar

To change the color of the toolbar, I simply changed the background-image CSS rule on the div#toolbar and div#toolbarbut selectors to a background-color rule and set the color to #FFFF99.

Add icons to the links

To add the icons, I added an attribute to each of the controls for the links in the layout.master. To keep the markup valid, I used the rel attribute. I set the value of the rel attribute to a descriptor of the link itself (e.g.: rel="admin" for the admin link). I then used this new attribute to apply a different background image to each link.

It is important to note that this approach will not work with IE6 as it doesn't understand how to select an element based on it's attributes. The next release of mojo will allow you to use the CssClass attribute on the controls so that you can style them more easily. The value of the CssClass attribute will be added to the classes for the link.

Link Controls in Layout.master file

<portal:AdminMenuLink id="lnkAdminMenu" runat="server" rel="admin"/>
<portal:FileManagerLink id="lnkFileManager" runat="server" rel="filemgr"/>
<portal:NewPageLink id="lnkNewPage" runat="server" rel="addpage" />
<portal:PageEditFeaturesLink id="lnkPageContent" runat="server" rel="pageedit"/>
<portal:PageEditSettingsLink id="lnkPageSettings" runat="server" rel="pagesettings"/>

CSS for icons

div#toolbar a[rel=admin]{
	background: transparent url('administration.png') no-repeat scroll left center;
	padding-left: 32px;
}

div#toolbar a[rel=addpage]{
	background: transparent url('newpage.png') no-repeat scroll left center;
	padding-left: 32px;}

div#toolbar a[rel=filemgr]{
	background: transparent url('filemgr.png') no-repeat scroll left center;
	padding-left: 32px;
}

div#toolbar a[rel=pageedit]{
	background: transparent url('editpage.png') no-repeat scroll left center;
	padding-left: 32px;
}

div#toolbar a[rel=pagesettings]{
	background: transparent url('pagesettings.png') no-repeat scroll left center;
	padding-left: 32px;
}

The icons are from the Crystal Project but you can use any you like.

Hiding the menu by default

Personally, I do not want the toolbar to be displayed all the time. I would rather have a link which opens the toolbar when I need it. To accomplish this, I moved the display:none; rule from the div#toolbarbut selector to the div#toolbar selector.

Conclusion

I hope this gives you a head-start on skinning the new admin toolbar. Keep in mind that all of this was accomplished easily with CSS.

Happy mojo-ing!

I started browsing around the demo site (http://demo.mojoportal.com) so I could see some of the new changes in action. The list below are just the ones I found interesting, there are a lot more changes coming in the next release.

1. A new File Manager has been added and the old one has been re-factored. The new File Manager is very nice and is a big improvement over the old one. It uses Javascript whereas the old one doesn't so Audette decided to keep the old File Manager and allow users to switch back and forth between the old and the new. Usability is very big to mojoPortal and as a matter of fact, mojoPortal can be used entirely without Javascript if one chooses to do so. There is also a new link with the Administration and Edit Page links which opens the File Manager in a graybox. This allows for easy access to the File Manager at all times.
   
2. Adding users to Roles via the Role Administration admin page is a lot easier thanks to a new selector dialog. Previously, users not in a role were listed in a single drop-down list which made it very difficult to use when a site had a lot of users.
   
3. mojoPortal uses a CSSHandler to combine & minimize CSS files. This process makes caching easier and allows sites to load faster. The url to CSSHandler has been http://somedomain.com/data/sites/[sitenumber]/skins/[skinname]/CSSHandler.ashx. This required the Data directory or at least the skin directory to be executable which is not ideal. The CSSHandler URL has been moved to the root of applicaiton in the next release. Problem solved.
4. A new SQL Query tool will allow developers to easily see and modify data in the database from the website. This tool must be enabled by a site administrator in the web.config prior to it being available for use. It will allow developers to save queries which can be used to populate date in a custom module for quick and dirty data access.
   
5. The main administration links (admin, add page, edit page, page settings) used to be just that, links. If a site designer like yours truly wanted to display the links in a drawer or some other type of cool UI, custom code would have to be developed to create the links manually. This next version will include support for controls for each link which means it will be possible to declare them directly in the layout.master and they will show/hide automatically according to internal logic. See number 6 for what this really means.
6. The jQuery Extruder plugin has been included with mojoPortal which allows for an example of using a widget with the admin links.
    
7. The blog is getting some attention this go 'round. Community feedback suggested a preview draft option, paging, option to display only blog titles in the main blog page, and a few other improvements. All of them, that I noticed anyway, made it into the core! Check out the demo, to get a better idea of what has changed with the blog.
8. The Search facility will now provide a link to download items in ShareFiles modules. Previously, just a link to the Shared Files module was provided.

Rather impressive what Joe Audette can get done in just a few weeks, isn't it?

What improvements or features are you waiting to see implemented? Why not buy Joe Audette a Coffee to show him your appreciation? 

So that's simple, right? Well, yes and no. The BreadCrumb control doesn't have the ability to add a message to the crumbs so we have to add the text in the layout.master of our skin. Okay, that's simple too but the difficulty comes with making the message invisible when the page settings have breadcrumbs turned off or there aren't any to display.

The solution is to create a User Control with all of the logic needed to display the Breadcrumb Message when needed.

The User Control

For simplicity of this article, we will create our user control in a folder named CustomControls which we placed inside the Controls folder (\Controls).

The YouAreHere.ascx file

<%@ Control Language="C#" AutoEventWireup="true" CodeFile="YouAreHere.ascx.cs"
	ClassName="YouAreHere.ascx" Inherits="Controls_YouAreHere" %>
<asp:literal ID="lblYouAreHere" Text="You Are Here:" runat="server" Visible="false" />

Not much magic here, just importing the necessary namespaces and creating our Label which will end up being the Message text. Notice the Label has the Text argument assigned and it is set to "You Are Here:". We will discuss this further later in the article.

The YouAreHere.ascx.cs file (code behind)

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

using mojoPortal.Web;
using mojoPortal.Web.UI;
using mojoPortal.Web.Framework;
using mojoPortal.Business;
using mojoPortal.Business.WebHelpers;


public partial class Controls_YouAreHere : System.Web.UI.UserControl
{
	private string sMessage;

	public string Message
	{
		get { return sMessage; }
		set { sMessage = value; }
	}

	protected void Page_Load(object sender, EventArgs e)
	{
		if (sMessage != null)
		{
			lblYouAreHere.Text = sMessage;
		}

		PageSettings currentPage = CacheHelper.GetCurrentPage();
		if (currentPage == null) { return; }
		if ((currentPage.ShowBreadcrumbs) || (currentPage.ShowChildPageBreadcrumbs))
		{
			lblYouAreHere.Visible = true;
		}
	}
}

Using the User Control (layout.Master file)

<%@ Register Src="~/Controls/CustomControls/YouAreHere.ascx" TagName="YouAreHere" TagPrefix="i7" %>

<i7:YouAreHere id="YouAreHere1" Message="How You Got Here:" runat="server" />

The first line should be placed after the <%@Register... line. It registers the User Control on the page.

The second line should be placed directly before the <portal:Breadcrumbs... line. This is the User Control Tag which will show the Message. Optionally, you can set a custom message using the Message argument.

Note: i7MEDIA assumes no liability or responsibility for the use of this code. We do however want to help you if you need it so don't hesitate to ask us.

Happy mojo-ing!

The first idea I had for using the widgets was to include a couple different contact forms on one page, each with its own tab. So I set out creating the 3 different Contact Form instances that I needed. I was doing this for my church so I had one for the Pastor, Christian Ed. Director and the Secretary. I then created an HTML Content instance on the Contact Us page and added the Tabs UI widget to the HTML content. Now this is when I ran into a problem; there isn't any way to reference a mojoPortal module from within another module, so I had no way to put the Contact Form instances inside the UI widget.

I looked throught the documentation on the mojoPortal site but couldn't find anything that I thought would lead me in the right direction so I posted a question in the forum asking for help. Joe Audette, mojoPortal's founder and chief developer, responded with a very elegant solution. All I needed to do was create a my own module that included the Tab widget with the Contact Form instances wrapped up inside. Being the great guy he is, Joe provided me with the necessary code to make this work. The process is very simple:

1. Create a text file named whateveryoulike.ascx
2. Paste this code into the text file:

   <%@ Control Language="C#" ClassName="MultiModuleInTabsModule.ascx" Inherits="mojoPortal.Web.SiteModuleControl" %>
   <%@ register assembly="AjaxControlToolkit" namespace="AjaxControlToolkit" tagprefix="portal" %>
   <%@ Import Namespace="mojoPortal.Business" %>
   <%@ Import Namespace="mojoPortal.Business.WebHelpers" %>
   <%@ Import Namespace="mojoPortal.Web.Framework" %>
   <%@ Import Namespace="mojoPortal.Web.Controls" %>
   <%@ Import Namespace="mojoPortal.Web.Editor" %>
   <%@ Import Namespace="mojoPortal.Net" %>
   
   <script runat="server">
   	protected void Page_Load(object sender, EventArgs e)
   	{
   	}
   </script>
   
   <div class="mojo-tabs">
   	<ul>
   		<li><a href="#tab1">Tab 1</a></li>
   		<li><a href="#tab2">Tab 2</a></li>
   		<li><a href="#tab3">Tab 3</a></li>
   	</ul>
   	<div id="tab1">
   		<asp:Panel ID="pnlModuleWrapper1" runat="server">
   			<portal:ModuleWrapper ID="ModuleWrapper1" runat="server" ConfigureModuleID="15" />
   		</asp:Panel>
   	</div>
   	<div id="tab2">
   		<asp:Panel ID="pnlModuleWrapper2" runat="server">
   			<portal:ModuleWrapper ID="ModuleWrapper2" runat="server" ConfigureModuleID="16" />
   		</asp:Panel>
   	</div>
   	<div id="tab3">
   		<asp:Panel ID="pnlModuleWrapper3" runat="server">   
   			<portal:ModuleWrapper ID="ModuleWrapper3" runat="server" ConfigureModuleID="17" />
   		</asp:Panel>
   	</div>
   </div>

3. Find the ModuleID for each Contact Form instance and modify the ModuleWrapper controls in the code above to match the correct ModuleIDs.
   Note: To find the correct ModuleIDs all you need to do is hover over the Edit or Settings link for the Contact Form instances and then look in your browser's status bar. The ModuleID will show as mid=SomeNumber.
4. Save the file you created in the first step to the "~\data\sites\[sitenumber]\Modules" directory. (Note: you can save the file to any directory in the mojoPortal application but I think it is best that you save it to a directory under your actual site in the Data directory because this will prevent it from being overwritten or accidentally deleted during upgrades.
5. Install your newly created module via the Administration > Advanced Tools > Feature Installation/Configuration screen inside of your mojoPortal site.
   1. This is rather straight forward. All you have to do is give your Module a name, and input the correct path in the Control Source field. You may want to create your own GUID to make sure that it is unique.
6. Now you can add your new module to any page you like just as you would add any other module to a page.

Here’s a screenshot of the end result:

Happy mojo-ing!

Joe is adding the ability to the HTML Feature of mojoPortal to display any element in a Slide Show. All the user has to do is type out their text, separating each "slide" with DIV or P elements and mojoPortal handles the rest! You can mix text with images within your SlideShow!

Here is a short video on it so you can see what I mean:

Try doing something like this with the built-in functionality of DNN!!! I can tell you now that you can't!!! This is a prime example of why mojoPortal is so far ahead of everyone else in the OpenSource .NET CMS game. One of the most important purposes of a CMS is supposed to be to allow users without a lot of web knowledge the ability to quickly and efficiently update/manage a website. This simple but very elegant feature will help those users keep their website up to date with a Web 2.0 feel.

I can't wait for the next release of mojo!!!!