Exam runner - Plugixa Exam

The runner is the screen a candidate actually sits an exam on. Everything in it is arranged around one idea: nothing the candidate can reach decides anything. The clock, the question set and the score all live on the server, and the browser is given a nicer way to talk to them.

Starting an attempt

When somebody presses Start, the plugin does four things in order.

1. Checks the access gate. Open, by role, by access code, as a named guest, or by cohort PRO. See Access and Enrollment.
2. Looks for an attempt already in progress. If there is one, they resume it rather than starting a second. This is why closing the browser is not a way to get a fresh paper.
3. Builds the paper. Fixed sections contribute their questions in order; pool sections draw theirs now, according to their rules. Shuffling, if the exam uses it, happens here.
4. Stores the deadline. The attempt gets an expires_at computed from the server’s own clock.

From that moment the attempt carries its own copy of the exam. Everything below follows from that.

The clock is the server’s

If the exam has a Time limit, the deadline is stored on the attempt when it starts, and every write checks it. An autosave that arrives after the deadline is refused; so is a submission.

The countdown the candidate sees is drawn from that stored deadline, but it is only a display. Changing the operating system clock, pausing the JavaScript timer in devtools, or leaving the tab suspended for an hour changes nothing about when the paper closes.

A time limit of 0 means untimed. An untimed exam still is not a permanently open door, because the inactivity rule below still reaches it.

The paper is frozen

The question set, its order, the points on each question and the runner settings are captured into the attempt when it begins.

This means:

• Editing an exam mid-session is safe. Fix a typo, change the points, add a section: it applies to the next person who starts, never to somebody already answering.
• A pool draws once. Each candidate gets their own selection, and a reload returns the same one rather than re-drawing. The shuffle is seeded per attempt for the same reason.
• Deleting a question does not empty a paper in progress. The attempt already holds what it asked.

Autosave

Answers save as the candidate works, so a closed tab, a flat battery or a dropped connection loses nothing already entered.

Each autosave posts the whole of the current answer for a question, not a diff against what the server last saw. That is deliberate: a resend is safe, because writing the same answer twice produces the same state. If a save is lost in transit, the next one carries the same content and repairs it.

When they come back, they carry on from where they were, up to whichever of these comes first: the time limit, the exam’s closing time, or the inactivity period.

Pause and resume

If Allow pause is on, the candidate can stop the clock and come back.

Setting	What it does
Allow pause	Whether the Pause button exists at all
Max pauses	How many times one attempt may be paused. 0 is unlimited
Max pause minutes	The total frozen time allowed across an attempt

When an attempt resumes, the deadline moves forward by exactly the time that was frozen, so a pause neither costs nor gives the candidate a minute.

Layout and behaviour

These are per-exam, and they are the settings that change what the runner feels like.

Setting	Values	What it does
Layout	single_page, one_per_page	The whole paper at once, or one question at a time with a navigator
Review before submit	on / off	A summary screen listing answered, unanswered and flagged questions before the paper goes in
Allow early finish	on / off	Whether Submit is available before the time is up
Require answer	off, warn, block	Leave blanks freely, be warned about them, or be prevented from moving on
Fullscreen mode	off, offered, required	Whether the runner asks for, or insists on, fullscreen

What closes an attempt nobody came back to

Every other ending is request-driven: the candidate presses Submit, or their next autosave is refused for being late. A closed tab produces neither, so a scheduled sweep closes attempts that have gone quiet.

Without it an attempt would sit in_progress for ever. That is worse than it sounds: attempt caps count in-progress rows deliberately, so the candidate would be holding one of their own allowed attempts, locked out of a retry, and never graded on the answers they had already saved.

Three rules close an attempt:

1. The deadline passed.
2. The exam’s window shut and Window close action is close.
3. It has been silent longer than Idle timeout minutes. This is the only rule that reaches an untimed attempt.

What then happens is up to the exam:

Setting	Values	What it does
Auto close action	submit, abandon	Mark what they saved, or close the attempt unmarked
Auto close time spent	capped, wallclock	Record the time as capped at the limit, or as the real elapsed time
Auto close notify	auto, normal, silent	Whether the usual result notification goes out for a swept attempt

Choose submit when a partial paper still deserves a mark, and abandon when an unfinished attempt should not count as a sitting.

Without JavaScript

The runner is a real HTML form before it is anything else. With scripts blocked or broken, the candidate gets a server-rendered paper and an ordinary form post, and the exam still works end to end: the same access gate, the same frozen paper, the same server-side deadline, the same marking.

What they lose is the enhancement layer - the live countdown, the question navigator, flagging, and saving as they go rather than on submit. Picture and hotspot questions fall back to a labelled grid rather than a click target, so they remain answerable.

This is worth knowing when you are deciding whether to require fullscreen on a locked-down exam machine: the paper will work there either way.

Troubleshooting

Symptom	Usual cause
Candidate says the timer “jumped”	The clock is server-owned, so a suspended tab catches up on the next render. The deadline never moved.
An attempt is stuck in progress	The sweep runs opportunistically off ordinary admin requests, throttled site-wide. Load an admin page, or check that Idle timeout minutes is not 0.
Somebody cannot start, and is told they already have an attempt	They do. Attempt caps count in-progress rows. Close it from the attempts list, or let the sweep do it.
A resumed attempt shows the old questions	That is correct. The paper is frozen at the start; your edit applies to the next person.

More in Troubleshooting.

What to do next

• Decide how the paper is assembled in Sections and Pools.
• Decide who gets in, and how often, in Access and Enrollment.
• Decide what happens when the paper lands in Grading.
• Watch it happen live with Live Monitoring PRO.