Rohin Grover

Who Rohin Grover is

Rohin Grover runs Hooknot Digital, a one-person studio focused on Moodle. The work is unglamorous and specific: installations that need to be built properly the first time, upgrades that have been deferred for years, migrations off hosted platforms, permission models that have drifted, and reports that Moodle's built-in tools cannot produce without custom SQL.

The work has a recognisable shape. A training platform that used to be fine is now slow, broken, or several versions behind, and the person responsible for it does not have a server engineer to hand. Rohin is the person who reads the logs, establishes what actually happened, and fixes it.

He works across the whole stack a Moodle site sits on — Linux, nginx or Apache, PHP-FPM, MySQL, MariaDB or PostgreSQL, cron and backups — as well as inside Moodle itself: roles and capabilities, enrolment methods, course structure, activity and course completion, and custom SQL reporting. He also works with IOMAD for multi-tenant Moodle, where one installation serves several separate organisations. IOMAD ships a version for each Moodle release, but it lands months afterwards: the project's own stated target is three months after each Moodle release, and the record runs a little wider than that — IOMAD 4.5 arrived in February 2025 against Moodle 4.5 in October 2024, IOMAD 5.0 in July 2025 against Moodle 5.0 in April 2025, and IOMAD 5.1 in March 2026 against Moodle 5.1 in October 2025. IOMAD 4.5 is the long-term-support line, supported to October 2027, which makes it the conservative choice for a site that wants a long support window.

How he works

Honest scoping. If a job is a two-hour configuration change, he says so rather than packaging it as a project. If a request is genuinely risky — an upgrade across four major versions on a server with no tested restore — he says that too, before anyone commits.

Staging first, always. Nothing structural touches production until it has been rehearsed on a clone. A rehearsal produces a real timing figure and a real list of plugins that break, not an estimate. The command sequence itself is deliberately dull. It runs as the web server user, which is what the Moodle CLI documentation asks for, so that nothing written under moodledata ends up owned by root, and the upgrade carries --non-interactive so it runs straight through instead of stopping on a confirmation prompt:

sudo -u www-data php admin/cli/maintenance.php --enable
sudo -u www-data php admin/cli/upgrade.php --non-interactive
sudo -u www-data php admin/cli/maintenance.php --disable

There is no separate cache purge in that sequence, and it is not an oversight. admin/cli/upgrade.php takes --maintenance as its default, and on that plain path it calls cache_helper::purge_all() itself on the way out; only a no-outage upgrade defers the purge. The paths also survived the Moodle 5.1 restructure: only web-accessible code moved into public/, so admin/cli is still at the installation root on the 5.1 and 5.2 branches.

Production-aware. Version constraints get checked before a plan is written, not after it fails. Moodle 5.2, released on 20 April 2026, requires PHP 8.3.0 as a minimum on a 64-bit build, and its database floors are PostgreSQL 16, MySQL 8.4, MariaDB 10.11 or SQL Server 2019 — Oracle was dropped at Moodle 5.0. Those floors belong to 5.2 and should not be read back onto older branches: Moodle 5.0 and 5.1, for instance, ask only for PHP 8.2.0. The upgrade floors differ too. Moodle 5.2 can only be reached from 4.4 or later, while 5.0 and 5.1 accept 4.2.3 or later, so a site sitting on 4.2.x or 4.3.x cannot go straight to 5.2 and has to hop through an intermediate release first. Moodle 5.1 also changed the directory layout so that only public/ is web-accessible, which means the document root moves, $CFG->wwwroot must not end in /public, and plugins installed before the upgrade remain in their old locations above public/ and have to be relocated by hand. Details like these decide whether an upgrade is straightforward or a multi-stage project.

Direct communication. There is no account manager, no ticket queue and no handover to a junior. The person answering the email is the person editing the config. He replies personally, usually within a working day.

What he takes on, and what he declines

Four projects, and how work of that shape is approached

Four pieces of project work that can be described in public. Hooknot Digital is a one-person studio, so the list is short. What follows each one is general practice on jobs of that shape — the reasoning rather than the marketing — not a blow-by-blow account of any single engagement.

A Moodle training website with the Edumy theme, for an astrology and numerology academy

Moodle with the premium Edumy theme. On a themed build, the decision that usually matters most is where the branding actually lives. Colours, logos, fonts and layout choices made through a theme's own settings survive a theme update; the same changes made by editing theme files do not, and they turn every future upgrade into an archaeology exercise. That single choice is often the difference between a site that can be upgraded and a site that has to be rebuilt.

An upgrade to the Moodle 3.11 line

Moodle 3.11 was released on 17 May 2021 and requires PHP 7.3.0 as a minimum. Where a job carries both a PHP move and a Moodle move, the general rule is to rehearse them separately on staging, because bundling them makes a failure impossible to attribute — a white screen after a combined jump tells you nothing about which half caused it. Worth stating plainly: 3.11 stopped receiving security fixes on 11 December 2023, so a site still on that line needs an upgrade path rather than maintenance, and it cannot reach the 5.x branches in a single move, because 5.0 and 5.1 require 4.2.3 or later and 5.2 requires 4.4 or later.

MoodleCloud to a self-managed AWS server

The usual reason to leave MoodleCloud is structural rather than performance. MoodleCloud does not permit administrators to install their own plugins or themes, and there is no server or database access. Once a site needs either, the platform has been outgrown. On this route the tool to reach for is MoodleCloud's own site export from the portal's Tools tab — a full database in MySQL or PostgreSQL format together with the site's files — rather than course-by-course .mbz restores, which lose site-level configuration. That export puts the live site into maintenance mode and may take several hours depending on the size of the database, so the cutover window has to be planned around that fact rather than around optimism.

WordPress and Moodle with single sign-on

A public WordPress site and a Moodle LMS behind it, where learners should log in once. The broad options are mirroring accounts with a bridge plugin, publishing Moodle courses over LTI, or keeping one identity source and letting Moodle consume it. The last is generally the durable answer, with a caveat that is easy to miss: WordPress core is not an OAuth 2 or OpenID Connect provider and publishes no discovery document, so it has to be fronted by a provider plugin — or, in an organisation that already keeps staff identity elsewhere, replaced as the identity source by an external provider. Moodle then consumes that provider through core auth_oauth2, which discovers an OpenID Connect provider from /.well-known/openid-configuration and requires only the authorization_endpoint, token_endpoint and userinfo_endpoint entries it finds there. Synchronising two password databases is a support burden that never ends.

Plugins in development

Six Moodle plugins are in development. None is released, and none can be bought or downloaded. Each exists because of a gap encountered while administering Moodle.

Why the studio is one person

This is a deliberate choice, and it cuts both ways. The benefit is that you speak to the person doing the work, every time, and nothing is lost in a handover. The cost is capacity: only a small number of projects can run concurrently, and a request sometimes has to wait or be turned down. Rohin would rather say that than take the work and be late. The services on offer are scoped to what one experienced person can genuinely deliver.

Where the name Hooknot comes from

A hook is how systems safely speak to each other — the defined point where one thing calls another without either needing to know the other's internals. A knot is how you tie things together so they hold under load. Integration and durability, which is a fair description of what Moodle work actually is.

How to reach Rohin Grover

Email rgrover@hooknot.com, or message +91 78992 65708 on WhatsApp. There is also a free 30-minute session you can book directly in his calendar to talk through a problem before anyone discusses scope or cost. He also maintains a Fiverr profile for smaller, well-defined jobs. If you are weighing multi-tenant options, the comparison of IOMAD against Moodle Workplace is a useful place to start, and the contact page covers what to include in a first message.