Database Configuration

If you have questions about using mojoPortal, you can post them here.

You may want to first review our site administration documentation to see if your question is answered there.

This thread is closed to new posts. You must sign in to post in the forums.
4/16/2013 8:32:06 AM
Gravatar
Total Posts 30

Database Configuration

I am having an odd problem so let me start by explaining my environment

I have Mojo installed on a development IIS server.

The goal is to get the site completely tested here and then move it to our production server

The migration plan is to move the files c:\inetpub\wwwroot\cadrms and the SQL databse to the production server

Mojo is installed in c:\inetpub\wwwroot\cadrms on server 10.0.1.34

We initially added the website to IIS as Mojo and then subsequently created a website called CADRMS

I noticed that when I make a change through Administration in Mojo it was not reflected in CADRMS until the following day

I want to know if there is any concern with having the website have a different name in IIS in production?

Also, is there some setting that can be managed so this synchronizes faster?

 

4/16/2013 9:55:19 AM
Gravatar
Total Posts 18439

Re: Database Configuration

If you have 2 sites using the same database, the problem will be that when one site updates data it can clear its own cache but it cannot clear the cache for the other site. ie when a new page is created the site map chace has to be cleared for the new page to show up in the menu. Also if you use more than one site with the same db the search index will not stay up to date correctly in both sites. Best to use just one site.

Generally I don't recommend migrating sites around, mojoPortal is not designed for that kind of scenario where content is created on one server and then pushed to another server. A one time migration is ok but I would not do that on a regular basis. You should see the article Moving an Installation of mojoPortal To a Different Server.

Generally I recommend use page view roles to hide content until you are ready to make it public and for HTML content feature you can use content workflow for updating existing content in a way that public users don't see the edits until it is approved. When a page is protected by view roles, only users in the role will see the pages in the menu and be able to view the pages, the menu will be filtered out for users not in the allowed view roles.

When launching a new site the site can be marked as closed and then no users except admins and content admins roles will be able to see any of the site content, so even new sites are easier to just install where they are going to be instead of having to go through the migration process.

Hope that helps,

Joe

You must sign in to post in the forums. This thread is closed to new posts.