OSGeo Portal Site

This page documents issues, policies and plans with regard to the evolving OSGeo Portal front end.

= Portal Site = The OSGeo Portal site contains stable documents and lives at http://www.osgeo.org/ and is managed by WebCom. This Wiki is the place to collaborate on new documents, refine and revisit existing policies. Once approved they become stable and migrate to the Portal Site where they are translated and maintained using the Portal Translation Status page.

LDAP and membership

 * A mechanism for new users to join the web site and for this to update the LDAP backend database is currently being set up. This work is integrated with the Membership Application project.

= Policies = The portal site is hosted by a professional provider. The Infrastructure Transition Plan and Migration Documentation details the installation. CSS file access, patches, LDAP connectivity and lower level system administration are amanged by SAC.
 * WebCom is responisible for the content, and content management policy.
 * SAC is responsible for maintaining the software, and host system.

CMS Permissions
The role defines what a user is allowed to do and what she gets to see. WebCom votes for users to get roles.

admins
Users with role "admins" can check permissions when logged in.
 * "admins" can create (currently only local - yuck) users, configure all modules that are installed, edit all settings and perform all operations.

anonymous user

 * "anonymous users" can read pages, this is the public, unrestricted view.

authenticated user

 * can look at other user pages
 * can see pre-releases
 * can create "own events", what is that, do we want that?

project manager

 * "project managers" can create pages and add content but cannot change the structure, layout and cannot activate or take away modules. All members of VisCom should have this role for the VisCom "instance", "pages" or "sections".

translator

 * "translators" are somewhat more resticted in creating new items than project managers are but they can access the translation tools.

All roles can be combined and adding functionality up. If you are intersted in translating content please read the description on OSGeo Portal Translations and contact WebCom.

Editing Site Themes
OSGeo website themes are managed through SVN. Any changes to the themes must first be done through SVN and then a user with adequate permissions must do an update on the test and primary servers. SVN checkout is available to anonymous but commits are done through privileged user accounts. Here is the command for checking out the themes from SVN:
 * svn co http://svn.osgeo.org/osgeo/webcom/themes

When a change is ready to be tested, do an update on the test.osgeo.net server. When it is ready do an update on the primary server: cd /var/www/html/themes sudo svn update

= Troubleshooting = When going to http://www.osgeo.org/admin/ you may see various errors listed there. Most of them are usually just page not found errors for whatever reason. But sometimes the error shows that something is broke and needs fixing or refreshing. Here are a couple of them and ways to fix them.

Table 'search_dataset' is marked as crashed and should be repaired
sudo mysql -u root \r osgeo_drupal repair table search_dataset
 * Don't ask me how MySQL lets a table "crash", but the fix is easy, so easy you'll wonder why the database can't do it itself. Log into the database and run the commands like so:

Last cron run did not complete.

 * This may be related to the above error about tables going stale, but has appeared on its own as well. We have a cron job that regularly runs the cron.php page.  This page updates the search indexes and does some other housekeeping.  The fact that it has been failing, and that some table has had problems, is not surprising.
 * Some settings are here, including a re-indexing option and some cron settings: http://www.osgeo.org/admin/settings/search
 * cron failures are largely due to errors in some module or from memory limitations. Debugging this can be a real pain.  Basically you have to know which modules you recently turned on, then turn it off, re-run cron.php (from command line on the server itself), then check the admin log again.  Or increase memory and try again.
 * To fix it the last time, I increased php memory options from 16MB to 32MB and it seems to work fine now.