Skip to main content
Enterprise Annual License: pay for 10 months, get 12.Claim the free months
HiTechCloudPanelDocumentation
Version: 4.1

Moodle Manager

Install and manage Moodle — an open-source learning management system (LMS) — in an existing domain, via Moodle's own CLI installer. Install, a read-only overview with live status, cache clearing, error logs, maintenance mode, a dedicated backup/restore system, cloning, self-update, and uninstall.

Install Moodle​

Navigate to HiTechCloud > AutoInstaller and click Install Moodle.

On the install page, configure:

  • Domain – The domain (and optional subfolder) to install into. Leave the subfolder blank to install at the domain root.
  • Site name / Site short name – Moodle's full site name and short name.
  • Moodle version – Latest, or an earlier release line such as 4.5 LTS, listed live from Moodle's GitHub tags. The newest build of the line you pick is installed (picking 4.5.2 installs the current 4.5.x).
  • Admin username / password / email – The initial administrator account Moodle creates during install. Leave the password blank to generate one.

Behind the scenes, this downloads that release line's packaged tarball from download.moodle.org (a copy in the server's cache is reused for at most a day, so an install always gets the line's current point release), and extracts it into a sibling "app root" directory next to the domain's docroot rather than the docroot itself. The layout is read from the release itself: from Moodle 5.1 the web-served files are under a public/ subdirectory, with config.php and admin/cli/ one level above it (outside the web root, by design); up to 5.0, including 4.5 LTS, the whole tree is served. HiTechCloud replaces the (empty) docroot with a symlink to that web root — <approot>/public or <approot> — so the webserver serves exactly what Moodle intends. If the domain's PHP version is older than the release requires (read from Moodle's own lib/phpminimumversionlib.php), the install stops here and says which PHP version to switch to. It then creates a dedicated MySQL/MariaDB database and runs Moodle's own admin/cli/install.php non-interactively with the details you provided. Finally, it registers a per-minute cron job running admin/cli/cron.php — Moodle does nothing (no mail, no enrolments, no scheduled tasks) without it. Progress is streamed live as each step completes.

Manage a Moodle site​

Every Moodle install shows up on the general Site Manager page (/sites) alongside your other websites. Click Manage on a Moodle site to open its overview page:

  • Screenshot and Moodle / PHP / MariaDB / Created status cards, matching the other CMS managers.
  • Files – The docroot is a symlink to Moodle's web root (the app root's public/ directory from 5.1, the app root itself before); a File Manager shortcut, and live folder size.
  • Database – Name and table prefix, read live from the app root's config.php (not stored anywhere separately), plus a phpMyAdmin shortcut.
  • PHP version – Editable for root-level installs; subdirectory installs inherit the domain's PHP version.

Cache​

The Cache widget runs Moodle's own bundled admin/cli/purge_caches.php, the standard documented way to purge all Moodle caches without a browser.

Logs​

The Logs tab tails the newest log file under moodledata (Moodle's separate data directory — see below). Moodle logs most application events to its own database, readable only through its admin UI, rather than a flat application log file, so this surfaces PHP-level errors instead. A freshly installed, healthy site typically has none yet.

Maintenance mode​

The Maintenance mode toggle enables or disables Moodle's own front-end maintenance page, via admin/cli/maintenance.php --enable / --disable — the same mechanism the Update flow uses automatically while it runs. Status is read back by checking whether Moodle's own climaintenance.html marker file exists under moodledata, rather than parsing the script's output.

Backups​

Moodle sites get a dedicated backup system, separate from the account-level Backups feature. Real site content — uploads, course files, caches — lives in moodledata, not the docroot (which contains only the stock release code, identical across every install of that version), so that's what's backed up:

  • Generate an on-demand backup of the database, moodledata, or both. Backups are stored per-domain, per-timestamp (backups/<domain>/<timestamp>/database.sql and/or files.tar.gz) under your account's html_data volume.
  • Restore any previous backup date. Restoring the database drops the site's existing prefixed tables first, then imports database.sql; restoring files extracts files.tar.gz over the current moodledata directory.

Clone​

The Clone action copies a Moodle site to a new domain (or subfolder). It copies both the app root and moodledata directories, creates a new database from a dump of the source database, rewrites the database name/user/password/wwwroot/dataroot inside the copy's config.php, symlinks the destination docroot to the copy's web root (public/ from 5.1, the app root before), registers the copy's own cron job, and runs a generic URL search-replace across the cloned database — Moodle's CLI has no built-in equivalent of WP-CLI's search-replace, so HiTechCloud handles it itself.

Update​

The Update action brings an installed site to the newest build of its own release line — a 4.5 LTS site stays on 4.5. Moving to a newer major release (for example 4.5 to 5.x) is a separate step that has to be asked for explicitly (major=1 on the update request), because a major release can need a newer PHP version and, from 5.1, moves the web root into public/.

The update downloads the line's packaged tarball (a cached copy is reused for at most a day), unpacks it beside the site and checks it before touching anything:

  • it must be newer than the installed build — otherwise the update stops with "Already running the latest version", or finishes a database upgrade an earlier run left pending;
  • the domain's PHP version must be at least the one the new release requires.

It then enables maintenance mode, swaps the new release in with the site's config.php (the previous release is kept aside meanwhile), points the docroot at the new web root if the layout changed, runs admin/cli/upgrade.php --non-interactive, and disables maintenance mode again. If upgrade.php stops before it changes the database (its environment, file and plugin checks), the previous release is put back and the site keeps running as before. If it fails part way through the database upgrade, the new release stays in place; fix the reported cause and run Update again to finish. Maintenance mode is turned off in every case. Only config.php is carried over: add-on plugins installed into the code must be added to the new release again.

Remove​

The Remove tab's Delete Application button fully uninstalls the site: removes the registered cron job, drops the database and database user, deletes the docroot symlink plus the app root and moodledata directories, and removes it from Site Manager. This cannot be undone.

Not included​

To keep this feature simple, the following are not part of Moodle support (unlike the WordPress Manager):

  • A dedicated "Moodle Manager" sidebar page — manage installed sites from Site Manager instead
  • One-click "Login as Admin" — log in with the admin credentials you set during install
  • A general admin/cli/* command console — only cache purging and log tailing are exposed
  • Scanning the filesystem for untracked installations
  • Security hardening rules
  • Pinning an update to a specific point release — Update installs the newest build of the site's release line, or of the newest line when a major upgrade is asked for
  • Only MySQL/MariaDB databases are supported (not PostgreSQL)
Previous
TinyFileManager Manager
Next
OJS Manager
Was this helpful?