Note. Emails are sent from within Wordpress and thus use the email configuration provided to Wordpress. In some shared hosting environments such email sending capabilities are not available (by default) to Wordpress. In such cases you can install a Wordpress plugin which will provide emailing capabilities to Wordpress by connecting to an external SMTP email server (of your configuring).

You should ensure that your Wordpress site has the capability to send emails before enabling this setting. Otherwise, users will not receive any verification emails and thus won’t be able to proceed through the registration process.

Subscription Groups are one of the options for a Post or Page’s Visibility setting; the other options are Everyone and All Subscribers.

Subscription Groups are useful if you want to restrict a Post or Page’s access to subscribers who have a particular Subscription Plan.

For instance, you might have a Paid Subscription Plan and a Guest Subscription Plan offered to your users and you want only paid subscribers to have access to a particular post.  In this case, you would create a Subscription Group (perhaps labelled Privileged Subscribers) and have it comprised of the Paid Subscription Plan.  Then you can set the Post’s Visibility to that Subscription Group.  This would limit access to that Post to subscribers who are subscribed to the Paid Subscription Plan (and is active, obviously).

To continue the example further, you could also define a special Guest Subscription Plan with a Promotional Code intended to provide access to the same content as the Paid Subscription Plan does but without cost – perhaps this is for special users who you want to give premium access but not charge them for it.  All that is needed to include this Plan in the Access configuration is for you to add it as a Plan of the Subscription Group you defined earlier; you don’t need to go back and change any of the premium Post Visibility settings because they are already set to limit access based on a Subscription Group and not individual Subscription Plans.

Likewise, if you wanted to offer an alternative Paid Subscription Plan which has access to the same content but perhaps different terms (e.g. a yearly subscription instead of 3 monthly) then you would simply create this new Plan and add it to the Subscription Group(s) where the alternative Plan appears.

See Also:

• Managing Subscription Plans
• Subscription Plans

When a Promotional code is specified for a Subscription Plan that Plan will not be displayed in the list of available Subscription Plans during the user’s registration experience unless the user enters the promotional code for that Subscription Plan.  The reason for hiding Promotion-related Subscription Plans is that if the Plan were to offer a discount, for instance 20% of the normal price, compared to a regular Plan and both were displayed but the discounted one were not accessible, then your users would be disappointed that they were not given the better deal.  Thus, promotion protected Plans are only displayed to the user when the user enters the Plan’s code.

Another aspect to note about Promotional codes is that if there are no Plans which have promotional codes then the promo code input field is not displayed on the registration form.  This would be the case, for instance, if you had a Plan with a promo code but that Plan’s state was Listed = No.

Below is a screenshot of the registration form when a promotional code can be used.

Promo codes are set on Subscription Plans from the Tools→Subscription Plans area of the Wordpress Control Panel.

Note that these subscription and billing pages are only shown to users who registered through Suma. Users who’s accounts weren’t created through Suma would not have access to such pages (wouldn’t make any sense) and this ofcourse also includes Administrators.

Running pre-2.9 Suma?

If you have Suma 2.8.x or older then you should first upgrade to the Suma 2.9.x version before undertaking the upgrade to Suma 3.0.

What will I notice?

Suma 3.0 introduced a lot of new features and quite a different underlying architecture to allow it to be more flexible and accommodate all sorts of new feature requests that I’ve received.  All of the existing 2.9 features are included in Suma 3.0 except the following:

• Paid Subscription Plans no longer offer an initial payment feature.  This is to harmonized Suma with some other payment processors (other than PayPal) which we’ll be including in later releases which don’t support this feature.
• Paid Subscription Plan Trial Periods have been simplified so that there are no billing cycles, just a trial period and trial frequency.

These restrictions will not affect any subscribers who may have already subscribed to plans with these features.

Other than that all the functionality is still there, and much more.

The 12 step program to Upgrade to Suma 3.0

Note 1. For a short period of time during this upgrade, Suma will be deactivated.  While deactivated it will not be protecting access to your content.  For this reason alone you shoul use a maintenance mode plugin (such as The Maintenance Mode plugin) to keep the public out of your site, but you should do this for another important reason.  Some upgrades can take 15-30 seconds on large datasets (lots of historical information in the database).  If a request arrives at your website during this time when the plugin hasn’t completed the schema conversion, it will launch another batch of conversion actions which will only interfere with the conversion already taking place.

Note 2. Suma 3.0 uses a different license manager than Suma 2.x.  Hence your old 2.9 license key won’t work.  You’ll need to obtain a new one (available here: Suma 2.9 Upgrade Licenses) and activate it once Suma 3.0 is installed.  If you upgrade but don’t activate a new key then your installation will only be operating in test mode not production mode.

1. Admit Ensure that the database account used by Wordpress to access the database has DROP, CREATE and ALTER privileges.  The upgrade will not work without these.
2. Backup all Suma database tables in the Wordpress database (i.e. those beginning with wp_Suma_*)
3. Backup the Wordpress wp_options table because Suma will be updating its options that are saved there
4. Backup all files currently in the suma plugin directory (i.e. wp-content/plugins/suma).
5. Deactivate the Suma Plugin from the Wordpress Control Panel
6. Remove all files from the Suma plugin directory.
7. Copy the new Suma 3.x files into the suma plugin directory
8. Activate the Suma Plugin
9. Check the Suma Admin Event Log in the Dashboard area of Wordpress for any errors that may have been encountered during the installation
10. If you have Suma 3.0 license keys then you should activate them from Suma’s Settings page
11. If necessary, you should copy back any customizations you may have had in the suma plugin directory such as a suma_userforms.php file (which are now called suma_customization.php) or any changes to the suma.css file you might have done.
12. Test that the installation is operating correctly.  As of Suma 3.0 you can now run Test mode alongside Production mode.  See this article for details: Test Mode Setting.

Upgrade complete.

See Also:

• Purchase an upgrade license from the Suma shop
• Download the latest Suma v3 from the HelpDesk
• Ask for help at the HelpDesk if you have questions

Users can click on the Checkout button and be automatically transferred to PayPal’s website to complete the payment or can enter credit card information on the form and Suma will submit this to PayPal.  Thus users do not need a PayPal account to pay for a subscription.  Users are automatically transferred back to your site if paying with PayPal whether they complete or cancel the checkout process.

Using this feature in Production requires a license.  The license can be purchased from the Suma shop.

You can also experiment with this feature in Test mode which doesn’t require a license.  If used in Test mode, all transactions will be routed to the PayPal Sandbox.  Thus you will need to create an account in the PayPal Sandbox.

See Also:

• A Comparison of Payment Modules showing their similarities and differences
• A Payment Module screencast demonstrating the different Payment Modules
• A list of Licensed features in Suma
• The Suma shop for purchasing licenses

Users would click on the Checkout button and be automatically transferred to PayPal’s website to complete the payment.  Users will need a PayPal account to and they can open one during the checkout process.  Users are automatically transferred back to your site whether they complete or cancel the checkout process.

Using this feature in Production requires a license.  The license can be purchased from the Suma shop.

You can also experiment with this feature in Test mode which doesn’t require a license.  If used in Test mode, all transactions will be routed to the PayPal Sandbox.  Thus you will need to create an account in the PayPal Sandbox.

See Also:

• A Comparison of Payment Modules showing their similarities and differences
• A Payment Module screencast demonstrating the different Payment Modules
• A list of Licensed features in Suma
• The Suma shop for purchasing licenses

In 2007 a client of mine needed a subscription-based pay-to-view website. I determined that Wordpress would suit her needs well and so went about evaluating the various technology, products and plugins available.  I even prototyped a solution consisting of several plugins combined.  But I was not completely satisfied with any of these for one reason and another. So I decided to develop myself what I needed and at the same time fill a void in the marketplace.

The design and initial development of Suma took 6 months.  Then for another 12 months I had Suma in the market but kept “under the radar” (no advertising) so as to receive valuable feedback from real customers in real scenarios. I call it real world validation, where you get to see what the rest of the world thinks of your product.  Plus, you get to see how customers use the product which sometimes is quite different from what it was designed for.  Having worked for various software companies and pure research organizations in the past I am convinced that the best R&D laboratories around are your customer’s businesses.  They are the ones who know better than anyone what a great product would look like (at least for them – and ultimately, that’s who matters).

From that feedback and the many in-depth conversations I had with website developers and business owners came a much deeper insight into the business of blog-based commerce than I could ever have conceived of on my own. Consequently, I spent Sept 2009 to January 2010 redesigning the architecture and fundamental principals of Suma to be flexible, adaptable and aligned with the needs of small business owners seeking to utilize Wordpress for paid-access content delivery.

The result is the modest Suma 3.0. In these early releases the functionality will not seem dramatically different from Suma 2.x versions. However, its new architecture has laid the ground work to be able to add more payment processors (not just PayPal), to allow Suma’s dynamically generated forms to be customizable, and to allow developers to extend Suma even more to suit their own particular business requirements.

I’m always interested to hear from other developers and business owners about the projects they’re working on and how Suma can help and I especially like hearing feature suggestions or about any other technology you’re considering. You can reach me directly at b1@camacit.com.

And yes, there is a story to the name Suma.  It was the project code-name I had been using with that earlier client.  It was a short-hand way for me to label the Subscription Management component of the project (SUbscription MAnagment).

Cheers,
Brenton

Architect and Developer
Suma Plugin for Wordpress