Foswiki-2.1.9 is now available for download! We are delighted to announce the new release, which includes 57 significant bug fixes compared to the previous 2.1.8 version. This update addresses a range of important issues and enhances the overall stability and performance.

Optimizing Storage Performance

This release focuses on performance optimization, building upon Foswiki's historical struggles with disk I/O bottlenecks. Traditionally, for each request, the engine would access multiple files to compile the necessary objects required to render a wiki page. This was particularly true for preference settings and access control rights, which often necessitated loading complex combinations of objects. To address this issue, extensive profiling has been conducted to identify areas where time can be shaved off. Notably, our analysis reveals that we have a performance window between 300ms and 1 second in which to make further optimizations, allowing us to fine-tune the engine's efficiency.

Optimizing renaming/deleting webs

In large wikis renaming/deleting webs takes forever with the web-server's connection to the Foswiki backend timing out. This was caused by the system iterating over all of the wiki for all of the topics contained in the web to be renamed. In most cases this type of rewriting links isn't required or even desirable.

Optimizing loading CSS, JavaScript and I18n files

A significant contributor to slow page loading times is the sheer volume of assets being loaded. Each wiki page may require a unique set of CSS and JavaScript files, which can be substantial in number. However, there are common core functionalities that need to be loaded on every page, while additional assets might be required only for specific cases. To address this, Foswiki now allows for the predefinition of this core set of assets, which can then be compiled into a single combined chunk. This approach reduces the number of parallel HTTP requests needed to load a page, resulting in improved performance.

Get started with Foswiki today!

Tags: features, performance

We are very pleased to announce the availability of Foswiki 2.1.8. This release contains 61 fixes relative to 2.1.7, including 9 critical security related fixes.

Most notable are:

• CVE-2023-33756: SpreadSheetPlugin's EVAL feature exposes information about paths and files on the server
• CVE-2023-24698: Local file inclusion vulnerability in viewfile

But also:

• directories in working directory are created as world writable 777 permissions
• possible XSS attack in attachment comments
• restricted allowed protocols to http and https, i.e. forbid file protocol for local file inclusion
• prevent symlink attacks by defaulting to a secure location for temporary files
• update to jquery-ui 1.13.2
• backport patch to earlier jQuery versons to fix a potential XSS vulnerability
• possible XSS vulnerability in topic title field

Tags: security

Introduction

No, it was much simpler than that but the nature of Docker images means its a little different.

Persistent Volumes

In order for a docker instance to host something like Foswiki it needs persistent volumes. That is a place to hold the changing content. In timelegge/docker-foswiki the provided docker compose files esentially put the entire Foswiki website on a persistent volume. The way Foswiki automatically inter-mingles some of the data and code (or more properly automatically generates content sections under data) makes it difficult to do anything else.

So, simply pulling the latest Docker image for timlegge/docker-foswiki means you get all the updated alpine linux packages but Foswiki remains at the same version.

Upgrading

1. Download the upgrade package
2. Copy it to your Docker Image's persistent volume
3. Unzip/tar over the existing Foswiki Installation
4. Save the updated LocalSite.cfg
5. Restart your Docker Container

Example Steps assuming your Docker Container can access the Internet

docker exec -it docker-foswiki /bin/bash
cd /var/www/foswiki
wget https://github.com/foswiki/distro/releases/download/FoswikiRelease02x01x07/Foswiki-upgrade-2.1.7.tgz 
tar --strip-components=1 -zxf Foswiki-upgrade-2.1.7.tgz 
cd tools
./configure --save
rm Foswiki-upgrade-2.1.7.tgz
exit

Then you simply need to restart your docker image to cache the updated Perl Code

Example Steps assuming your Docker Container cannot access the Internet

wget https://github.com/foswiki/distro/releases/download/FoswikiRelease02x01x07/Foswiki-upgrade-2.1.7.tgz
cp Foswiki-upgrade-2.1.7.tgz /var/lib/docker/volumes/foswiki_foswiki_www/_data
docker exec -it docker-foswiki /bin/bash
cd /var/www/foswiki
tar --strip-components=1 -zxf Foswiki-upgrade-2.1.7.tgz 
cd tools
./configure --save
rm Foswiki-upgrade-2.1.7.tgz
exit

Tags: docker, installation, migration, update

Tags: security

In the first instance I measured page download times using a simple technique:

/usr/bin/time --quiet -f "%e" wget -pq --header="accept-encoding: gzip" --no-check-certificate --delete-after https://localhost/foswiki

Tsend and Treturn are defined by the network properties,I will assume that they are constant across elements for a single measurement. Tget is a server property and will be relatively constant across elements (ignoring disk transfer time, which will depend of element size). Tprocess will be zero for the static elements.

Environment - Tinkerbell Apache CGI

Environment - Katacoda Apache CGI

Environment - Katacoda Apache Fast CGI

• The result that surprised me most is the the wait times in the retrieval of the static elements. It should be noted that many of these elemnts are retrieved in parallel, but only after the the html has been evaluated in the browser. So it seems one should expect at least 200-400 ms delay in the retrieval of a page for the static elements. Caching these elements in the browser will help improve the overall performance. But the first encounter is sensitive to this wait time.
• Use FastCGI. It will reduce the wait time for html generation. In the Katacoda Apache FCGI environment it takes 500 ms to start, which are a consistent overhead on each transaction if you use regular CGI.
• If you want to improve performance beyond what Fast CGI gives you, use a server with more generous specifications. More cpu and more memory make a difference.
• Pre-zipped elements provided with Foswiki may make a difference on slow networks, but they will have no effect on the wait time. And for most elements, the wait time is 99% of the total time to receive the element.
• Apache mod_deflate is unlikely to make any improvement in the performance of your Foswiki site. The time taken to compress and decompress is added to the time it takes to retrieve the element from disk. It may help on a slow network, but you should check if it is worth it.
• PageOptimizerPlugin. This plugin collects all static css and js in one css and one js file and caches the result. From the server side perspective there are now two files to serve instead of say 10. But since the the retrieval is parallel, you are still stuck with whatever wait time is associated with the two files. At least 200 ms. Sites like Pingdom and many others recommend reducing the number of static elements per page to retrieve, because the browser needs the css and js before it can render the page. So combining the elements together may improve the user experience.

Tags: development, installation, performance