[Fix]: LimeSurvey - enable Apache mod_rewrite

[jonathan8devs]

✍️ Description

On a fresh installation Apache's mod_rewrite is not enabled, so LimeSurvey's
new editor breaks: requests to /rest/v1/* return HTTP 404.

The vhost written by the script already sets AllowOverride All, and LimeSurvey
ships a root .htaccess containing the front controller rules
(RewriteCond %{REQUEST_FILENAME} !-f + RewriteRule . index.php) that route
those endpoints to index.php. But mod_rewrite is not part of Debian's
default mods-enabled set, and setup_php only enables mpm_prefork and
php${PHP_VERSION} — it never enables rewrite.

Because LimeSurvey wraps its rules in <IfModule mod_rewrite.c>, there is no
error: the block is silently skipped, the request falls through to the
filesystem, and Apache returns a plain 404. The rest of LimeSurvey keeps working,
which is what makes this hard to spot.

The fix is a single line, matching the pattern already used by ~20 other
Apache-based scripts in this repo (e.g. wordpress, bookstack, grocy):

 chown -R www-data:www-data "/opt/limesurvey"
 chmod -R 750 "/opt/limesurvey"
+$STD a2enmod rewrite
 systemctl reload apache2

The existing systemctl reload apache2 is left unchanged: Debian's
apache2.service uses ExecReload=/usr/sbin/apachectl graceful, which re-reads
the configuration and re-executes all LoadModule directives, so the newly
enabled module is loaded. This matches 12 other scripts here that pair
a2enmod with reload.

Testing: shellcheck -x and bash -n pass on the modified file. The
underlying fix was confirmed on a live LimeSurvey 7.0.11 LXC (Debian 13,
PVE 9.1): before a2enmod rewrite, apache2ctl -M | grep rewrite was empty and
the editor failed with 404s on /rest/v1/i18n/en; afterwards the module loads
and the editor works normally. No full end-to-end run of the patched script from
scratch.

AI assistance: Claude Opus 5 (Claude Code), high reasoning effort. Root cause
and fix were identified manually while troubleshooting the live container (see
#16764); the model was used to verify the root cause against misc/tools.func
and LimeSurvey's shipped .htaccess, and to confirm the change matches repo
conventions.

🔗 Related Issue

Fixes #16764

✅ Prerequisites

• Self-review completed – Code follows project standards.
• Tested thoroughly – Changes work as expected.
• No security risks – No hardcoded secrets, unnecessary privilege escalations, or permission issues.

---

🤖 AI Assistance

• No AI used – Scripts were written without AI assistance.
• AI was used – I confirm the scripts were built using AGENTS.md and .github/agents/pve-script-creator.agent.md as guidance, and the output has been reviewed and corrected to match those guidelines.

---

🛠️ Type of Change

• 🐞 Bug fix – Resolves an issue without breaking functionality.
• ✨ New feature – Adds new, non-breaking functionality.
• 💥 Breaking change – Alters existing functionality in a way that may require updates.
• 🆕 New script – A fully functional and tested script or script set.
• 🌍 Website update – Changes to script metadata (PocketBase/website data).
• 🔧 Refactoring / Code Cleanup – Improves readability or maintainability without changing functionality.
• 📝 Documentation update – Changes to README, AppName.md, CONTRIBUTING.md, or other docs.

[CrazyWolf13]

can you fix the update script too?

[jonathan8devs]

Sure, done. Since LimeSurvey updates itself through the web interface, existing containers would never get the module otherwise, so the update script now enables it and restarts Apache. It's guarded by the mods-enabled symlink, so containers that already have it are untouched and Apache isn't restarted on every run.