Hi,

Sorry but the volume of forum posts is too much for me to answer every question, especially long lists of open ended questions. Not to mention today is Thanksgiving and I should be relaxing not answering forum posts.

1. You should not modify any mojoPortal code or mojoPortal tables. As soon as you do that you have created a fork and will have a hard time ever upgrading without losing your changes. All your custom code should be in your own projects and if you need custom tables you should create your own. You should read the developer documentation and you should study how existing features work to learn how to build your own features that can plug in. If you build a feature that plugs in you do not need to do anything to use the built in authentication since users will sign into the mojoportal site.

2. We do not have built in support for different kinds of users registering, though you can add custom profile properties and make them require for registration. You can create custom Register page in a separate project to do whatever you like and use a post build event to copy it up to replace the built in version, but then you will need to maintain it and always produce your own build to package mojoPortal with your custom features included.

3. Custom HttpModules can be plugged into the pipeline via the Web.config whether they affect page content or cause problems depends what they do. You should not plug in any httpmodules unless you understand exactly what they do and how they affect things.

4. Only CMS page are in the menu. Generally you implement a feature as a UserControl that can plug into a CMS page and this serves as the entry point to your application. From there you can link to any supporting pages of your feature and pass in the pageid and module id to keep the menu highlighted on the current page and to take advantage of built in methods of our base page for enforcing page and module level security. Though it is also possible to create a CMS page in the menu that really is just a pointer to your custom page by putting in the full url of your custom page as the url for the CMS page, but this is not really the recommended approach, it can be used.

5. MyPage is what it is, if you don't like it don't use it. I built it back when 2.0 .NET came out (around 2005) and WebParts seemed very interesting new feature at the time but less so now. I thought there would evolve an ecosystem of re-usable webparts for asp.net like Sharepoint webparts has but that never happened, it never really caught on and I don't know of any third party WebParts other than ones for Sharepoint. Whether something is easy to develop depends on the complexity and the skills of the developer.  mojoPortal is not meant to be all things to all people. It is meant to make it easy to have a web site for running a business and to be extendable but it is not meant to be a foundation of the next Facebook or MySpace.

Hope it helps,

Joe

I really wanted to make a fork of mojoPortal, and it was not much important to be able to upgrade to new versions, because current basis of mojo is more than enough for the application. (and really wanted help on what code and db tables should be changed for new features.)

This is a bad idea, I strongly recommend against it. Something will eventually come up where there is a security fix, a bug fix, or a new feature that you need. It is a bad assumption that you will never want or need to upgrade. Forking means you will have to maintain your fork and fix any bugs yourself. If you are building this app for someone else you do them a dis-service with this assumption, if you build it for yourself, I still think it is not a good assumption and you will later regret it.

Best,

Joe

I recommend find strategies to keep your code separate and not modify existing tables. If you need to customize an existing content feature, clone it first to make your fork of the feature rather than a fork of the whole system and then at least it is independent from the included feature. For things like custom registration and login pages you could keep your version in separate projects and use post build events to replace the existing version with your own rather than put your own right in the mojoPortal code projects. Custom httpModules can be compiled into your own dlls and registered via Web.config.

Ultimately it is your decision, if you fork it you will have to live with your decision not me. All I ask is don't come around posting about bugs in your forked version and expect me to offer any support.

I do not think it will be trivial to backport bug fixes and new features from mojoPortal into your forked version. I've been developing and maintaining mojoPortal for over 5 years, are you going to maintain your fork for the next 5 years or more? If you are really comfortable with that idea then go for it.

Hope it helps,

Joe