View Articles

Most Tiki Wiki maintenance tasks, from rebuilding the search index to sending notification digests, should never depend on someone remembering to click a button. The built-in Scheduler turns these chores into background jobs: set one cron entry on your server, then manage everything else from the Tiki interface.

The official documentation covers the basics in a few lines; this guide goes further, with the reasoning behind each setting and a set of tasks we actually deploy on client sites.

With the arrival of Tiki 30, the new Long Term Support release expected in summer 2026 and supported until 2031, your Tiki 27 enters the final stretch of its lifecycle. While it will keep receiving security fixes until 2029, there will be no more functional fixes or improvements. The time has come to plan your migration, without rushing, but without putting it off indefinitely.

Between the two releases, two versions (28 and 29) have deeply modernised Tiki. The list is very long, too long for a single, simple article, so we offer here a concise summary, along with all the links to read the details published by the Tiki community. Important good news: there is no abrupt technological break comparable to the PHP 7 to PHP 8 jump, because that work was already absorbed by Tiki 27. The developers, mindful of user's feedback after earlier, more "muscular" upgrades, have taken particular care to build bridges and update scripts that make it far more painless. In short, the road is clear.

This guide explains how to set up a Debian 13 server with the Virtualmin hosting control panel and deploy a Tiki Wiki CMS solution using exclusively open-source software.

Built with security and digital sovereignty in mind, you will learn how to configure essential server components (ports, MariaDB, PHP versions), install Webmin and Virtualmin, secure your server with SSL certificates, and publish your Tiki Wiki site efficiently.
This tutorial is designed for intermediate system administrators and full-stack developers seeking a reliable, scalable, and sovereignty-friendly approach to deploying modern web applications.

The Tiki 27+ Build System marks a significant evolution in the way Tiki Wiki CMS Groupware handles its development and deployment processes. This article aims to guide you through the essential steps and provide solutions, even as the process continues to stabilize.

Introduced in Tiki 27 and refined in subsequent versions, this build system brings numerous enhancements aimed at improving efficiency, consistency, and ease of maintenance for developers and users alike. However, it requires power users and administrators to familiarize themselves with the new installation method from Gitlab (Version Control System). This guide details the updated Tiki system build and setup procedure leveraging nvm for Node version management and npm for dependency handling, including troubleshooting for frequent installation and runtime issues.

If you're installing Tiki Wiki 27, Tiki Wiki 29, or any version above from the git repository, you'll need to use the Tiki Build System that was recently introduced. When running setup.sh option "b" (build), you may encounter build failures due to memory allocation issues. This is a common problem that occurs when Node.js runs out of allocated memory while compiling JavaScript assets. Here’s the troubleshooting process we use, and how you can apply it yourself.

After upgrading from Tiki Wiki 27 to Tiki 29, many users have discovered that their autocomplete functionality (used in CustomSearch for example) no longer works. The input field that previously showed suggestions as you typed now shows nothing at all. This can be particularly frustrating because there are no obvious error messages in the browser console, and the rest of your CustomSearch appears to function normally. The search still works, the results display correctly, but the helpful autocomplete suggestions have simply vanished. Find the solution in this article.

Tiki Wiki CMS is used on several sites that are currently under heavy fire from aggressive, resource-hungry AI crawlers. These bots can overwhelm servers to the point where applications become painfully slow or even completely unavailable, as we discussed in a previous article.

The answer cannot be limited to what happens “at the server’s doorstep” (WAF, rate limiting, IP blocking, etc.). It is just as essential to strengthen Tiki Wiki itself by acting on:

• The content the site actually exposes to visitors and bots
• The way queries are built, filtered, and chained
• The detection and control of abnormal memory or CPU consumption
• The data that is queried versus what is actually returned
• The use of Tiki’s own optimisation and performance tools

The goal of this article is to present concrete measures within Tiki Wiki CMS to reduce the attack surface, control resource consumption, and ensure your site stays available even under AI: crawlers hungry for data that overload your servers and leave your sites slow or inaccessible|pressure from AI bots or malicious crawlers], while also improving its performance over the long term.