Site Membership Pro - Coming Soon!

In our last newsletter I mentioned that I was working on a new add on product for mojoPortal named Site Membership Pro.

I've received quite a few emails expressing interest in this product and I'm happy to report that the first release is ready to ship and will be available soon in the mojoPortal store.

Site Membership Pro

However, Site Membership Pro depends on a few small changes I've recently implemented in the core of mojoPortal, so I'll have to wait until after the next release of mojoPortal before I can make it available. My plan is to make a new release of mojoPortal soon, I'm going through our project tracker looking for small things I can complete to round out a new release to make it worthwhile upgrade.

In the mean time, I've created a demo site to show the public facing side of the feature at smpdemo.mojoportal.com.  You can also try out the back end administration of the feature on our main demo site where you can login as the administrator, but you'll need to add it to a page manually and then you will see the "Settings" and "Manage" links.

What Is Site Membership Pro?

Site Membership Pro provides additional functionality on top of mojoPortal to make it easy to monetize access to your premium site content.

mojoPortal already provides role based security so that you can use roles to protect your premium content. For example you could create a role named "Members Only" and you could set that role as the only allowed View Role on pages in your site that contain premium content. However, managing the roles assigned to a user is a manual process in mojoPortal that can be done by Administrators, Role Adminsitrators or Roles That Can Manage Users. So one would have to go to each user who should be given access to premium content and add the user to the "Members Only" role.

Site Membership Pro provides the missing pieces to make it easy to sell membership subscriptions and automatically grant the user the role or roles that provide access to the premium content on your site when they complete a subscription purchase.

You define Membsership Levels which have a name and one or more roles that are provided with this level of membership. You could keep it simple and just have one level for "Members Only", or you could have multiple tiers of access like Gold, Silver and Bronze each providing different roles that protect sections of your site content.

Then you define Membership Product(s) which grant the user one of the Membership Levels (and the associated roles) for a specified number of days for a specified price. Products can be enabled or disabled and they can have begin and end dates that determine when they are on sale. A grace period can also be specified on the product such that users are not removed from the granted role(s) until after a certain number days after the actual expiration date.

When a user pruchases a membership product they are immediately granted the roles provided by the membership level when the payment has cleared. The begin and end dates of the membership are set at the time of purchase and a background task handles removing roles from the user when the membership expires or the grace period is over (if the user has not renewed).

You can also configure notifications on the products so that users can recieve reminders when their membership is coming up for renewal. Reminders can be configured as a specific number of days before or after either the end date of a membership or the end of the grace period. You can create multiple reminders per product so that you have a series of them to encourage renewal.

You can also define reminder templates for plain text email messages. Templates support some token replacement and you must assign a template to a reminder in order to save it. So the reminder will send a plain text email replacing the tokens from the template at the scheduled time if the user has not renewed.

The same background task that manages removing users from roles if their membership expires also handles sending the reminder messages.

Note that the reminders are intended to provide a link back to your site so the user can renew his membership before it expires. To renew, users have to go through the checkout process. Site Membership Pro does not retain any credit card information and does not automatically charge cards to renew subscriptions. Possibly in the future we will look into available APIs from PayPal and others for recurring payments but we have no plans to retain credit card information in the future. The risks and liability potential involved with retaining credit card information without proper infrastructure and staff to secure the data far outweigh the fact that it would be nice to be able to do that.

Since users probably don't want to go through the checkout process every month it is recommended to structure your membership products with fairly long durations like 6 months or one year as opposed to a month at a time. Free products are also supported so you could have one product that provides a free trial of Premium Access for a limited number of days and a One Year Subscription for $120 for example. You can also mark a product as available only for new members, so that existing members can't get the free trial offer.

Supports Authorize.NET, PlugNPay, PayPal, Google Checkout - ie the same payment systems supported in all mojoPortal ecommerce products (WebStore, Event Calendar Pro, Web Invoice Pro). I'm also investigating adding support for WorldPay for all our ecommerce products in the near future.

The initial release will support MS SQL and MySql, other database platforms may be supported later depending ion demand.

What Site Membership Pro Does Not Do

Site Membership Pro is NOT a replacement for the site registration system. User's must register or sign in to purchase premium membership, so they need to go through the normal registration process first to get a free account, then once they complete the membership purchase they are immediately granted the roles provided by the membership.

Site Membership Pro is not involved in protecting your premiumm content, that is done by configuring roles that can view pages in your site and is built in functionality of mojoPortal.

Site Membership Pro does not retain any credit card information and cannot automatically charge cards when membership renewal is due.

Site Membership Pro does not prevent an Administrator, Role Administrator or Roles That Can Manage Users from adding or removing users from roles.

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.

Event Calendar Pro 3.4.0.5 Released

I've just uploaded Event Calendar Pro 3.4.0.5 This is a minor upgrade with just a few little improvements that some customers have been asking for.

What's New?

Improvements to the event editor to get rid of some jumpiness that could happen when additional settings were shown or hidden based on checkbox selection. Previously this was done using UpdatePanel which was the cuase of the jumpiness. All UpdatePanels have been removed from the event editor page and the showing and hiding of things is done with jQuery making it much smoother.

Added settings to allow not requiring or showing address and phone fields on the registration form when the event is free.

Added a setting to use the Event Summary instead of Event Detail in the outbound feed. Often people consume the feed in the mojoPortal Feed Manager on their home page to show upcoming events but they don't want to show the full details.

Added a setting to control how far into the future events are included in the feed. Previously it was hard coded to 180 days, this is now just a default setting that can be changed.

Added more css classes on the body element in edit/admin pages

Added config settings to allow hiding the start and end time on List View and event Detail view if the start and end time is configured to the same value.

Updated the article Event Calendar Pro Tips and Tricks to cover some of the new and previously undocumented config settings.

Event Calendar Pro

We've got lots of plans for future enhancements for Event Calendar Pro, but wanted to get this small update out for the folks who requested these minor improvements. As with the previous release of Event Calendar Pro, this release requires mojoPortal 2.3.8.1 or higher.

This is a free upgrade for existing customers who have already purchased Event Calendar Pro. To download the new version just sign into www.mojoportal.com as the user who made the purchase, then click the "My Account" link at the top of the page and go to Order History. You'll be able to download the latest version from your order details.

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.

Using the Blogsy iPad App With mojoPortal

It seems like developing applications for the iPad is all the rage these days as it has become a very popular device.  I’ve thought about developing an iPad app for mojoPortal, it would be fun to learn how to develop apps for iPad and iPhone, but honestly my plate is pretty full just working on mojoPortal itself and add on products for it. So I got to wondering if there were any apps already in existence for the iPad that could work with mojoPortal similar to Windows Live Writer which is the best Windows desktop application for blogging. In case you missed it, in version 2.3.7.5 we improved our support for Windows Live Writer so that you can now edit CMS pages with Html content in addition to Blog posts. I thought it would be pretty cool if there is an iPad application that offers similar functionality as Windows Live Writer.

So I tried a few iPad applications including the WordPress app, BlogPress, and Blogsy. I found Blogsy to be the most feature rich user friendly one of the group. All of these apps support Wordpress and some of them support a few additional blogging platforms and since mojoPortal is much less known than the big blogging platforms I would not expect the developers of those apps to be interested in working on specific support for mojoPortal. So instead I decided to try to support more of the Wordpress API in mojoPortal so that these apps could be used with mojoPortal just as if they were using  Wordpress. I used all 3 of these apps in testing to make sure I was correctly implementing the Wordpress methods, but Blogsy is by far the best one that I could recommend to mojoPortal users who would like to blog from their iPad.

IMG_0012

In Blogsy you configure mojoPortal the same as if it were a self hosted Wordpress site. So you enter the url to your Blog page (use https if you have SSL installed) and your login credentials.

Now Wordpress of course is a PHP application (not a .NET app) and the Url for the API is yoursiteroot/xmlrpc.php (you don't enter this url in Blogsy but that is the url it will use to talk to mojoPortal) so we have a handler mapping in our Web.config file that maps requests for xmlrpc.php to our metaweblogapi.ashx handler. This probably only works in IIS 7.x and it may not work if you have PHP installed and configured for your site, but it does work for me.  I don’t have PHP installed so not sure what would happen if it is, but in most hosting control panels you can disable PHP for your site even if it is installed on the server, so hopefully it will work for you.

<add name="WordpressXmlRpcHandler" verb="POST" path="*xmlrpc.php" type="mojoPortal.Web.BlogUI.metaweblogapi, mojoPortal.Features.UI" preCondition="integratedMode"/>

When I first began work on the additional API methods and testing with Blogsy I was getting a lot of crashes. Adding an image from the iPad photostream for example was causing a crash after it uploaded the image to the server. But I contacted the Blogsy guys and they both helped me with advice that the images needed to be named a certain way with a prefix, and they also fixed things in their app to make it more robust and reduce the crashing and now it is working pretty well. I have a first generation iPad and suspect these apps work even better with newer iPads that have more memory available, but it works well enough even on my older iPad.

IMG_0009
You can create and edit posts, you can publish or post as draft. It supports inserting images from your Photostream, local storage, Fickr, Picasso, and even videos from YouTube. You can assign and edit categories. You can create and edit CMS pages with Html content in addition to Blog posts. The only missing feature is the ability to set the parent page of a CMS page so you can’t manage the site hierarchy the same as you can with Windows Live Writer, but who knows if enough people request it maybe they will add support for parent pages in a future update to Blogsy.

The additional support for the Wordpress API is included in mojoPortal 2.3.8.1 but I’m just now getting around to documenting it so that people know they can try it. If you have an iPad I hope you’ll give it a try. If you have any troubles with it or any feedback positive or negative let us know. In theory it should work with any Wordpress client. While Windows Live Writer is still the best Windows app for blogging, in the Mac world apps like MarsEdit should theoretically work though I haven’t actually tested it yet.

A quick shout of thanks out to the Blogsy guys for their help and support. I highly recommend you give their app a try if you have an iPad. Its very inexpensive ($5 if I recall correctly), I actually think they could get away with raising the price a bit because it is the best blogging tool currently available on iPad and they are very passionate about it and constantly improving it and listening to the feedback from their customers.

See also:

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 Sightings for February 2012

Our first site for this month's mojoPortal Sightings is Collins Language Pioneers in Dictionary Publishing Since 1819. Thanks to Vijay Karla for letting us know about this one.

Collins Language

 Our good friends at DM2 Creative Marketing Communications also submitted a nice site for Umbrella Collection.

Umbrella Collection

We also received a nice testimonial from the California Commission on Peace Officer Standards and Training. We featured their site in a blog post back in December 2010, when they first launched their site on mojoPortal. Recently they took their site mobile using our add on product Mobile Kit Pro.

California POST Mobile version

My name is Mike, I'm the web applications developer at the Commission on Peace Officer Standards and Training (POST for short). We've been using MojoPortal at POST for over a year now. We recently bought and implemented a mobile site using your Mobile Kit Pro. Prior to this I had hand coded a JqueryMobile/HTML version of our mobile site with a small subset of the pages available on the full site. With MobileKitPro we now allow our users to access all the pages available on the main site on mobile devices. Over the past year and a half we have created custom modules for MojoPortal, I was very impressed that most of these modules worked with the new mobile site without much tweaking.

Thanks so much for your hard work on MobileKitPro.

You're welcome to come check out our site on your Android/iPhone at http://post.ca.gov

-Mike

We've had similar feedback from quite a few customers using Mobile Kit Pro, it really does make it very easy to deliver a good experience for iPhone, Android Phone, and Windows 7 Phone. Although we don't offically support Blackberry mainly because we don't have a device to test with, Mike also told us it is working well for their Blackberry users.

We'd love to hear about the sites you are bringing online with mojoPortal. If you have a high profile site or a design that you're particularly proud of, or a site showing custom features you've built on mojoPortal, let us know, maybe we'll feature your site(s) in a blog post.

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.8.1 Released

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

What’s New?

Security Updates

Stronger password hashing for hashed password format. Previously we were using MD5 without salt, but now we use sha512 with a random 128 character salt per user. Existing users will be automatically updated to the stronger hash the next time they login.

For encrypted passwords we’ve also updated to use a 128 character random salt per user. Existing users will be updated with a salt the next time they login.

In version 2.3.7.6 we changed the SSL behavior to keep users in a secure session once they sign in. After the release we noticed that the canonical url was using https for secure requests and http for insecure requests which could affect SEO since the canonical url should not vary. We’ve changed it in this release such that if the page does not require SSL and the site does not require SSL for all pages, then the canonical url will use http, otherwise it will use https. This way it will be consistent and not vary to make sure there is no inconsistency if search engines happen to crawl the pages using https.

When a user’s roles are changed, the role cookie will now be updated automatically on the next authenticated page request. Previously, if you added a user to a role or removed him from a role he needed to logout and login again to get the new role cookie.

Usability Improvements

We’ve made the role permissions more clear on Page Settings and Feature Instance Settings. There has been some confusion in the past about a special case of permissions. By default Administrators and Content Administrators can access and edit any content without adding them to the allowed roles, but we had a special case where if you set the allowed roles to only Administrators then the content could be locked down to only Administrators and Content Administrators would no longer have access. In the past this has not been an obvious feature from the UI and users who did not know about that feature would mistakenly check the box for Administrators, accidently locking out Content Administrators. We’ve now made it more clear in the UI with radio buttons above the role lists for Page and Content View and Edit Permissions like this:

page-permissions

Note that if you want to lock some content down so that only Administrators can access it, you should set both the page view/edit permissions and the feature instance view/edit permissions to Only Administrators. Otherwise if you only secure the page, Content Administrators can still access the content instance from Content Manager outside the context of the page security.

A related change is that now if you have more than 20 roles, by default we use separate pages for page and feature instance permissions, and the site level permissions have been moved out of the Site Settings page into their own pages. This was done because of a change in behavior in ASP.NET after a recent security update. Now if a page is using postback with more than 1000 form elements, it causes an error, and we moved these things to reduce the number of form elements on a page because if you have a lot of roles the checkboxes for each role for each permission adds up to a lot of form elements and combined with other form elements on the site settings page and hidden elements used for viewstate some users were getting errors when they would save site settings due to too many form elements. There is a workaround to allow more form elements but we wanted to make it work without doing that so it seemed like a better idea to reduce the number of form elements by not having as many things all on one page. We also did some viewstate optimization to reduce un-needed viewstate in some features.

We also added paging to the /Admin/SecurityRoles.aspx page which shows the users for a given role, and we made the feature instance settings page use the same skin as the page when using page specific skins.

Blog Improvements

The blog now shows the post categories for a post in the post list and in the post detail. We’ve also implemented more of the Wordpress API, so in addition to being able to use Windows Live Writer, it is also now possible to use Wordpress clients such as the Blogsy app for iPad. I’ll be documenting that soon but basically you configure it as if you were using Wordpress.

Html Content Improvements

Several people have reported problems when trying to use javascript in the Html Content Feature, the WYSIWYG editors such as CKeditor and TinyMCE tend to do some “cleanup” on the markup which sometimes removed things that people intended to be there. In CKeditor for example you could get around it by saving while still in Html view, but the next time you opened the content in the editor it would run the “cleanup” and mess up your javascript. For content instances where you are using javascript and just want to edit the raw html without interferance from the WYSIWYG editor, you can go into the settings and un-check the box for “Use WYSIWYG Editor?”, and then it will just use a plain text area when you go to edit that content instance.

Most Additional Language Resource Files are Now In a Separate Download

As the number of translations and partial translations of resource files has grown over time, it has added to the size of the download, but more importantly it has increased the amount of time it takes for the ASP.NET compiler to compile the files for the initial request when a site is first started up, or the application pool is recycled such as when deploying an upgrade. Each of those .resx files is compiled by the ASP.NET compiler and over time as we have got so many of them it has become too much and it adds significant time to the initial site startup. So we now have a separate languagepack.zip that has the additional languages. You can copy the language resource files you need from there into your /App_GlobalResources folder. For those upgrading, you may already have a lot of existing resource files in that folder that you don’t need. My advice would be to delete the languages you are not supporting in your site from the /App_GlobalResources folder just before upgrading. Do not delete the English resource files though because those are needed for fallback when other languages have missing keys. The English files are named without a language code like Resource.resx and BlogResources.resx whereas other languages have a language code like Resource.ru.resx and BlogResources.ru.resx for Russian. The main package now only contains the resource files for English and Italian and the other languages are all in the languagepack.zip

WebStore Improvements

The way payment gateways was plugged in in the past for card processing gateways like Authorize.NET and PlugNPay was kind of a mess, it is now a true provider model so that new gateways can be implemented in separate assemblies (dlls) and plugged in by configuration, so it should be easier now to implement new gateways. I’ll be documenting this soon. It doesn’t affect PayPal or Google Checkout because those are special cases where we don’t process the credit card payment on our own site, it happens at the PayPal or Google Checkout site and those payment gateways can be used in addition to a standard card processing gateway where the user doesn’t leave your site to complete the transaction. The new provider model is only for standard card processing gateways.

There was also some redundancy with the old way we implemented Authorize.NET and PlugNPay, they each had their own separate log for logging transactions which was redundant and would have only become worse if we kept adding new logs for each new payment gateway, so we now have a consolidated payment log used by all standard card processing gateways (ie ones that implement IPaymentGateway provider). The upgrade script will migrate existing data form the old Authorize.NET and PlugNPay Logs. Since our add on features Web Invoice Pro and Event Calendar Pro also use the payment gateways, we have corresponding upgrades of those features and you should upgrade them at the same time as you upgrade mojoPortal to make sure that going forward new transactions are being logged in the new common payment log (Note that this really only matters if you’ve been using Authorize.NET in those add on products).

In WebStore it is now also possible to move an order from one site user to another one on the AdminOrderDetail.aspx page. I’ve needed to do this in the past when the user who completed the order no longer works at the company that purchased a product so a different user needed to be able to get the product updates.

Miscellaneous

The Feed Manager now supports relative urls for use with internal feeds using the ~/ syntax to represent the site root.

When using Folder based child sites with related sites mode, closing the master site now closes all the sites

FCKEditor has been removed and is no longer included with mojoPortal because it is no longer kept up to date and doesn’t work well with newer browsers. CKeditor is the new generation of FCKeditor and we’ve included both of them for quite a while. Note however, that if you are upgrading from an older version, the FCKeditor files are still on disk from previouse installation, we are not deleting files during upgrades, so if you really wanted to keep using FCKeditor you could re-enable it by using a custom configuration file to plug in FCKeditor. But, my advice is don't use it, it has problems in newer browsers like IE 9 anyway and CKEditor is a better product.

Fixed a bug where the Janrain Engage sign in system wasn’t working correctly when using multiple sites with related sites mode, we’ve also updated to the newer Janrain Engage widget code.

Fixed some issues with theme caching where it wasn’t always loading the correct theme.skin file when using page specific skins.

Fixed a problem where the SiteRoot was being cached as a property on SiteSettings and then used in various places to build urls. The problem was that if you were accessing the site with more than one url such as using a domain name and by ip address, the cached site root might not be correct for the context of a specific request. This property has now been deprecated and all places in mojoPortal where we were using it are now using SiteUtils.GetNavigationSiteRoot() to make sure the site root is calculated in the context of the current request.

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