Chapter 2: Configuration Options

You'll find all of Sitellite's configuration options under the Control Panel tab in the Admin menu. This includes:

• Access Levels
• Activity Log
• Applications
• Cache Settings
• Preferences
• Resources
• Roles
• Site Settings
• Statuses
• Teams
• Users
• Workflow Services

Sitellite comes with 4 built-in access levels, which cover the basic levels needed by most websites. It is a good idea to keep these and simply add your own instead of deleting the ones there, since ones like "public" and "private" are used to determine the visibility of pages and other content items.

The 4 built-in access levels are:

• member – For member-only content areas
• private – For admin-only content areas or applications
• public – For any users including anonymous visitors
• subscriber –For paid site members

The activity log provides a view of all of the editor activity on the site. This includes login and logout times, adding, editing and deleting content, and error messages. The data logged for each log entry includes:

• Date/Time
• Action (Login, Edit, etc.)
• Username
• IP Address
• Message

You can browse the log by action type, username, and date, including day, week, month, and year date ranges.

The applications screen contains a list of all available apps installed on the Sitellite framework. Applications that are editable have an edit icon next to them which brings up a settings form for that app, and add-on applications can be enabled/disabled in a single click.

You can tell at a glance which apps are enabled because the disabled apps are greyed out. Core apps can't be disabled because their functions may be relied on by other apps as well.

Sitellite's caching abilities are fairly robust, but by default all caching is disabled. For storage, Sitellite by default uses files in the "/cache/" folder in the filesystem, and keeps a list of cached files in the "sitellite_cache_file_list" database table. The cache can also be configured to simply output the proper HTTP headers for use with 3rd party cache/proxy servers.

Additionally, Sitellite has independent caches for database queries and for the site menu hierarchy. Typically, enabling just the menu cache can yield good results on moderate-to-large-size websites with many pages. To enable any of the cache types, simply enter a number of seconds in its duration field. We recommend 1 hour as a good starting point, but that depends on the frequency of updates to your site.

You can also control which URLs can be cached and which can't be. The cacheable URLs should contain a list of URLs followed by an "=yes" or "=no" to denote whether that URL is cacheable. URLs can also contain an asterisk (*) to denote a wildcard match.

The preferences contain a list of user preference settings Sitellite offers, such as language or default view (Web View or Control Panel). These are not typically edited except in very custom situations.

Resources is a list of elements that user roles can be restricted from. Resource types include apps, content collections, as well as custom resources you can define for use in your own apps. This list then appears under the Resources tab in the Add/Edit Role forms.

If there is no resource defined for a collection or app, Sitellite assumes site editors should be granted access to it by default. If an app or collection needs to be restricted but doesn't have a resource defined, such as a custom collection or app, simply add one to this list and you will be able to control access to it on a role-by-role basis after that.

When adding resources, if their system name begins with "app_" then that tells Sitellite that the resource is an app. For collections, Sitellite then matches it against the list of collection definitions in the "inc/app/cms/conf/collections" folder. If no matching collection is found, the resource is considered custom.

Each user in Sitellite belongs to exactly one role, and one or more teams. The role defines all of the access levels, statuses, and resources that the user can access.

So for example a "writer" role may be able to read and write to the "draft" access level, but only read from the "approved" access level. This means that the writer can't approve their own changes. An "editor" role would be needed for that.

With resources, the writer can be restricted from certain content collections and apps, but not others.

Built-in Roles

There are nine built-in roles, but five of them are the most commonly used, and all of them are fully customizable to suit the needs of your site. The main five are:

•  master – A role allowing access to everything, typically reserved for the person responsible for the site settings. This role is also often used on smaller sites with only one site editor.
• writer – A writer can create changes to content that require the approval of an editor. This role works with Sitellite's default workflow notifications to trigger emails to an editor user from the same team.
• editor – An editor can approve changes from writers or make their own approved changes directly to the live site. This role also works with Sitellite's default workflow notifications and receives emails when a writer marks a change with a "pending" status.
• member – A non-administrative role used for membership services on the site itself.
• translator – A role used for translators of content on multilingual sites. This role works with the default workflow notifications and receives emails when content in the default language is approved by an editor on the same team.

The site settings allow you to update the core behaviour of Sitellite. These are broken down into five sections:

• Database – The MySQL database connection settings.
• Site – The domain, document root and basic site behaviour.
• Server – Settings affecting the behaviour of the Sitellite Content Server, including the default handler (web page or box), error handler, template set, and output compression (gzip).
• Internationalization – These settings determine how Sitellite's multilingual capabilities behave, including how the language of the current visitor is determined (from their browser settings, a session cookie, a "/fr/" prefix in the URL, or from their Sitellite preferences).
• Messaging – The email and Jabber (aka XMPP) server connection settings, for workflow notifications and other message forwarding.

Statuses determine the lifecycle stage of a content item such as a web page or news story. The status list is fully customizable, but we recommend against removing the statuses that are in place and simply to add new ones for your workflow requirements.

There are 6 built-in statuses:

• approved – A document that has been approved and is visible on the public website.
• archived – A document that is no longer visible on the public site, but can still be accessed in the system.
• draft – A document that is in progress and not yet ready to be published to the website.
• pending – A document that is ready for editorial approval and publishing on the live website.
• queued – A document that has been approved for publishing to the live site at a future date. The document queue is published by Sitellite's task scheduler, which can also automatically archive documents after a certain date/time as well.
• rejected – A document that needs further changes before it can be reviewed for publishing again.

In Sitellite Professional Edition, there is also a "parallel" status for performing A/B or Multivariate testing. Setting an approved page to "parallel" will allow the site editors to create multiple concurrent live versions of a page and have Sitellite test them against live visitors. Sitellite requests a URL from the page that is to be the goal that you want to direct users towards, and will then measure which version causes the best conversion ratio.

Teams break up content into groups of site editors who can perform their various roles on particular pages of the site. Each content item is owned by a team, and the users belonging to that team are responsible for that content item.

On smaller sites, typically everyone belongs to the same team and all content is owned by that team, but for larger sites teams can be used to separate the workflow of multiple groups of writers, editors and translators.

There are 5 built-in teams, and these are fully customizable. Typically, non-admin-level users such as site members belong to the "none" team, and on smaller sites the admins would belong to "core". The others are meant to serve as examples.

• core
• design
• editing
• none
• development

The user list includes both admin and non-admin users, e.g., site members or subscribers. These are all managed in the same place and use the same authentication system in Sitellite.

You can add, edit, and delete users from the user list as well as search for them by name, role, and several other properties. You can also export the users in comma-separated values (CSV) format for use in external applications such as a CRM tool or contact database.

The workflow services page contains a list of all workflow services defined by the various applications installed in Sitellite. These are triggered by certain actions in the system, from adding, editing or deleting a document to logging in or out of the software.

The default services that are enabled activate the activity log and the workflow notifications, and update links and child pages in the site tree when pages are deleted or renamed. It's a good idea to leave these services enabled.

Additional services cover resetting the cache on page edits, search indexing and more.