Forum OpenACS Q&A: Re: Don't understand "big picture" of what to do

Collapse
Posted by Torben Brosten on
An installation is capable of any purpose, demo, admin or developer tool etc.

The application code is in /packages

For upgrading purposes, it's best to think ahead. Put static files in /www/resources or somewhere in the /www file hierarchy and put new procedures etc in their own files. This way, when updating, you are not overwriting your customizations (as much).

A general rule for extending tables is to create your own tables and use a common reference from the existing one, such as object_id to join them via queries. This way, any modifications you make are unlikely to be affected by changes to the core system. There are advanced CMS db features available via the object database such as revisioning etc, but those features are not fault tolerant if used in a nonstandard way. It's best to have a test system running to implement changes you aren't sure about their impacts to the system. It's good experience to build the test site from a backup of the live site to verify your backup procedures work. Always make a backup before changes so you can revert if need be.

cheers,
Torben