Test Mode is useful if:

1. you want to experiment with a feature of Suma but don’t have a license for that feature, or
2. you are using a licensed feature in production and need to be able to exercise it with test payment methods (i.e. Sandbox payment accounts) but without excluding regular users from using the site.

Test Mode is available for most licensed features of Suma and is activated per feature from Suma’s Settings page in the Wordpress Administration area.

When a feature is activated in Test Mode:

1. the feature will only be available in Test Mode to the Administrator (as explained below),
2. the feature will continue to operate in Live Mode for all other users if that feature is licensed, and
3. the feature will use the Sandbox Payment Processor when required (e.g. PayPal’s Sandbox instead of your Live account).

An important principal of Test Mode is that its use is restricted to the Wordpress Administrator (specifically, requests from the Administrator’s computer).  If any other user requests a Test Mode enabled feature they will be given that feature operating in live mode if there is a valid license for it or it will be treated as a disabled feature if there is no valid license.  Suma achieves this operational behavior using the following mechanism.  When the Administrator activates Test Mode on a feature, Suma saves their IP Address (i.e. their network address), which is reported on the Settings page beneath each feature that is in Test Mode.  Then whenever Suma receives a request for that feature and Test Mode is enabled for it, it will compare the requester’s IP Address with the saved one. If they match then the request will be given a Test Mode version of the feature.  If they don’t match, then the requester will be given the Live Mode version of the feature if its been licensed otherwise its treated as though the feature is disabled.  Since only the Administrator has access to Suma’s Setting page, only the Administrator’s IP Address will be saved for comparison.

The Administrator’s IP address was used as the basis of this scheme because it allows the Administrator to access features in Test Mode without being logged into Wordpress.  This is an important requirement because Suma treats logged-in users differently than anonymous users (as when determining whether they have access to content, or whether access to Subscription Plans) and furthermore treats a logged-in user in the Wordpress Administrator role differently again (not interfering at all).  Using IP Addresses does however create the possibility that a malicious user could impersonate the IP Address of the Administrator in order to access a feature in Test Mode but this would merely offer them the ability to subscribe using a Sandbox account instead of a Production account and for this they would need the password for the Sandbox.  Since this scheme does not grant any access to the administrative functions of Suma or Wordpress,there is no threat that this could be used as a backdoor to perpetrate other exploits.

Being able to have the Administrator test a feature on a live site using the site’s live data and its actual configuration (posts, subscription plans, other plugins active on the site, etc) means the Administrator can reproduce the same scenarios as actual users without needing valid payment methods.  And allowing Suma to service both Sandbox and Live Payment Processors simultaneously means that you don’t need to shut out users from the site (e.g. maintenance mode) in order to run test transactions.

Features that can be run in Test Mode:

• Donations Feature
• Onsite Recurring Payments Feature
• Hosted Recurring Payments Feature
• HTTPS Protocol

Subscription Plan Types: Guest and Paid

There are two types of Subscription Plans: Guest and Paid.  Guest Plans are free and thus don’t require any payment from the user when registering.  Paid Plans, in contrast, have billing terms associated with them (e.g. $9.95 every month) and thus require a payment method from the user in order to complete their registration.  The payment methods accepted by Suma depend on how its been configured but could include a PayPal account or a credit card.

Important Note. When no Payment Modules are activate Suma will prevent Paid Subscription Plans from being offered to users via the registration process and will not allow Paid Plans to be created or edited.  This is because without a Payment Module it is not possible to accept payment information from the user and thus not possible to register a user under such a plan.

Creating a Subscription Plan

Plans are created from the Tools → Subscription Plans page in Wordpress’ administration area (click on the Create Paid Plan button or Create Guest Plan button).

If the Create Paid Plan button is disabled its because there is no Payment Module active that supports recurring payments or its not correctly configured.  If its not correctly configured you’ll see error messages displayed on its Settings page.  So, unless a Payment Module is activate, only Guest Plans will be shown and only those which don’t have an expiry date.  In addition, any Paid Plans that may have been defined will not be displayed for management or offered to users if there isn’t a such a Module activated.

The following are key concepts about Subscription Plans:

Plan Descriptions

This field allows you to enter a description about the Plan.  It could be something like “Gold Level” or “Private Invitation”, and is considered the user-defined part of a Plan’s description.  Suma will generate the other part of the description (the contract part) based on the parameters you define in the Plan.  Examples of this would be “Free access for 15 days” and “$10.00 USD every month.”  Together the user-defined part and the contract part must not exceed 127 characters in length (a limitation imposed by PayPal).  Thus you are constrained in the amount of text you can include in the user-defined description and this depends directly on the length of the contract part which depends in turn on the parameters to the Plan.  Fortunately, you can edit the Plan once its created so that you can play with its description until its acceptable.  The reason for having contract wording in the description is its a requirement of PayPal’s Express Checkout service, but is considered good business practice in general.  Furthermore, since Suma’s contract generator uses the same grammar as PayPal you can be confident that the Plan’s terms are beyond dispute.  Finally, the entire description (user and contract parts) are displayed to the user when they are going through the registration process so that the user can compare different Plans based on their contracts.  If you want to provide more information about a Plan you can use Suma’s Customization API to add a hyperlink to the user-defined description (see getPlanDescriptionHREF() function) which can be used to link to another page on your website which provides more details about the Subscription Plan.

Access Codes

The Access Code is a (practically) unlimited length text field associated with each Plan.  It can be empty or contain any text you wish.  The purpose of the Access Code is to restrict availability to that Plan to only those users who know the Access Code.  In this way, you can create Plans (discounted or free) for certain individuals only.  You would provide those individuals the Access Code which they would enter in the Promotion Code field during the registration process and if the Code they enter is valid (i.e. linked to a Plan) then that Plan’s description is presented to the user.  If a Plan does not have an Access Code then that Plan is displayed to all users (provided its state is: Open to New Subscribers).  You will notice that Suma automatically assigns a random Access Code whenever a Guest Plan is created.  This is to ensure that you don’t inadvertently create a free alternative to your Paid Plans that is accessible by the public, who would surely choose the Guest Plan over the Paid Plan and thus negatively impact your sales.  If its your intention to have the Guest Plan be available to all users (a limited length Guest Plan for instance) then simply delete the text from the Access Code field and click on the Save button.

Plan Period / Trial Period / Regular Billing Period

Every Guest Plan has a period for which it is valid.  This can be a limited length period (e.g. 2 weeks) or unlimited.  After the Plan’s period ends (if ever) the access granted through that Plan will cease.  Suma does not allow users to re-subscribe to the same Guest Plan again unless its a non-expiring Guest Plan or the Guest Plan’s period hasn’t expired (as measured from when the user first subscribed to the Plan).  Note: this restriction is per user account, so users may try to defeat this by signing up under a different username and email address.

Paid Plans all have an optional Trial Period followed by a required Regular Period.  The Trial Period, if specified, represents one billing cycle (i.e. one payment) if the Trial Amount is non-zero.  The Trial Amount can also be zero in which case it become a free Trial Period.  If there is an amount specified then it is billed at registration time.  If there is no Trial Period, then the Plan begins with the Regular Period.  Regular Periods must have a non-zero billing amount specified (i.e. they can’t be free).

Member’s Wordpress Role

If a user is registering for the first time then Suma will create a Wordpress user account for them in addition to setting up a Subscription Profile for that user.  When a user successfully subscribes to a Subscription Plan, Suma will set the Wordpress Role of that user’s account to the value specified by this field in the Subscription Plan.  It should be noted that Suma doesn’t use Roles in its access control decision making process.  Those decisions are made entirely based on whether the user has an active Subscription Profile or not and whether that Profile grants access to the content they are requesting.

Editing a Subscription Plan

Subscription Plans can be edited (as of Suma 3.0) to allow you to alter the parameter values for the plan.  Any changes made to a Subscription Plan will only apply to users who subscribe to that Plan after the changes have been made.  Users who have already subscribed to the Plan will not have their Subscription Profiles changed.  Thus, changes to a Subscription Plan do not affect current Subscribers to that Plan but only future subscribers.

Terminating a Subscription Plan

Subscription Plans can be terminated from the Subscription Plan Manager.  Terminating a Plan means that every user who is subscribed to that Plan will have their subscription canceled.  When all the cancelations are successful, you will then be able to Delete the plan.  If you merely wish to stop offering the Plan to new users and do not want to cancel the subscriptions of existing subscribers then you can close the Plan to new subscribers instead.  This is achieved by clicking on the Plan’s Yes button for the field “Open to New Subscribers” in the Subscription Plan Manager which will toggle the value to No.  This action is reversible and is achieved by clicking on the button again.  Setting this parameter to No instructs Suma to not allow new users to subscribe to this Plan and thus it will not be shown as a choice during registration.

See Also:

• Subscription Groups for creating more selective Content Access models
• Hosted Recurring Payments and Onsite Recurring Payments
• Suma’s Customization API getPlanDescriptionHREF() for adding a hyperlink to a Plan’s user-defined description

Suma provides its own built-in shortcode “[suma]” using this technology which allows authors to restrict access to select parts of a Post’s content.  Using shortcodes can thus be more selective than marking the entire Post as restricted, and so compliments Suma’s other mechanism for restricting access (Setting the Visibility of Restricted Posts).

The Suma short code is used to tag content.  Thus it has opening and closing tags.  An example of use is:

Some content here.  [suma] This content will be subject to Suma’s access control rules. [/suma].  More content here.

The following arguments can be used with this tag:

• notLoggedInMsg=’msg‘ – If the tagged content is requested by a user who isn’t logged into Wordpress then Suma returns msg instead of the tagged content.  Msg maybe HTML code.
• noSubscriptionMsg=’msg‘ – If the tagged content is requested by a user who is logged into Wordpress and who is a subscriber but doesn’t have any active subscriptions (e.g. their subscriptions have expired) the Suma returns msg instead of the tagged content. Msg maybe HTML code.
• inadequateSubscriptionMsg=’msg‘ – If the tagged content is requested by a user who is logged into Wordpress and who is a subscriber but doesn’t have a subscription which provides access to this content then Suma returns msg instead of the tagged content. Msg maybe HTML code.
• restrictedTo=”SubscriptionGroupName[,SubscriptionGroupName]“] –  The user requesting the tagged content must have an active subscription belonging to one of the named Subscription Groups for Suma to allow them access the tagged content, otherwise Suma considers the user to have insufficient access privileges.  This parameter thus modifies the access decisions of the above arguments.
• invert – Inverts the decision to replace or not replace the tagged content.

These arguments can be used in combination within the same tag.

The following examples can be used with a default installation of Suma.

Example 1.  Require the user to be logged into Wordpress (with or without a subscription) in order to view the tagged content.

This is untagged content.
[suma notLoggedInMsg='You must be logged in to view this content']
Content viewable only when logged-in.
[/suma]
Resuming with regular content.

Example 2.  Display a message but only to users who aren’t subscribers.  This could be used for instance to display advertisements to non-members and leave members to view the Post without ads.

This is untagged content.
[suma invert noSubscriptionMsg='This text is displayed to users who aren't logged in and could have been the HTML for an advertisement'/]
Resuming with regular content.

Suma achieves this by replacing certain elements of a Post or Page (e.g. the body, parts of the body, comments or excerpts) which are not accessible by the viewer with messages explaining that they don’t have permission to view this information and how they can obtain it. Suma gives the site’s administrator the ability to choose which of these elements are to be displayed (See Visibility of Restricted Posts Setting and Suma ShortCodes).

The advantages of this approach are:

• Lets the viewer know what they’re missing.  A well written title and excerpt can inform the visitor of what the post or page is about without revealing its details.  It can thus generate interest in the article and persuade the visitor to subscribe to your website to read the entire article.
• Allows the depth and breadth of content on your site to be revealed even if the content is not accessible.  If your site’s content is extensive (an important factor in search engine rankings) then using this approach will ensure that coverage is reflected to the public.
• Lets search engines do a better job of indexing your website.  Using this approach search engines will be able to view key elements of the page such as keywords found in the excerpt and meta-tags you have added.  Whereas if the page were hidden from non-members then search engines would encounter a generic not-found page which would lack content specific to that page that is essential for the engine’s ability to properly rank it.
• Doesn’t interfere with other approaches.  This approach doesn’t interfere with or prevent you from using Wordpress’ native access controls to either hide a page completely or password protect the page through its Visibility attribute.

See Also:

• Visibility of Restricted Posts setting