Forum OpenACS Development: Towards OpenACS 5.9.1

Collapse
Posted by Gustaf Neumann on
Dear All,

we have on the OpenACS 5.9.1 agenda [1] aside of other things a cleanup
of the .xql-file (remove unused/duplicated queries, strip misleading
SQL statements from the source, drop unused .xql files) and a better
plugin structure for richtext editors (see also [2]).

Over the holidays, i did some work concerning the .xql file (mostly
the acs-* packages on the oacs-5-9 branch). As a result, i've deleted
36 completely useless .xql files and made numerous changes to these
files. Also a couple of -oracle.xql queries were missing, etc.)

The other largish change are the richtext editor plugins. This change
become necessary, since the Debian packager does not allow
e.g. minified .css or .js files, and there were more than 1300 complaints
from lintian. Now there are three new packages

- richtext-xinha
- richtext-tinymce
- richtext-ckeditor4

and a new interface to
a) register richtext editor plugins
b) initialize richtext widgets per usage
c) perform setup tasks for all richtext widgets in one step

As a consequence the integration interface is now much easier and the
per-editor hacks from the blank-master.tcl are gone. The functionality
of the integration has not changed. The CKEditor 4 integration is
still via CDN, but it is now much easier to switch to a local
configuration when needed. Also, the dependency management is now
easier, since the editors have version OpenACS version numbers.

The package parameters in acs-templating for the richtext editors
(TinyMCEDefaultConfig and XinhaDefaultPlugins) are now in the new
packages, but i have not deleted these yet from acs-templating
to ease migration.

The new code (and the most recent version from the oacs-5-9 branch)
is running already on OpenACS.org

In case you are using the editors, it would be a good time now to
make a quick test if everything is still working fine for you.

Is still anyone using htmlarea? The last change on this code was
done 2005, so it is probably not working anymore.

All the best in the new year
-g

[1] https://openacs.org/xowiki/openacs-todo
[2] https://openacs.org/forums/message-view?message_id=4868684

Collapse
2: Re: Towards OpenACS 5.9.1 (response to 1)
Posted by Paul Babin on
Just curious about the -richtext-packages - those appear to have been deleted - we like the new editors but need to add custom configurations.
Collapse
3: Re: Towards OpenACS 5.9.1 (response to 2)
Posted by Gustaf Neumann on
Dear Paul,

The *-richtext editors are in the oacs-5-9 branch (and referenced by the interface-code in acs-templating in oacs-5-9). When new files are added to a non-head branch in CVS, the fisheye browser shows this somehow strangely by adding the same files marked as deleted to the HEAD branch. Note, that the current development is in the oacs-5-9 branch [1].

With the new *-richtext packages and the standardized interaction, it is easier to (a) add/remove editors, (b) to switch between editors and (c) add local modifications without boating acs-templating and without running into problems with (debian) packaging.

all the best
-g
[1] http://www.openacs.org/xowiki/openacs-todo

Collapse
4: Re: Towards OpenACS 5.9.1 (response to 1)
Posted by Gustaf Neumann on
In the development of OpenACS 5.9.1, many changes in the oacs-5-9 branch are the result of vulnerability scanning with tools like acunetix. In particular, many of the demo scripts at openacs.org had serious security issues. Note that an attitude "these are just demo programs" is bad, since the demo programs are as well available per default on every OpenACS site, therefore these vulnerabilities are affecting these sites as well.

Since a vulnerability scanner fires typically 100-200 valid and invalid requests per second for multiple days to the web-site, many little errors and insufficient error handling show up during these runs. Therefore, i've further cleaned up the applications used at openacs.org.

One nice consequence is that the number of errors in the error.log was reduced significantly. During the last week, only a single error message showed up in the error.log in the last week, where we have about 1/second in the year average (orange line). Also the warnings were reduced by a factor of 40 (compare avg values of year char vs. week chart). Note that the scales of the carts are logarithmic.

Week statistics of entries in error.log 2016-07-26:


Year statistics of entries in error.log 2016-07-26:

Graphics are generated with the munin-plugins from [1]
https://github.com/gustafn/munin-plugins-ns