SV Portal v2.0 Beta 1

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:

1. Automatic, per setting. Each getter copies the value from config.php the 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.
2. importsettings.php, deliberate and complete (recommended). Run once from a shell, before first opening Setup:
   sudo php importsettings.php
   from public/. It imports every migrated setting, prints a diff, backs up config.php to the folder above public/ and comments out the migrated define() lines. It needs root, or any user with write access to config.php and to that parent folder; without that the import still completes and only the trim is skipped. See Install.md for 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.

A very small cosmetic change to the “logs” screen.  It’s now wider, the actor name should not wrap and the log entries have a consistant look and feel.  Previously different types of log entries had a different look.   This was not actually intentional but a result of Claude converting some entries to json and others not.   It’s now been fixed so this is consistant.

This change isnt needed for your portal so its up to you if you wish to apply this to your portal install.   Also in this package – the config-sample.php has explicit GRANTs needed for granting access for the portal to modify opensim tables needed for specific features.  These are identified by ENABLE_ constants which explain what the option does – and gives the GRANT statement needed to make it possible, if you wish to use those features you need to enable the feature and execute the grant against your opensim table for it.  These features are:

• ENABLE_PARTNERSHIPS
• ENABLE_CHANGE_MATURITY
• ENABLE_ESTATE_MANAGER_EDIT
• ENABLE_ESTATE_OWNER_TRANSFER
• ENABLE_REGION_ESTATE_TRANSFER
• ENABLE_ESTATE_DELETE

Please see the config.php to see exactly what these do and decide if you want to enable them or not.  ANY of these also need the overriding ALLOW_OS_DATABASE_WRITES to be true.  If it is false, then none of the above will work – its a “master switch”.  When these functions are disabled – the corresponding options will just not appear in the portal.

If you wish to update to this version this is the standard practice:

• copy your portal directory (cp -a portal portal-safe for example)
• unpack the portal code overwriting the existing files.
• your config.php file should be safe as the portal package only contains config-sample.php

Once files are updated you should be able to use the portal as normal – but the log screen will be wider and have these other changes.

This is the main download for the SVPortal OpenSim Web Frontend updated 12th July 2026 at 17:30pm BST.  It will always have the latest updates in it.   If you have prevously downloaded this package – then please read the notes below for any changes you may need to do to tables unless you drop the tables and start again.   There are changes to the portal that make improvements in this version so you may want to re-download this now and apply these.   Better (safer) integration with TinyMCE and who’s online allowing viewing of profiles are both in this, along with an updated install.md that adds another php module that’s needed.

PLEASE NOTE:

A few bugs have been found in the code, some things missed (database tables with a missing column), default images missing from /themes/default/.    I believe this have all now been fixed now so I have replaced the download package with this new one.

I have removed the other partial downloads as they will be regressions now.  Please download just this new version for now.  You can install this over the top of your existing one (take a copy of your config.php first).    Please check for the extra column in tables as below:

SELECT TABLE_NAME, COLUMN_NAME
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
AND TABLE_NAME IN (‘portal_news’, ‘portal_events’, ‘portal_pages’)
AND COLUMN_NAME = ‘is_html’;

That will let you know if any of them actaully already have the is_html (you dont want to add the column if you already have it!). Assuming none of them have it yet – these alter tables should get you going without having to drop all your portal tables (for completness I DID drop all my portal_* tables just to be sure but alter table should work fine too).

ALTER TABLE `portal_news`
ADD COLUMN `is_html` TINYINT(1) NOT NULL DEFAULT 0 COMMENT ‘True if body is TinyMCE-produced HTML, false for plain text’ AFTER `updated_at`;

ALTER TABLE `portal_events`
ADD COLUMN `is_html` TINYINT(1) NOT NULL DEFAULT 0 COMMENT ‘True if description is TinyMCE-produced HTML, false for plain text’ AFTER `created_at`;

ALTER TABLE `portal_pages`
ADD COLUMN `is_html` TINYINT(1) NOT NULL DEFAULT 1 COMMENT ‘True if content is TinyMCE-produced HTML, false for plain text’ AFTER `updated_by`;

That should alter your tables to make sure that is_html is in the tables. You CAN take the check out for that – but the reason for it is to protect against injection attacks.