Moodle and Turnitin plagiarism detection

Before any Moodle upgrade, check the Turnitin plagiarism plugin's published compatibility range. The plugin's listing in the Moodle plugins directory shows support for Moodle 4.5 to 5.2. Moodle 5.3 was released on 5 October 2026 and receives general support until 4 October 2027. Because the listed range stops at 5.2, a site that plans to move to 5.3 cannot assume the Turnitin plugin will work after the upgrade. The plugin's requirements for each Moodle release come from Turnitin and the plugin page, so the upgrade team should check the current listing on the day the upgrade is scheduled and ask Turnitin in writing for a compatibility statement that names the target version.

Treat that compatibility statement as a gate in the upgrade plan, not as a item to confirm after the upgrade. Record the current Moodle version and the installed Turnitin plugin version, identify the target Moodle release, and obtain Turnitin's statement for that exact pairing. If the statement does not yet cover the target, the options are to wait, to stage the upgrade on a copy of production, or to defer the upgrade. Confirm the Turnitin licence as a separate item, because the plugin requires a licence and the terms should cover the upgraded site and the hosting environment. Ask Turnitin whether any licence or account change is needed when the Moodle version changes.

A Turnitin-dependent site must also meet Moodle's server requirements for the target release. From Moodle 5.1, the web server document root must point to the new /public directory instead of the main Moodle folder, or the site may show directory listings or errors. Web server configuration, reverse proxies and deployment scripts all need to change to match. For Moodle 5.3, the release notes list 64-bit PHP 8.3 or later (8.4 is supported), PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Sites must also run Moodle 4.4 or later to upgrade to 5.3. Check each database and PHP version against these lists before the plugin question is settled, because the two sets of constraints apply together.

Turn these checks into written items for the upgrade scope. Ask Turnitin which plugin version pairs with the target Moodle release and when that version will be published. Confirm that the database engine, PHP version and document root meet the target's requirements in a staging environment that mirrors production. Decide who signs off the Turnitin statement, and who owns the rollback if the plugin fails after the core upgrade. Also confirm which assignments, forums, quizzes and workshops use Turnitin features, so testing covers similarity reports, grading and feedback on each. If the team cannot get a clear statement for 5.3, plan the upgrade around that answer rather than around the release date.

The most useful thing to map before rollout is the path a piece of student work takes through Moodle and back. When a student submits to an activity where the Turnitin plugin is enabled, the work is passed to Turnitin for processing. The similarity report comes back and is attached to that submission in the Moodle activity, so teachers review the report where they already grade. Teachers then add grades and feedback through Moodle's normal grading tools, and students see their results in the places Moodle already uses for that activity. The exact order of these steps, including timing and where each item appears in the interface, depends on your Moodle version and plugin version. Confirm the full sequence in a test course with a test student account before you publish the configuration.

The first decision is which activities send work to Turnitin. The plugin's listed features cover Moodle Assignments, Discussions (forums), Quizzes and Workshops, and each can be treated differently. Enabling the plugin at site level does not automatically send every activity's content for checking, so confirm how the plugin is turned on for each activity type and course. Write down the rule your institution will apply, for example which assessment types must be checked and which are exempt. Quizzes and forums often produce different kinds of text than file uploads, so test each activity type separately and decide whether the resulting reports are useful for that type of work.

The second decision is whether students can see similarity reports, and when. Moodle activities commonly offer options that control what students see and at which point, but the names, defaults and interaction with grade release differ by activity and version, so confirm them in your environment. Showing a report before the final submission deadline lets students revise and resubmit, which supports learning but may encourage repeated editing to reduce matches. Showing reports only after grading protects the assessment but gives students less chance to correct citation errors. Set one institutional position, document it for teachers, and check that students see grades and feedback in the same place the report appears.

The third decision is how resubmissions are handled. Ask whether each new submission is sent to Turnitin again, whether earlier reports remain visible to teachers, and how draft or unsubmitted work is treated. Also check how the Turnitin licence applies to users and activities, because the plugin requires a licence from Turnitin and your agreement will set the terms. Confirm that your Moodle version is within the range the plugin lists, which is Moodle 4.5 to 5.2 in the plugin directory listing, before testing. Record the answers in a short test script so that teachers, support staff and your Turnitin administrator follow the same process.

The test plan should answer one question before any student sees the integration: does each Turnitin-enabled activity send work, return a similarity report to the right people, and pass grades and feedback back to the Moodle gradebook? Start in a dedicated test course, not a copy of a live course, so that no real student data reaches Turnitin during testing. Enrol at least one teacher account, one student account and, if your courses use them, a non-editing teacher and a second student. Create these accounts through the same authentication method your students use, so the role checks reflect production. Before the first test, confirm that the Turnitin plagiarism plugin is installed on this site and that your institution holds the licence it requires.

The first set of checks covers submission and the similarity report. Create one test activity for each type you plan to enable: assignment, forum discussion, quiz and workshop, since the plugin supports all four. Submit a document that contains original text and a passage copied from a source you control, so you know what the similarity score should roughly reflect. For each activity, confirm that a similarity report is generated and that the score appears. Then check visibility by role: the teacher should see the full report, and the student should see only what your settings allow, such as a score or no report at all. Record the setting values beside each result, because a visibility rule is only verifiable against the configuration that produced it.

Next, test the grading and feedback round trip. Grade the test submissions in Moodle, add written feedback, and confirm that the grade appears in the gradebook and that the student sees the feedback in the expected place. If you enable Turnitin grading or feedback tools, test each one separately and confirm which tool writes the grade back to Moodle. Then run the resubmission test on an assignment with resubmissions allowed. Submit a second version, confirm that the two reports can be told apart, and check how the first attempt's grade and feedback are handled under your settings. Ask the vendor to confirm how resubmitted papers are counted and stored, because that behavior affects how teachers review repeat submissions.

The test must also prove that disabled activities do not send work. Create one activity with the Turnitin option turned off, submit a file to it, and confirm that no similarity report is created and that no record of transmission appears in the plugin or Turnitin's own records. Confirm with Turnitin how to check transmission logs from your account, since the answer determines what evidence you keep. Finally, back up a test course that contains Turnitin-enabled activities, restore it to a separate course, and check that the restored activities keep their settings and still link to Turnitin. Verify whether existing reports carry over or whether work must be resubmitted, and confirm that the restored copy does not send work anywhere unexpected.

Record every check in a results log before running it. Use columns for check ID, Moodle version, plugin version, settings used, expected result, actual result, tester and date. Writing the expected result first stops the test from being judged against whatever happened. Repeat the full plan after every Moodle point release, plugin update, licence renewal or configuration change. The plugin directory lists support for Moodle 4.5 to 5.2, so if your target Moodle version falls outside that range, including the 5.3 release, confirm compatibility with Turnitin in writing before you upgrade and before you run this plan again.