• Visitor: Any one or device who visits the site but is not necessarily identified
• User: Any visitor who can be identified (e.g. has a session ID or tracked IP address)
• Guest: A user who is not logged in (in Conversr, they all share a special "Guest" ID / account)
• Member: A user who is logged in with a registered account on the website (they have a username and a member ID)
• Author: Specific to the authors addon, a profile of an entity (could be a member, individual, or even a company) who makes content for the site
• Subscriber: A user who receives newsletters from the site (they do not necessarily have to be a member)
• Submitter: A user who submitted content (usually a member, but could be a guest if the site is very open to submissions)
• Staff: A member who moderates any significant portion of the website
• Super-moderator: A staff member with global moderation capabilities
  • Moderator: Same as super-moderator but does not have those capabilities globally; they may only be able to moderate certain sections or content
• Super-administrator: A staff member with literally undeniable access to everything on the site
  • Administrator: Same as super-administrator but they might not have access to the most elevated of privileges such as accessing maintenance scripts

• Password Strength Setting: Administrators can set a minimum password strength requirement, forcing members to choose stronger passwords. Password strengths are calculated on a scale of 1-10 using algorithms that take into account letters (including case), numbers, symbols, repeat characters, use of dictionary words, and use of usernames / dates of birth / e-mail addresses.
• Forced Password Resets: Administrators can force specific members or all members to change their passwords upon next login, enhancing security in case of potential breaches.
• Expiring passwords: Administrators can require members to change their password after so many days.
• Encrypted CPFs: If the server has the OpenSSL PHP extension installed, specific CPFs (such as ones containing other passwords) can be encrypted to protect sensitive member data in case of a server compromise.

• Enforce specific requirements for membership (e.g., job role in a company forum).
• Categorize members based on their interests or affiliations (e.g., football players in a school forum).
• Display additional information on member profiles and forum posts.

• Regular Registration: Users can click on "join" links, agree to your rules, and fill out a registration form. They will then receive an activation email to confirm their email address (if enabled).
• Invites: You can restrict joining to invite-only. Existing members can send invites, and only those who receive an invite can register.
• Manual Addition: Administrators can manually create member accounts through the Admin Zone. This is useful for pre-joining members or handling issues with the regular registration process.
• Other Methods: Composr also supports automatic member joining through LDAP and HTTP authentication.

Ran some of the early websites where ocPortal came from

Technically the original developer of ocPortal, in that he wrote the first few lines of code

Heavily involved in the feature design process

Hosted some of our early meet-ups

Original developer of ocPortal, former lead developer of Composr CMS

Masters degree in Computer Science from The University Of Sheffield

Undertaken work for over 15 FTSE-100 companies, as well as many small and mid-sized organisations. Includes a number of banks and major brands.

gameRevolt (@[email protected]) - LinuxRocks.Online

That depends on several factors. Here are some pros and cons of each:

It is not recommended you do this because you may run into issues. For example, some changes were made in crypto_master.php and data/upgrader2.php prior to the first v11 alpha. These changes will result in a broken upgrade unless you already pulled these changes from git. Similar situations could happen in the future as well.

It is recommended you either discard the git install and use a fresh install from the Downloads, or to maintain a git install and a bleeding-edge release install separately. Do not combine the two.

Absolutely! Frequent changes may be made to both bundled and non-bundled addons. Bundled addons will be updated via the upgrader. For non-bundled addons, you will have to update them through the addons management screen (Admin Zone > Structure > Addons). You will be informed which ones need updated.

Once version 11 reaches release candidate, we do not expect frequent updates to non-bundled addons anymore. But it is still good practice to check after every update.

Yes, for basic non-custom v10 sites. However, expect some issues to arise in the process. And please report those issues to the tracker.

For v10 sites with non-bundled addons or customisations, upgrading to v11 will likely break the site until you update the non-bundled addons or temporarily remove the customisations.

We aim to have the upgrader fully functional for a large majority of types of sites and for sites using non-bundled addons by the time version 11 reaches release candidate stage.

We do not recommend upgrading production v10 sites at this time until v11 reaches stable.