University website

A university’s website is not one website. It is thirty of them, owned by people who do not report to each other: each faculty has its own announcements, its own study programmes, its own timetables and exam documents; each research centre has projects and calls; the senate publishes decisions; the admissions office runs a campaign that changes every year and must be exact. When all of that goes through one web team, two things follow — the content is always late, and the web team spends the year copying PDFs into pages.

The recognisable symptoms in a sales conversation: documents e-mailed to a webmaster to be uploaded; faculty pages that were last accurate two years ago; an admissions offer that exists as a spreadsheet and is retyped into the site; prospective students who phone because they cannot find the rules for the programme they want; and no list of the people who expressed interest, because interest arrives as unstructured e-mail.

For a public institution with many semi-autonomous internal entities and a content problem rather than a transaction problem: a university, an institute, a hospital group, a county administration. It fits when the institution has a communications team able to structure content but no capacity to be the bottleneck for every faculty and department, and when the yearly admissions or enrolment campaign is a hard commitment with a published calendar.

It fits when editors are non-technical: everything the site shows is edited in an administrative interface with entity-scoped access, not in files.

It is not for:

• a single-entity organisation with a handful of pages — the delegated-permission machinery is the whole point and would be pure overhead;
• an institution that needs a full application and enrolment system — this captures expressions of interest and publishes results, it does not score candidates, rank them, allocate places or handle fees (see Not included);
• a multi-site or multi-brand setup expected to run several institutions from one installation — the implementation is shaped for one institution per deployment;
• a fully bilingual public site where both languages are one deployment: today the second language is a separate site.

Content and editing

Admissions

Forms and outreach

Operations

Dependencies worth knowing: the social feed and the analytics capability each need an account the institution owns, and its credential must be kept where ordinary editors cannot read it. Bot protection covers the pre-registration form and extends to other forms as configuration. Spreadsheet export is enabled per register.

What is included in a given delivery, and how it is delivered: configuration vs. custom · delivery approach.

• A candidate application and selection system. Scoring, ranking, place allocation, contracts and fees happen outside. This publishes the offer, captures interest and publishes the outcome.
• Any link to a student-information system. The list of interested candidates leaves as a spreadsheet, by hand.
• Payments. No tuition, no application fee, no gateway.
• Candidate accounts. A prospective student never logs in; there is no place to see one’s own submission, correct it, or withdraw it.
• Data-subject erasure and correction from the interface. The candidate register is read-only by design, so a request to correct or delete a record is currently a database operation.
• An editorial approval chain. An editor with access to an entity publishes; there is no four-eyes step, no scheduled publication and no draft/review state beyond the show/hide switch and the preview URL.
• Timetables, grades, course delivery, library systems. The site publishes documents about them.

Technology-neutral first — this is the blueprint:

Four things are load-bearing in that picture, and they are what a second implementation would keep: one document object shared by every module; entity-scoped editorial access; a search index that follows the content store without an editor thinking about it; and a public form intake whose records are append-only.

Implementation stack of the delivered site: Django on Python with PostgreSQL; Solr for search; object-level permissions and runtime settings inside the Django admin, which is the editorial workspace; served natively behind nginx, with the admin reachable only from agreed network addresses. The containerised setup is for development only.

There is no integration with a student-information system, no payment integration and no identity provider. Every candidate-facing exchange ends in a spreadsheet handed to the office.

Baseline: security-baseline. Specific to this blueprint:

• Editorial access is object-level, not role-level. A faculty, centre, structure, programme or commission is an object a user is granted access to; child content inherits the grant through its foreign-key chain. This is the mechanism that lets the institution decentralise editing without giving thirty people the run of the site.
• One institution per deployment. There is no tenant boundary in the data model — separation between institutions is separation of installations.
• The administrative interface is reachable only from agreed networks. Where the boundary is drawn, and who may change it, is settled at implementation.
• Login hardening is in place: repeated failed sign-ins lock the account, passwords are stored hashed and checked against strength rules.
• Personal data collected is minimal and consent-tracked. A pre-registration request holds name, contact details, age, place of residence, the year the school-leaving exam was passed, the programmes chosen, and three separate consent flags — processing, sharing with partners, and being contacted — each recorded as given or not given.
• The candidate register is append-only by design. Adding, changing and deleting are disabled in the interface; viewing and export remain. That is a good audit property and a bad erasure property: a correction or erasure request is handled as an administered data operation, not from a screen (see Not included).
• Nothing is deleted automatically. Candidate records, newsletter addresses and recorded messages are kept indefinitely until a retention rule is agreed and a scheduled deletion put in place; both are decided at implementation and documented for it.
• Audit covers who changed which object and when, through the administrative log. Publication decisions themselves are not separately audited.
• Ownership. The institution owns the code, the content, the uploaded files and the database. Backups, monitoring and their verification are an operating responsibility: assign them explicitly, or contract them through Managed Hosting.