ITERAS

Each page/post gets a little box where you can choose whether to paywall it or not. The plugin then associates a little bit of extra metadata with the post (stored with the key "iteras_paywall"). Then when that post is served, the plugin first checks if the visitor has a valid access pass from the ITERAS server. If not you can setup the plugin to cut off the content and instead insert call to action content (sign up to get access or login). Or you can also setup the plugin to redirect to another landing page.

Make a test subscriber inside Iteras, fill in the plugin settings, add a test post that you set to be behind the paywall, then experiment with the layout. Once you're happy, you can add the paywall to real posts.

You can insert a login iframe in the content by using the WordPress shortcode [iteras-paywall-login paywallid="abc123,def456"]. You can insert an ordering iframe for signing up for a subscription or ordering a product with the shortcode [iteras-ordering orderingid="subscribenow"]. You can insert a self-service iframe to allow subscribers to manage their subscriptions with the shortcode [iteras-selfservice]. The [iteras-return-to-page url='/some/url/?p=123'] is useful if you need to link to another page in the call to action content. It will append the current page to the given URL so that the visitor is redirected back to the original page after having completed an ordering flow or having logged in. NOTE: due to limitations in the WordPress parser, when you put [iteras-return-to-page] in an HTML tag attribute, you need to be aware of single quotes and double quotes. <a href="[iteras-return-to-page url='/some/url/?p=123']">sign up!</a> works while <a href="[iteras-return-to-page url="/some/url/?p=123"]">sign up!</a> doesn't! These shortcodes, except [iteras-return-to-page], are internally converted to calls to the ITERAS Javascript API. You can pass more parameters if you need to, e.g. next, see the API documentation for more details. The profile parameter is implicit and comes from your plugin settings. There's a few shortcodes for controlling content based on the users logged in status. For showing content when the user has access use [iteras-if-logged-in paywallid="abc123,def456"]Content only shown if the user is logged in and has access[/iteras-if-logged-in]. [iteras-if-not-logged-in] does the opposite. [iteras-if-logged-in-link paywallid="abc123,def456"]Content[/iteras-if-logged-in-link] will automatically insert a link to the subscriber landing page that is configured with the plugin, alternatively a url attribute can be supplied, while login_text can we used to customize the link text. These shortcodes only work with server validation enabled.

Yes! Add the GET-parameter orderproduct to a link to your ordering page, e.g. /buysubscription/?orderproduct=12MPro. This will select the "12MPro" product when the user gets to the form.

It is possible to override the decision of which content should be paywalled. Add a hook to the iteras_override_content_paywall filter to define a function that should have the last say in if the content should be paywalled or not. This can for example be used for handling share links the gives the user access eventhough they don't have a login. This could look something like this: /** * Override the decision to paywall the particular content * * @param integer $post_paywall_ids The paywalls that give access to the post, if empty the post would not be paywalled be default * @param object $post Reference to the post being potentially paywalled * @param boolean $user_authorized If the user has a valid iteraspass that has the appropriate access * @param array $paywall_config Contains the Iteras plugin configuration */ function make_paywall_decision($post_paywall_ids, $post, $user_authorized, $paywall_config) { // example of generated share token error_log(openssl_encrypt(json_encode(array('shared_by'=>"John Doe", 'post_id' => $post->ID)), "aes-128-cbc", "somesecret")); $token = $_GET['token']; if (isset($token)) { $share = json_decode(openssl_decrypt($token, "aes-128-cbc", "somesecret")); if (isset($share) and $share->post_id == $post->ID) { echo "Shared by " . $share->shared_by; // signal that the paywall should not be applied return false; } } // return the paywall ids to apply the paywall as normal return $post_paywall_ids; } add_filter('iteras_override_content_paywall', 'make_paywall_decision', 10, 4);

When you link to other pages, you may be losing the return information needed to redirect the visitors. Send the URL through [iteras-return-to-page] as described above to forward the return information. When an iframe is embedded directly, the return information is inserted automatically, but when you put the iframe on another page and link to that, the iframe needs to know where the visitors come from to be able to return them correctly.

No. But it’s not hard to get one - if you are interested in learning more about ITERAS, please visit iteras.dk and contact us.

You will need to do a custom integration. The plugin attaches to the the_content hook in Wordpress which in some situations is called mutiple times by 3rd party plugins. In this case set the "Paywall integration method" to "Custom" and add the paywall code manually to the theme or plugin you are using. This can be done either by wrapping the post body with the shortcode [iteras-paywall-content]...[/iteras-paywall-content] or by calling Iteras::get_instance()->potentially_paywall_content(...) which returns the content wrapped with the paywall. Logged in subscribers see truncated preview instead of the full article When server-side validation is enabled, the plugin truncates paywalled content for visitors without a valid access pass. If a page cache in front of WordPress stores that truncated response under the post URL, every subsequent visitor - including paying subscribers - will see the truncated version. To prevent this, the plugin sends no-cache signals (Cache-Control: no-cache, private, no-store, max-age=0, must-revalidate, Pragma: no-cache, Vary: Cookie, X-LiteSpeed-Cache-Control: no-cache, X-Accel-Expires: 0) and defines DONOTCACHEPAGE for paywalled posts. The "Prevent caching" setting controls this behaviour and is on by default. If paywalled content is still being cached after upgrading: Run curl -I https://example.com/<paywalled-post>/ and check the response headers. If Cache-Control: private, no-cache, no-store is present, the plugin is doing its job and the cache layer is ignoring the origin response. If those headers are missing, another plugin or theme is stripping them - disable plugins one at a time to find the culprit. If you use Cloudflare, add a Cache Rule that bypasses the cache when the iteraspass cookie is present, or set the Cache Level to "Respect Existing Headers". Cloudflare's default "Cache Everything" page rules can override origin caching directives. If you use Varnish or nginx fastcgi_cache/proxy_cache, configure the cache to either respect origin Cache-Control: private/no-store (most defaults do), or to bypass cache when the iteraspass cookie is present, or to include the iteraspass cookie in the cache key. Make sure the cache does not strip the cookie before forwarding to origin - if it does, even authorized subscribers will receive truncated content. If you must disable the plugin's no-cache signals (for example because your cache is configured to vary on the iteraspass cookie and you want to keep page caching), uncheck "Prevent caching" in the plugin settings. Do not disable server-side validation - that exposes the full paywalled article to anyone with JavaScript disabled. Subscribers on iPhone/iPad keep getting logged out Safari and other WebKit browsers treat cookies written by JavaScript as script storage and delete them after 7 days without user interaction with the site - and cap them at 24 hours if the visitor arrived on a URL with query parameters from a domain WebKit has classified as a tracker. Since the login iframe used to write the iteraspass cookie with JavaScript, subscribers on iOS were logged out again and again no matter how long the access pass itself was valid for. From version 1.9.0 the login iframe hands the access pass to WordPress instead, and the plugin sets the cookie with a Set-Cookie header from your own domain, where the limit does not apply. The pass is renewed the same way, so the cookie never goes back to being script-written. The "Login session cookie" setting controls this and is on by default. It requires a signing key, since the plugin verifies the signature on the pass before it sets any cookie. If subscribers are still logged out too soon: Check that a signing key is filled in on the settings page. Without one the setting is inactive. Log in with Safari's Web Inspector open and check in the Network tab that the request to ?iteras-pass=1 answered with a Set-Cookie: iteraspass=... header. If it did, the cookie came from your server and Safari's limit does not apply to it. The cookie's expiry date under Storage is not a useful check - Safari shows the full expiry either way, and removes script-written cookies without changing it. If your visitors move between example.com and www.example.com (or other subdomains), set the "Cookie domain" setting to .example.com so the session follows them. Use the setting rather than an Iteras.cookieDomain snippet in your theme - if the two disagree the visitor ends up with two iteraspass cookies that drift apart, and which one counts is up to the browser. If a page cache in front of WordPress serves pages without running PHP, make sure it bypasses the cache for requests that carry an iteraspass query parameter. Most caches already bypass URLs with a query string. POST requests, which is what the pass endpoint uses, are never cached.

Yes, see keeping visitors logged in in the API documentation. Security issues If you discover a security issue, please contact us. You can also report it through Patchstack.