Controlling Bright Initialization and Creation of API Keys

If your Bright plan covers active users, "activity" is governed by authentication of the user [that is the request for a Bright API key] from WordPress to the Bright server. This document explains how and why that happens, and how to control it.

By default, Bright initializes itself as part of WordPress's header hook. If a user is logged in, the user is registered for an API key, and that limited use token is written into the page header.

<meta name='bright-token' content='somesortoflongSHA'/>
<meta name='bright-token-expiration' content='2016-12-13T03:41:42.731Z'/>
<meta name='bright-api-url' content='https://[bright-api-url]/bright/api/v2'/>
<meta name='bright-first-name' content=''/>
<meta name='bright-last-name' content=''/>
<meta name='bright-email' content='support@aura-software.com'/>

This enables any Bright content to appear in posts, pages, widgets or in the page header and footer. It also records the user as an Active User.

The rest of document talks about ways to circumvent this default behavior.

You can omit content from the default API key algorithm by adding a WordPress Custom Field called 'bright-stop' to any page or post.

With this set, when rendering the page or post, Bright will not initialize itself. This does mean that any Bright template on the page will not render. Also if you have a Bright template in a header, footer, or sidebar widget, it may not render correctly.

If you have a part of your website not involved with delivering Bright templates, and a set of users who visit only this area, consider using this as a way to eliminate these users from your active user count.

In this model, you can configure Bright to not initialize itself by default. Add an options field on the Bright Setting Page:

When this is set, Bright will initialize itself only if a bright-start custom field appears on the page or post

Important: You will not be able to use Bright templates outside of posts and pages [such as in Widgets, Header, or footer] when this is set. You may also experience issue in blog-rolling Bright content.

If you have Bright on a limited set of pages, and you only want Bright templates to render when users directly hit these pages, this can be an effective method to limit the number of users who have API keys fetched for them. Note, the default Bright behavior is designed to be essentially foolproof in that a Bright template will render from anywhere in the WordPress render loop without interventention. By disrupting this, you may experience issues in cases where a Bright template appears anywhere but in a post or a page with 'bright-start' set.