SVPortal is a new “front end” for Open Simulator. It is designed for two groups:
- End users: Users can see their profile, their friends list, publically publish their profile, offer partnership, view the world map and manage their estates.
- Grid Staff/Administrator: Grid staff and administrators can also do other tasks such as account approvals, grid news, pages, links, who’s online, user management, all estates and logs.
I will not be providing a full manual for this – I don’t have enough time to go through it all! However, I will be showing screenshots of functionality in a few categories and then there will be a larger “install” section. Please note: This product is created for “Grid Owners”. As such some technical knowledge is assumed. Additionally – as this is designed as a system to manage a grid – it has no use for anyone who does not have a grid to manage. End Users may find the section on End Users interesting but ultimately it cannot be used in that capacity unless your grid owner has installed it – you cannot do so yourself.
End User Functionality
Grid Management Functionality
New Setup System
Installation
Installation of SVPortal has been simplified by moving most of the configuration options from a very long config.php to a settings registry within the application itself.
You still need to set the portal URL, Database settings, and User Mappings in the config.php however (without the database settings in the config.php for example, it cant connet to the database – so could not get its database settings FROM the database!).
The files below are part of the distribution but are copied here as WordPress pages for convenience
- README.md – Introduction to SVPortal
- QuickStart.md – this file contains only what you really need to know to get to the point of logging into the Portal
- SVPortal-Setup.md – this file provides some help with the setup menus. Most of these however also have online help for each option – so you may not need to refer to this file at all.
- Install.md – this file has the full “long form” install. Again you may not need this at all (especially if you are using Nginx and MariaDB).
Once the webserver is serving the portal – the rest of the configuration is done via the web. Follow QuickStart.md to get to this stage.
Notice about distrubution
SVPortal is open source software distributed with an Apache 2.0 licence. This means anyone can take a copy of the software and modify it as they see fit and re-distribute it. According to the terms of the licence any re-distribution either needs to be the original version, or any alterations need to be identified (“changes made by Joe Bloggs” etc). However, it is quite possible that some versions of SVPortal could become available that have modifications where those changes are not speficied.
Modifications could improve the software, or could introduce new bugs – or just work in a different way to the original code. If you want to be sure to be using the original code with all the features as originally created (or with changes that have been sanctioned by the original creation team) then the safest place to download this, is from this website.
Downloading SVPortal from anywhere else is not guaranteed to be the original code. It may have improvements, or it may have missing features or bugs. The choice as to where to download SVPortal is of course yours, but the “official” download is only via this website.
This new version of SVPortal moves most of the configuration to a new Setup screen within the Administration menu (visible only to System Administrators, not Grid Staff).
Users upgrading from SVPortal v1.x may encounter problems if upgrade steps are not performed correctly. As settings are now retrieved from the database stored registry, if current settings are not moved to this, then all your settings in config.php will be ignored. Please see the section below copied from https://www.glenysbieler.com/svportal-setup-md/, the SVPortal-Setup.md file.
Upgrading an existing portal
Two routes bring existing config.php values into the database:
- Automatic, per setting. Each getter copies the value from
config.phpthe first time it is needed and no row exists. Opening a Setup tab renders every field on it, so a tab visit imports all of that tab’s settings at once. importsettings.php, deliberate and complete (recommended). Run once from a shell, before first opening Setup:
sudo php importsettings.php
frompublic/. It imports every migrated setting, prints a diff, backs upconfig.phpto the folder abovepublic/and comments out the migrateddefine()lines. It needs root, or any user with write access toconfig.phpand to that parent folder; without that the import still completes and only the trim is skipped. SeeInstall.mdfor details.
Placeholder values are imported too, on purpose: a copied-over YourRemoteAdminPassword is correctly shown as “not configured” rather than the import inventing a configured state.
inworld_relay.lsl is a simple relay script designed to take a message from the portal website and send to an in world avatar. The script publishes its current httpin address so thge portal can contact it – then the portal sends a request to this script to relay a message to the intended user. As such the IM is sent as an “object IM” so it doesn’t get delivered exactly the same way – but still enables immediate contact if the user is online – as opposed to inserting a row into im_offline which will not deliver until the next time a user logs in (so if they are already online they wont get it till next time).
The script should be put in an object that will not be moved. Please read the instructions in the script – it will need a constant changed to point toward the URL of your portal – and also needs s secret to be put in a notecard in the same object.