This problem is caused by file system permissions. We use cache dependency files to clear the SiteMap cache (and other things that are cached), we need to be able to modify the dependency file in order to clear the cache. However if file system permissions are not correct the dependency files cannot be updated and therefore it fails to clear the cache. The dependency files are created beneath /Data/Sites/[SiteID]/systemfiles where [SiteID] is usually 1 unless you have a multi site installation. Since the entire /Data folder needs to be writable, under normal conditions there is no problem clearing the cache, but if for some reason file system permissions change, it can prevent clearing the cache. In some cases it can happen that your host moves your site from one server to another or from one drive to another and it may cause the permissions on the dependency files to be incorrect even if the folder permissions are correct. In that case you can try deleting all files from beneath /Data/Sites/[SiteID]/systemfiles. If folder permissions are correct the files will be re-created as needed. If the files don't come back on their own, that is an indication the folder permissions are not correct. The user that is the identity on the application pool is the user who needs file system permissions, this user should have full control over the /Data folder and /App_Data folder.

When the setup page runs and it creates the first site, all the skin files are copied from /Data/skins to /Data/Sites/[SiteID]/skins.

So typically it will copy them from /Data/skins to /Data/Sites/1/skins. It will only do this if the /Data/Sites/1/skins folder does not exist. Sometimes during installation it may copy some of the files but not all of them and the result will be that your site has no style. If you manually copy the /Data/skins folder to /Data/Sites/[SiteID]/skins and then touch your Web.Config file (IE download it an upload it again or type a space in it and save it) to clear the server cache and then also clear your browser cache it will fix the problem. Typically, SiteID will be 1 in a single site installation.

The reason we don't include the font face, font-size, and text color/background color toolbar items in the editors is because it is contrary to the notion of having a skinnable site. If you use those toolbar items you are hard coding fonts, sizes and colors into your content making them un-skinnable. You may pick fonts and colors that look good with your current skin but a year from now when you decide to re-design the look of the site those fonts and colors you hard coded into the content using these toolbars may look ugly and now you have a big job to do to clean that up to make it look right with your new skin design. So, its a bad practice to use those toolbar items that hard code any kind of style into your content. It is much wiser to use only CSS classes and let the fonts and colors be decided in the CSS files. If you do want to customize the toolbars and put those font toolbar items back in, you can do it, see this article: Customizing the Editor Toolbars, but I think later you will regret it. We removed these items to make it more difficult for you to follow bad practices.

If you delete a site there is no way to get it back unless you have a database backup and can restore the whole database. To prevent accidental deletion of sites we have hidden the delete button by default. You can enable it by setting this to true in Web.config or user.config:

<add key="AllowDeletingChildSites" value="true" />

Note that sites can only be deleted from the root site and the root site itself cannot be deleted. After you delete a site I recommend you disable the button again to avoid accidental deletion.

This error happens when there are wildcard mappings for handlers in IIS. The most common cause is when ColdFusion is installed on the same server with ASP.NET, ColdFusion creates these wildcard mappings that break the mappings for some things that should be handled by ASP.NET. See this Microsoft Knowledge Base Article for details solutions, and workarounds.

The first step is to find out what the error is. See the article about Basic Troubleshooting to learn how to find the error details.

If you have trouble resolving the issue on your own, you can post your questions in the Site Administration forum to get help from the community.

If the problem is beyond what you can handle, we at i7MEDIA offer a Paid Support plan and can help you with any errors your site might have.

Removal of the "Powered by mojoPortal" link is allowed, and there are no requirements for its removal.

However, leaving the link on your site would be greatly appreciated, as it helps spread the word about mojoPortal.