Organizing the mojoPortal Community

The mojoPortal community has been gradually growing along with the evolution of the project since late 2004. We have had quite a few contributors over the years such as Dean Brettle, who implemented NeatUpload, Joseph Hill, who implemented the initial version of Feed Manager (later improved by Walter Ferrari) as well as the initial data layers for PostgreSql and Sqlite, Rob Henry, who implemented the Survey, Christian Fredh, who implemented the Poll, and Kevin Needham who implemented the content workflow, and many others who contributed various little improvements over the years. You can find a list of contributors on our developer page for more detail. All the contributions and involvement have been pretty organic, we have never really organized project teams or a holistic strategy to grow and support the community. mojoPortal is now the 3rd most popular CMS on the ASP.NET stack and we are reaching a critical mass of popularity that I think requires us to get a little more organized. We are beginning to see more people helping out in the forums and more and more people are offering to help with development, but it is challenging for me to manage the community all by myself.

Today I would like to announce that Joe Davis will be stepping up to take on new responsibilities in the project as Community Manager. Joe has been a huge help to myself and the community already in the forums. He has helped a lot of people with skinning questions, installation and configuration questions, and lots of implementation tips and tricks to help others achieve their goals with mojoPortal. Joe mentioned to me a long time ago that one of the things that drew him toward mojoPortal was the friendly forums, we don't make people feel stupid for asking questions, there are no stupid questions. This is not to say that every question gets answered, most of them do but not all of them. Sometimes people ask questions for which we don't know the answer, or there isn't a good answer that comes to mind, or the amount of time required to answer it would be too much effort, or what I playfully would describe as "Wizard of Oz" questions. But by and large if people ask reasonable well articulated questions and we are able to help we do help. In his participation in the forums, Joe Davis has been exemplary in putting a friendly face on our forums and making people feel welcome. I mean just look at his mug shot, if you lookup "nice guy" in the dictionary there should be a mug shot of Joe Davis!

Joe Davis i7MEDIA

As Community Manager, Joe Davis will be able to help with forum moderation and logistics of managing the community, and he will collaborate with me on strategy to promote community engagement and how best to organize teams and contribution guidelines to facilitate development help offered by the community. As such we are in the beginning stages of working on the strategy and will be communicating more about that as our ideas begin to take shape. For now I just want to thank and congratulate Joe for stepping up to take on this role as a Core Team member and Community Manager.

Joe's company i7MEDIA provides high quality mojoPortal hosting and design services.

I also want to officially welcome Katherine Moss, who has joined our team as an Accessibility Advisor. Katherine will be instrumental in helping us keep mojoPortal accessible for users who use assistive technology such as screen readers. She will be helping with testing and feedback of various mojoPortal features in terms of their accessibility.

 

Follow us on twitter or become a fan on Facebook

follow us on twitter become a fan on facebook

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.

The Miraculous Resurrection of Novell Forge svn and the Recovery of Source Code History

If you read this blog on a regular basis you may recall that back on May 12 I blogged Caught Off Guard Novell Forge svn is Gone!

I had missed the email and had not known that Novell Forge was going away as of March 2010. So as it was, the Novell Forge svn server had already been running way past the deadline when I found it was down on May 11 and 12. That morning I googled and found the notice about it. So we quickly moved to Codeplex with a new Mercurial repository which I have since found to be a joy to use. Ultimately I felt the whole situation had been a blessing in disguise because I like Mecurial so much better than Subversion.

Then a few weeks later on June 6, a surprising thing happened, there was a post in the forums where a user said he just got the latest version of the code from svn. As it turned out, the svn repository at Novell Forge was back online!

So the next morning I did some research and found this post and this linked post about how to get svn history into Mercurial. It seemed pretty straightforward so I kicked the process off wondering if it would really work given we have history in the svn repository going back to 2005. The process started working, it scanned the repository and started counting down from 6000 plus change sets that I guess it was converting to Mercurial change sets. So that was the morning of June 7, 2010 and it finally finished running this morning sometime before I got up. Today is June 28 so it ran for about 21 days. The conversion process was surprisingly robust in that a few nights (including the screen shot below where it was getting close to finishing) it would lose its connection with the server and stop running, but I would kick it off again and it would scan and then pick up where it left off. The process was killed one night because my computer went into hibernate mode an would not wake up without powering it off, and another night a forced reboot by windows update killed it, but every time it managed to work again and pick up where it left off.

hg convert screen shot

So now I have the ability to browse change history going back to the beginning of our svn repository using TortoiseHG with a Mercurial repository on my local machine.

TortoiseHG repository browser

I'm kind of glad we started with just the latest code in a clean repository at Codeplex because this much history takes up a lot of space on disk, but now it is nice that I will be able to have an archive the source code history on CD ROM.

I have to say that I am pleasantly amazed with Mercurial and TortoiseHG!

Anyway, thought I would share the happy ending!

 

Follow us on twitter or become a fan on Facebook

follow us on twitter become a fan on facebook

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.

mojoPortal 2.3.4.5 Released

I'm happy to announce the release of mojoPortal 2.3.4.5, available now from our download page.

What's New

  • New Bing Map Feature
  • New alternate site search features allow you to use Bing or Google for site search in addition to or instead of the internal Lucene search engine
  • Upgraded to the latest version of AjaxControlToolkit
  • Upgraded from TinyMCE .3.6 to 3.3.7
  • Upgraded from CKeditor 3.3 to 3.3.1
  • Added a required checkbox if a registration agreement is used
  • Updated Italian resources from Diego Mora
  • Fixed a bug introduced in version 2.3.4.4 where if you were using excerpts in the blog, the read more link was malformed
  • Fixed a bug introduced in version 2.3.4.4 where the FeedManager page size setting was ignored
  • Fixed some more places where we had not implemented the new TimeZone system and the old hard coded offsets were still being used
  • Fixed a bug where the google 404 enhancement gives a script error in IE, it is now disabled in IE
  • Fixed a bug in the pgsql data layer for the blog that caused an error on viewing blog categories
  • Other minor enhancements and fixes for things reported or requested in the forums since the last release

Bing Map Screen shot

There were also a few additions to CSS in included skins that you will need to add to custom skins, see this sticky thread for details.

Upgrades for Add On Products

Because of the upgrade to the latest version of AjaxControlToolkit, there are also corresponding compatibility updates for Event Calendar Pro and Form Wizard Pro because they must use the same version of AjaxControlToolkit as mojoPortal. Existing customers can download the updates from their purchase history. We have officially changed our upgrade policy, originally the policy was free upgrades for 1 year after purchasing our add on products, but now our policy is free upgrades for the life of the product and this is retro active to all existing customers. If you've never purchased our add on products now is a good time to consider adding them to your site, visit the store to learn more about our add on products for mojoPortal

Online User Group Meeting

Don't forget to sign up for our free online user group meeting coming up this Wednesday June 23, 2010 8 PM Eastern Daylight Time on Yamisee.

mojoportal user group ad

Follow us on twitter or become a fan on Facebook

follow us on twitter become a fan on facebook

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.

mojoPortal 2.3.4.4 Released

I'm happy to announce the release of mojoPortal 2.3.4.4, available now on our download page.

What's New?

  • This is the first release where we have separate release packages for .NET 3.5 and .NET 4.0.
  • New Facebook like button available in the Blog and in the HTML feature. This makes it easy for people to "Like" pages on your site on Facebook.
  • Upgrade from TinyMCE 3.2.7 to 3.3.6
  • Upgrade from CKeditor 3.2.1 to 3.3
  • Upgrade to the latest version of NeatUpload
  • We removed 7 skins from the main release packages to reduce the file size of the main packages and made them available in a separate download extra-skins.zip. Don't worry there are still a lot of skins included in the main packages.
  • Various bug fixes and enhancements for things reported or requested in the forums.

There are also corresponding releases of Form Wizard Pro and Event Calendar Pro. Users who have purchased these add-on products should upgrade them at the same time or right after upgrading mojoPortal.

Form Wizard Pro 0.0.1.7

  • compatibility updates for mojoPortal 2.3.4.4
  • includes a build for both .NET 3.5 and .NET 4.0
  • fixed bug where an incorrect redirect would happen after importing a form definition if the site was running in a virtual directory instead of a root site
  • added option to use regular expression validation of date questions
  • added a setting for a custom CSS class so forms can be styled differently

Event Calendar Pro 0.0.2.8

  • compatibility update for mojoPortal 2.3.4.4
  • includes a build for .NET 3.5 and .NET 4.0

Follow us on twitter or become a fan on Facebook

follow us on twitter become a fan on facebook

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.

The .NET 4 Transition Plan for mojoPortal

This post will outline the transition plan for moving forward with .NET 4.0 in mojoPortal while still maintaining support for .NET 3.5 and how this plan will impact developers working with the mojoPortal source code.

Beginning with the coming release, we will be making a separate set of compiled deployment packages for .NET 3.5 and for .NET 4.  For those who are not working with the mojoPortal source code, you don't need to read the rest of the post, the only part you really need to know is that when you upgrade to the next and future versions of mojoPortal you need to choose the correct download package for your hosting environment. If you are hosted in 3.5 .NET you will need to choose the appropriate package for 3.5 and if you are hosted in .NET 4 you will want the package for .NET 4.

Transition Duration

We will continue to produce deployment packages for .NET 3.5 for at least the next year and possibly longer depending on community feedback.

What Changes Will Be Required?

The target framework is a project level setting, so we will be changing the 3 web UI projects (mojoPortal.Web.csproj, mojoPortal.Features.UI.csproj, and WebStore.UI.csproj) to have a target of .NET 4. To the extent possible we will try to keep the target for all other supporting projects as 3.5 during the transition period.

To make it possible to be able to produce a build for 3.5 .NET I have made copies of the above project files and named them as mojoPortal.Web.net35.csproj, mojoPortal.Features.UI.net35.csproj, and WebStore.UI.net35.csproj and I have set them up in a separate set of solution files.  

mojoportal.net35.sln is the complete solution configured for .NET 3.5.
mojoportal.core.net35.sln is just the core without all the features like blog, forums and WebStore etc.
mojoportal.mssqlonly.net35.sln is the full set of features but leaving out the data projects for alternate databases.

The main solutions which will be used for .NET 4 development have the same name except for the .net35 segment.

The new projects for .NET 3.5 are already available in the repository, but I have not yet changed the target on the main projects to 4.0, this will probably be done tomorrow. I did a test conversion on a copy already to make sure I will have no problems with the conversion.

We also have mojoportal.mono.sln which is for use in MonoDevelop on Linux.

screen shot of target framework setting

 

How Will This Impact Developers?

For some developers this will be great because they are wanting to use .NET 4 and the main solution and project files will be setup for .NET 4 development.

Developers who need to continue working with .NET 3.5 for their own custom features will need to remove the 4.0 version projects and add the new net35 projects in their custom solution files and then may need to re-create project references to the new projects since references may be lost when the projects are removed.

There will also be one other inconvenience for those who need to stay on .NET 3.5 development. When we convert the main Web project to .NET 4 it will change the Web.config file to be compatible with .NET 4 and it will no longer be compatible with .NET 3.5. I have created an alternate Web.net35.config file, so you will have to copy the contents of that file into the Web.config file after getting the code. To avoid merge conflicts when getting code updates from the Mercurial repository, you may also need to revert the Web.config file before getting updates from the repository and then change it back again afterwards. 

Since the 4.0 and 3.5 versions of the projects will share the same files, I have added a conditional compilation symbol NET35 on the 3.5 versions of the projects. So in code that uses new properties or methods available only in .NET 4 we will have to wrap the code with checks for the conditional symbol like this:

#if !NET35

// some .NET 4 specific code

#else

//some alternate .NET 3.5 code if needed

#endif

screen shot of conditional compilation symbols

This way when we compile the 3.5 versions it will leave out the 4.0 only stuff.

Of course this means that whenever I add a new file to one of the 4.0 projects I have to remember to also add the file in the 3.5 version of the project, so there will be some extra tedium for me also during this transition period. Once the transition period is over and we feel it is safe to drop support for .NET 3.5, then we will remove the extra project and solution files and we will then be able to change the target on all the projects in the solution to .NET 4. There may be a few bumps along the way in a transition such as this, it is similar to what we went through in the transition from 1.1 .NET to 2.0 back around 2005.

So that is the go forward plan that will allow us to begin using some .NET 4 features while maintaining the ability to produce builds for 3.5 .NET for at least the next year. If anyone has any concerns or opinions or other feedback about this plan, please post in the comments. The main projects will be converted to .NET 4 possibly as soon as tomorrow. If that worriess you, you might want to go ahead and get a fresh update from the repository today.

UPDATE 2010-05-24: I've completed the conversion of the main projects to 4.0 .NET in the repository and verified that it is still very easy to make a build for 3.5 .NET.

www.mojoportal.com has been running on .NET 4 for several days now and all seems well. I did encounter a few little menu rendering issues at first but was able to solve them in code (already updated in the repository). So far the only significant issue I've found is that under .NET 4 Medium Trust configuration we get errors on any page that has NeatUpload on it. I've passed the information about the error on to Dean Brettle, the developer of NeatUpload so hopefully it can be resolved soon. In the mean time I would not recommend using mojoPortal under .NET 4 with medium trust. It does works fine in Full Trust and hopefully the Medium Trust issue can be solved in the near future.

UPDATE 2010-05-25: Thanks to assistance from Dean Brettle, the latest version of mojoPortal in the repository now works with no errors under .NET 4 Medium Trust.

 

Follow us on twitter or become a fan on Facebook

follow us on twitter become a fan on facebook

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.