Search · Index


Showing 1 - 10 of 823 Postings (summary)

Naming Conventions

Created by Rocael Hernández Rizzardini, last modified by Gustaf Neumann 21 Jun 2016, at 08:59 AM


  • Use always is lowercase: file.tcl
  • Separate names with dash “-“:  my-file.tcl
  • Use English as your for your naming (at least if you plan to contribute to the community)
  • Put generic names, such as:
    • my-page-add-edit.tcl
    • my-page-delete.tcl
    • index.tcl
  • Follow the object-action naming convention
    • my-page-delete.tcl
    • NOT delete-my-page.tcl

Procedures (Tcl functions)

  • Usually in lowercase (only in proc callbacks or service contracts you will use TheFirstLetterOfEachWord as uppercase)
  • Separate words with “_”: my_proc
  • Use names that indicates what the procs does, usually not too long
    • my_package::user::add_to_class
  • Always use namespaces
    • The namespace must be the same as the package-key, just that with “_” if applies
      • If package-key is: my-package
      • Then: my_package::add_user
    • Follow the package_key::object::action convention, use
      • my_package::user::add_to_class
      • NOT my_package::add_to_class::user
    • If you have only one action on users you might also use:
      • my_package::add_user_to_class

SQL Statements

  • Lowercase
  • Seperate words with "_": select_users_in_class
  • Use names that indicate what the SQL statement does, or what it returns
    • db_list list_of_unregistered_user_ids {}
    • db_1row user_info {}
    • db_dml update_user_biography {}
  • Preferrably, in db_multirow calls, keep your statement name the same as the multirow name
  • For PL/SQL look here

SQL constraints 

  • Read the document behind the link
  • All constraints have to be named
  • The naming convention for constraints are as follows:
    • Primary Key: tablename_pk (acs_mail_lite_queue_pk)
    • Unique: tablename_columnname1_columnname2_un
    • Foreign Key: tablename_columnname_fk ( acs_mail_lite_queue_pck_fk)
    • Check:  tablename_column_name_ck (acs_mail_lite_co_qu_use_sender_p_ck)
  • Column names can be abbreviated (e.g. pck instead of package_id)


  • Lowercase
  • Seperate words with "_": user_id
  • Use names that indicate what the variable contains. If this matches with a database column, use the same name as used for the column in the database.
  • Use the following conventions for variables containing
    • IDs: Append "_id" at the end, like "user_id"
    • Booleans: Append "_p" at the end, like "employee_p" to define if the user is an employee
    • Arrays: Append "_arr" at the end, like "employee_arr". This way you can immediately detect arrays in the code. 

Package Parameters

  • Use camel case, start with uppercase character
  • Example "IndexRedirectUrl"

Get the Code!

Created by roc@, last modified by Gustaf Neumann 17 Jun 2016, at 11:52 AM

This are instructions to obtain OpenACS, either as a released distribution (a .tar.gz file) or from CVS.

Obtain a released version of OpenACS via .tar file:

Download from

Unpack the OpenACS tarball. Usually something like this works:

tar zxvf openacs-5.9.0.tgz

Obtain OpenACS from CVS (a certain release with potential patches, or the HEAD version):

If you want to track fresh code developments between releases, or you are an OpenACS core developer, you may want to install from CVS. This is identical to downloading a distribution, except that you get the files from CVS instead of the tarball. The following commands are used to obtain the newest version of the OpenACS 5.9 branch from CVS:

cvs login
# press enter for password
cvs checkout -r oacs-5-9 acs-core 



The command above checks out the core packages of OpenACS in a directory named openacs-4. For  the entire OpenACS version 5.9 branch you can use the following commands (adjust as required going forward):



cvs checkout -r oacs-5-9 openacs-4


If the the branch name (like oacs-5-9) is omitted, the the leading edge developer version (the HEAD release) is obtained

cvs checkout openacs-4



In order to check out a single package (e.g. the package cronjob) from  e.g. the leading edge developer version (HEAD), use 

cvs checkout openacs-4/packages/cronjob

For most OpenACS packages, CVS aliases are defined. In order to checkout e.g. the forums package from OpenACS 5.5, just use:

cvs checkout -r oacs-5-9 forums

 More info here:

Looking for README instructions or installers? View the OpenACS Installation instructions: en:openacs-system-install, otherwise continue by setting up the OpenACS distribution:

Set up the file system for one or more OpenACS sites

For Linux Standard Base compliance and ease of backup, all of the files in each OpenACS site are stored in a subdirectory of /var/lib/aolserver, one subdirectory (SERVERROOT) per site (see: en:openacs-reference-platform). The first time you install an OpenACS site on a server, you must create the parent directory and set its permissions:

While logged in as root:

mkdir -p /var/lib/aolserver
chgrp web /var/lib/aolserver
chmod 770 /var/lib/aolserver

Move the uncompressed code to SERVERROOT and rename the directory to $OPENACS_SERVICE_NAME:

mv openacs-4 /var/lib/aolserver/$OPENACS_SERVICE_NAME

Developer Tutorial - Req.

Created by OpenACS community, last modified by maria katosvich 14 Jun 2016, at 11:49 AM

Documentation Requirements for Developer Tutorials

By the OpenACS Community. This section is a collection of documentation requirements that have been expressed in the OpenACS forums to 4th July 2003.

OpenACS developer tutorial documentation should meet the following requirements. No significance has been given to the order presented, topic breadth or depth here.

  • list learning prerequisites to customize, fix, and improve OACS modules, and create new ones. You are expected to have read and understand the information [minimum requirements similar to adept at Using OpenACS Administrating Guide] before reading this guide.

  • Refer to development documentation instead of duplicating here

  • List suggestions for installing and setting up a development environment; these can be annotated links to the installation documentation

  • Provide working examples that highlight the various subsystems, tcl environment, OpenACS protocols, aolserver template and ns_* commands, OpenACS templating, sql queries, db triggers, scheduling protocols, how to use the page contact, how to get the accessing user_id etc

  • Show how to construct basic SQL queries using the db API,

  • The life of an http request to a dynamic, templated page

  • General rules to follow for stability, scalability

  • Show the step by step customizing of an existing package that meets current recommended coding styles of OpenACS package development, by referring to developer resources.

  • Use the ArsDigita problem sets and "what Lars produced for ACS Java" as inspiration for a PostgreSQL equivalent tutorial about developing a new OpenACS package including discussion of the significance of the package documentation templates

  • Include a summary of important links used by developers

  • Note any deprecated tools and methods by linking to prior versions instead of describing them in current docs

OpenACS Reference Platform

Created by OpenACS community, last modified by maria katosvich 13 Jun 2016, at 01:24 PM

These are the defaults we create and use during the standard installation process, in helper scripts and other places. None of these locations are set in stone - they're simply the values that we've chosen.

Default directories for a standard install

Fully qualified domain name of your server yourserver.test
name of administrative access account remadmin
OpenACS service service0
OpenACS service account service0
OpenACS database name service0
SERVERROOT - base of the OpenACS service file tree /var/lib/aolserver/service0
Location of source code tarballs for new software /var/tmp
The OpenACS tarball contains some files which are useful while setting up other software. Those files are located at: /var/lib/aolserver/service0/packages/acs-core-docs/www/files
Database backup directory /var/lib/aolserver/service0/database-backup
Service config files /var/lib/aolserver/service0/etc
Service log files /var/lib/aolserver/service0/log
Base compile directory /usr/local/src
PostgreSQL directory /usr/local/pgsql
AOLserver directory /usr/local/aolserver

Some instructions provide cut and paste conveniences

In order for some copy and paste instructions to work in your bash shell, you must set the environment variable $OPENACS_SERVICE_NAME. Add this line to your .bashrc or .profile_bash file to set the environment variable for a specific user:

export OPENACS_SERVICE_NAME=service0

To set it globally so that it works for any new users or special service users you may create, add the above line to the file /etc/profile

$OPENACS_SERVICE_NAME is set to the value of service0 on a default install. Change service0 to a word that better represents your project. The other values we recommend you leave unchanged unless you have a reason to change them.

A service name ($OPENACS_SERVICE_NAME) should be a single word, letters and numbers only. If the name of your site is one word, that would be a good choice. For example "$OPENACS_SERVICE_NAME" might be the service name for the website.

Some discussion that lead to these default values:

Creating box tags for consistent html/css

Created by openacs community, last modified by maria katosvich 10 Jun 2016, at 10:13 AM

Box Tag Code:

# The box tag is intended to make the markup around a "box"
# standard sitewide so that you can use the same css everywhere to   
# style the site.

template_tag box { chunk params } {

    set class [ns_set iget $params class]

    if {[template::util::is_nil class]} {

        set class box


    set id [ns_set iget $params id]

    if {![template::util::is_nil id]} {

        set id " id=\\\"$id\\\""


    template::adp_append_code "append __adp_output \"<div class=\\\"$class\\\"$id><div class=\\\"boxTop\\\"></div><div class=\\\"boxContent\\\">\""

    template::adp_compile_chunk $chunk

    template::adp_append_code "append __adp_output {</div><div class=\"boxBottom\"></div></div>}"



Created by Maurizio Martignano, last modified by Maurizio Martignano 31 May 2016, at 03:23 PM

Windows-OpenACS (vers. 3.1.0 - June 2016) is a  Windows 64 port of OpenACS 5.9.0 and the latest snapshot of Naviserver and is available here.

This port installs and runs on the following systems: Windows 8.1, Windows 10, Windows Server 2012 R2 and Windows Server 2016 TP.



Created by Dave Bauer, last modified by Gustaf Neumann 31 May 2016, at 09:21 AM

Release Status

See openacs-release-status

Development is taking place in the oacs-5.9 branch.

OpenACS Version 5.9.1 agenda/wish list

  • Refactoring of rich-text editor integration
    • Driving force: Debian packaging
    • we have now the new packages
      • richtext-xinha
      • richtext-tinymce
      • richtext-ckeditor4
  • SQL:
    • Further cleanup of .xql files (like what as done for acs-subsite in 5.9.0)
      • so far, 36 files deleted
      • removed more than 100 obsolete named queries
      • stripped misleading SQL statements
    • Mark redundant / uncalled sql functions as deprecated
    • Simplify core sql functions by using defaults
      • Number of functions reduced by a factor of 2 compared to OpenACS 5.9.0 (while providing compatibility for clients using old versions),
      • reduced code redundancy
      • Affected functions:
        • reduced content_item__new from 12 versions to 6,
        • reduce content_revision__new from 7 to 4
        • similar in image__new, image__new_revision, content_item__copy, content_item__get_title, content_item__move
    • PG 9.5 supports named parameter in the same syntax as in Oracle. Further reduction of variants will be possible, once OpenACS requires at least pg 9.5
    • Modernize SQL
      • use real Boolean types instead of character(1)
        (done for new-portal, forums, faq, attachments, categories, dotlrn, dotlrn-forums, evaluation)
      • use real enumeration types rather than check constraints (done for storage type text/file/lob)
  • CR hygienics (reduce cr bloat)
    • Provide means to avoid insert/update/delete operations in the search queue: OpenACS adds for every new revision often multiple entries to the search_queue, without providing any means to prevent this. This requires for busy sites very short intervals between queue sweeps (otherwise too many entries pile up). Another consequence is that this behavior keeps the PostgreSQL auto-vacuum daemons permanently active. Many of these operations are useless in cases where the content repository is used for content that should not be provided via search. The changed behavior should honors a publish-date set to the future, since it will not add any content with future publish dates to the search-queue.
    • Insert into cr_child_rels just when needed. cr_child_rels provide only little benefit (allow to use roles in a child-rel), but the common operation is a well available in cr_items via the parent_id. cr_child_rels do not help for recursive queries either. One option would be to add an additional argument for content_item__new to omit child-rel creation (default is old behavior) and adapt the other cases.
  • Security improvements:
    • improve protection against XSS and SQL-injection
    • add support against CSRF (cross site request forgery)
  • Final cleanup of permissions:
    • Get rid of acs_object_context_index on pg: huge table,
    • expensive maintenance, used only in a few places,
    • used as well by Oracle (effort has to be determined)
  • Data bloat hygiene:
    • rethink package parameter and portlet parameter data models
  • registry for .js and .css libaries: allow besides classical urls symbolic names for loading external resources (e.g. jquery), this would make it easier to upgrade  libraries in multiple packages (without running into problems with duplicate versions) or switching between CDN and local paths
  • say farewell to CVS

OpenACS Version 5.9.0 Agenda

  • Slimming pg SQL core:
    • Part 1: improve performance of object deletion
      • remove manual delete operations from acs_object__delete()
    • Part 2: content-repository - manual referential integrity management
      • handle referential integrity via pg's integrity constraints rather by functions cr_revision_del_ri_tr, cr_revision_ins_ri_tr, cr_revision_up_ri_tr, cr_revision_del_rev_ri_tr, and cr_revision_del_rev_ri_tr
      • fix broken/missing upgrade scripts from earlier updates
    • Part 3: content-repository - manual deletions and nulling
      • Removed manual nulling of live_revision and latest_revision
      • Removed manual deletion of old_revision and new_revision in cr_item_publish_audit
      • Removed manual deletion of item_id in cr_item_publish_audit, cr_release_periods, cr_item_template_map, and cr_item_keyword_map
      • Removed manual deletion of direct permissions
      • Added missing index for child_id to cr_child_rels.
    • Part 4: get rid of tree_sortkey in acs-objects
      • Check/fix dependencies in oacs-5-8 packages
      • Get rid of broken/uncalled functions using the column
      • Check/fix dependencies in other packages
      • Remove tree_sortkey and max_child_sortkey
  • Web interface:
    • Improve client performance
      • moving core.js from head to body
      • provide kernel parameter to control expiration date for /resources/
    • Protect against more XSS attacks
    • Improved HTML validity (see oacs-5-9-html-validity for the checklist)
    • Add lightweight support for ckeditor4 for templating::richtext widget (configurable via package parameter "RichTextEditor" of acs-templating. ckeditor4 supports mobile devices (such as iPad, ...).
    • New kernel parameter ResourcesExpireInterval to control expiration dates of resources
  • Templating:
    • Improve theme-ability
      • Move more information into theme packages in order to create responsive designs
      • Reduce hard-coding of paths, HTML etc.
    • Dimensional slider reform (ad_dimensional):
      • Remove hard-coded table layout from dimensional slider
      • Add backwards compatible templates
      • Move hard-coded styles into theme styling
      • Remove obsolete comments from ad_dimensional
    • Complete template variable controls (adding noi18n, addressing bug #2692):
      • @foo@: perform html quoting and internationalization
      • @foo;noquote@: perform internationalization
      • @foo;noi18n@: perform html quoting
      • @foo;literal@: perform neither html quoting nor internationalization
    • Improved Russian nationalization
    • Support of expiration dates and passwords for signed variables
  • Documentation:
    • Use ACS templating for the (static) OpenACS documentation to provide a more consistent layout and user experience.
    • Make pretty-naming of acs-core packages more consistent.
  • Misc improvements:
    • Mark unused functions of acs-tcl/tcl/table-display-procs.tcl as deprecated
    • Reduce number of muxtex locks by pre-request and per-thread caching
    • Improved development und debugging aids:
      • use "ad_log error|warning  .... " instead of "ns_log" to include information of request and callstack in error.log
      • ability to display ns_log entries caused by a request in ds-footer
      • ability to save delivered web pages in file-system for testing HTML validity (especially for admin pages, which are unaccessible for external validity testers)
    • More bug fixes
  • Version numbers:
    * require PG 9.0 (End Of Life of PostgreSQL 8.4 was July 2014)
    * require XOTcl 2.0 (presented at the Tcl conference in 2011).

OpenACS Version 5.8 Agenda

  • PostgreSQL 9.2+:
    • Get rid of nonstandard backslash escapes in function definitions
    • Change quote syntax in sql files (single quotes around the functions) to recommended PostgreSQL quoting using (recommended since pg8.0, jan 2005). li>Drop aliases in favor of named function arguments (recommended since pg8.0)
    • Fix wrong function_args, add missing function_args, align default semantics with the defaults in pg (providing "null" as default means the argument is optional)
    • Make OpenACS loadable without any tweaks in the pg config files
  • Use recursive queries for e.g. permission lookup to avoid performance problems in pg 8.4 and newer)
  • ADP: Use byte-compiled function wherever possible in compiled adp-code, support "@var;literal@" when neither quotes nor localization is needed in compiled adp-code
  • Improve support of NaviServer
  • Switch to Tcl 8.5 (TIP #143)
  • Improve scalability: Reduce mutex-stress on util-memoize cache and for cache maintenance in general
  • Code cleanup:
    • Get rid of calls to deprecated code (e.g. ad_tables, ad_parameter, ... in acs-core and main packages)
    • Improve awareness of usage of deprecated code (complain to error.log)
    • Use Tcl 8.5 idioms
    • cleanup of various http-client approaches and introduce a common implementation util::http::get and util::http::post; get rid of other usages, mark these as deprecated
    • page-contracts: Perform checking of all ids in acs-core and main packages to improve error messages and to improve security
  • OpenACS 5.8.1 should be released with main packages

OpenACS Version 5.7 Agenda

  • Support for object management in core 
  • Postgresql 9.0
  • TinyMCE update (fix for random JS injection issue, affecting Safari)
  • Fix for "remember me" issue
  • WCAG2-AA

OpenACS Version 5.6 Agenda

  • global parameters
  • package "embeds" 
  • fix search by package_id
  • core works on Postgresql 8.4

OpenACS Version 5.5 Agenda

  • DONE: Postgresql 8.3 support: especially regarding tsearch2
  • DONE: acs-authentication:
    • fix upgrade, add conditional logic into site wide tcl library so that you can login to perform the rest of the upgrade
  • DONE: tinymce:
    • upgrade to 3.1.1 + language packs
    • HTML Strict cleanup
    • create appropriate parameters for its config in acs-templating
  • acs-mail-lite:
    • DONE: cleanup duplicated procs (bounce)
    • review the parsing of bouncing messages (case user_id 0)
    • DONE: rollout support
  • Documentation improvements as discussed at the Guatemala conference:
    • Make current source for static files included in the release and provide ease means to achieve this for the release manager
      • DONE (CVS HEAD): Provide in XoWiki an alternative table of contents by nested UL/LI (without JavaScript) for static output
      • DONE (CVS HEAD): Provide in XoWiki a prototype page similar to "book" without edit-buttons etc., using the new table of contents
    • Update where necessary (incomplete list):
      • DONE: Fix the page ordering for the higher chapters (the original document  had no 3rd. level numbering)
      • update pages in /test-doc which are more recent in openacs/xowiki
      • bump version numbers of OpenACS, where appropriate (some places talk about openacs-5-0, others about openacs-5-1, oacs-5-2-3rc1 or 5-3) 
      • some version numbers of the required components are quite a mess. e.g. some parts say that Postgres 7.3 is required,  some examples talks about postgres 7.4.7 and 8.2.4 in the same listing.
      • also the dotlrn version numbers are old dotrln-2.0
      • Tcl version numbers should be 8.4.19
      • The install section for XOTcl is missing in II.3.4
      • remove ChangeLog from documentation
      • find some other prominent place for the ChangeLog
      • Fix indenting in examples  (e.g. in Rocael's robust web    development framework)
      • overthink Win2000 guidelines.  There are the native compiled packages from Maurizio, including everything from postgres, xotcl ....
    • It is desired to find a single person responsible for overworking the documentation, however, funding is unclear.

OpenACS Version 5.4 Agenda

  • DONE: HTML Strict (openacs core)
  • DONE: finish template::head (daveb)
  • DONE: test acs-mail-lite (complex send)
  • DONE: test notifications (complex send)
  • DONE: new XinHA release, get rid of RTE & HTMLarea, test on Safari
  • DONE: Form builder: add the ID attribute  to the form tag
  • DONE: acs-lang - keepLocalTranslationP to be removed
  • DONE search and intermedia-driver: move intermedia specific stuff to its package
  • DONE: acs-mail-lite - patch for mime::qp_encode bug


  • Split Xinha and TinyMCE into seperate packages see:
  • Usability ("my account" page)
  • XHTML ?
  • Testing and documentation for recording automated tests using the firefox plugin and the upload feature for it new in automated testing. Probably needs some polishing and should be talked to with Quest who are getting into this.
  • Parameter Scope Patch 
  • Remove obsolete master template stuff (default and site master template in openacs-4/www, acs-subsite's group-master, and related CSS and images).  Probably in the version which follows 5.5 (probably 5.6).  Also remove the compat master stuff at the same time.

Things to merge into this page

Old 5.0 Roadmap  discussion 

Roadmap discussion 1 

 [Ideas for Boston 2006 Future of OpenACS discussion]

My previous attempt at collaborative roadmap 

A .LRN Roadmap 

Another .LRN Roadmap discussion 


What's on this page?

This page should include work that is planned on and has someone comitted to working on it.

Migration from CVS to GIT

Created by Victor Guerra, last modified by Gustaf Neumann 28 Apr 2016, at 09:07 AM

IMPORTANT!!! by no means the statements written in this page are official. At the moment one should consider this information just and only for experimental purposes. There are no official decisions made by the OCT so far regarding migration to GIT or any other source control tool.  At the moment CVS is the official tool used and you can navigate the project history and code at our official code and history inspector Fisheye OpenACS

Tools to consider for the migration:

  • GIT includes a tool for the migration of CVS repositories called git-cvsimport.
  • The cvs2svn project provides support for converting a CVS repository into GIT. The tool is called cvs2git

Structure of the GIT Repository:

  • One git repository hosting the entire code base of OpenACS (including contrib and all packages) vs. multiple repositories (provide separate git repositories managed via modules/subdirs/...)
  • A single large repository seems not realistic, since many sites have site-speciifc modules, since there projects like ProjectOpen and others having developed a long range of maintained packages. But are 300+ separate repositories manageable with reasonable effort (maybe mr is currently the best option, we have good experiences with this). However, this decision has large impact on tagging and release management (see below)

Where could the repositories live (?):

  • Official repositories on machine? (Perhaps setting up  and having remote-mirrored repositories on github so developers can clone and share patches using github. -- jiml: many tools which could get similar function to github (forking, pull requests),,, what would be required to get a  can we put up a gitorious on a test site with maybe 50gb of repo space so all the committers can have their own?
  • Using as our official source code site? or Bitbucket?

Points to consider before | when migrating to GIT: 

  • Release-management: Installing-software-from-repository code is based on release "channels" and cvs-tags in order to define which channels are available to users ( and to provide the recent packages for that channel.  In principal, similar tags could be used as well in git, but there are several differences. CVS tags are per file, git tags are per repository (if the git repository contains e.g. all packages, there is no way to tag a single package as e.g. OpenACS 5.9 compatible with e.g. tag "openacs-5-9-compat"). It is possible to work with separate git repositories and work with git modules and/or subtrees, but this means that we have 300 repos to manage (all could have separate branches and tags), and single commits covering multiple repos are not supported). This means, that one needs higher level tools and recommended workflows to manage developments on the core source repositories (branches, tags) and site-specific packages and local modification as well as site-specific release and feature branches
  • Depending on the decision of the structure it is necessary to provide git-guidelines similar to cvs-guidelines  and the code retrieving and generating .apm packages has to be rewritten.
  • Application for voting on oct-elections depends on commits history ( most likely this will transparent since we use  for fetching information about commit history, and fisheye provides one and one only interface for querying data, so the fact that the code is being controlled by cvs or git is irrelevant ... but since fisheye is configured for CVS, it has to be newly built for the resulting infrastructure, or it has to be dropped/replaced by github/bitbucket or others.

Current state:

  • Since 2014 Victor Guerra (Vienna University of Economics) has created an unofficial mirror on github  which contains a daily mirror of the CVS repositories at It consists of an openacs-core modules plus a separate repository for every non-core package.

OpenACS/dotLRN Windows Installer Instructions

Created by Byron Linares, last modified by Gustaf Neumann 20 Apr 2016, at 10:52 AM

NOTE: Currently (04/2016), the best option to get OpenACS 5.9.* running on Windows is to use the native windows installation Windows-OpenACS by Spazio IT (Maurizio Martignano).

This page describes the installation of (quite old) components based on cygwin, but might still be useful for people, that can't use Maurizio's implementation for whatever reason:

  • OpenACS 5.2.3
  • DotLRN 2.2.0

Included Software

  • AOLServer 4.0.beta10_2003
  • PostgresSQL 7.4.3
  • OpenACS 5.2.3
  • DotLrn 2.2.0
  • Cygwin

Installer Download :

The installer is available in openacs community page.
Available versions:

  • OpenACS/dotLRN installer
  • OpenACS 5.2.0 installer

Installation Instructions:

Run the "OpenACS/DotLRN Installer" called setup.exe, read the license document before continuing, the installer will ask for some information, this will be used to make the automatic installation.

There are to ways to install the components; manually or automatic


  • dotLRN Manual and openACS Manual:
  • In this modality the entered personal data in the installer will be omitted and will be necessary to retake the installation from a browser window and enter the necessary data to continue the creation of the data modeling.
  • dotLRN Automatic and openACS Automatic
  • In this modality the installer its in charge of all the work, when finishing creating the data model the following step would be to reinitiate the service and continue with the use of the platform.
  • Source Code:
  • The installer will put in the installation folder the source code of the same one.

Select what you want to install and click next. After the installer places all the files, a browser window will be opened and the installation have to be continued from here, if the automatic mode has been selected wait to the installation finishes. When the installation finishes restart the server and type in a web browser "http://localhost"

 Access Icons:

  • OpenACS on the web: access to http://localhost/
  • Start Server: Bach file to initiate the server (aolserver, postgresql, cygwim)
  • Stop Server: Bach file to stop the server (aolserver, postgresql, cygwin)
  • Unistall OpenACS: Uninstall all


  • Check if CygWin: Please execute the file server/cygwin/cygwin.bat.  You should get a black screen with some green text saying: "yourusername@yourcomputer" and the "$".
  • Check PostgreSQL: in the cygwin window typy psql -l , You should get the names of all data base.
  • Check AOLServer: ps -alW | grep nsd , You should get some thing like this
  • 2312 0 0 2312 ? 0 07:52:20 C:\OpenACS\nsd4\bin\nsd.exe

Full guide



developed at the Galileo University ( by Byron Haroldo Linares Roman as part of the E-LANE project (



related forum threads

OpenACS/dotLRN installer for MSWindows


Created by Michael Aram, last modified by Gustaf Neumann 12 Apr 2016, at 10:39 AM

hstore  is a postgresql module, which is used optionally by newer versions of xowiki and xowf (xowiki content flow ) to provide quick access to the "instance_attributes" (the per-form or per-workflow attributes not part of the native content repository data model). The supporting functions (creating indices, etc) are currently mostly part of the xowiki sources (earlier: xowf).

Under Ubuntu, you can install hstore via:

    psql -d <yourdb> -tAc "create extension hstore"

You can then verify the successful installation on the ds/shell using:


Next Page
Previous Month June 2016
Sun Mon Tue Wed Thu Fri Sat
29 30 31 1 2 3 4
5 6 7 8 9 (1) 10 11
12 (1) 13 (1) 14 15 16 (1) 17 18
19 20 (1) 21 22 23 24 25
26 27 28 29 30 1 2

Popular tags

17 , ad_form , ADP , ajax , aolserver , asynchronous , bgdelivery , bugtracker , CentOS , COMET , cvs , debian , emacs , fedora , FreeBSD , hstore , includelets , install , installation , installers , install-ns , javascript , libthread , linux , monitoring , munin , NaviServer , nginx , nx , oacs-5-8
No registered users in community xowiki
in last 30 minutes