Work/Education/Built for a client
CRSS school website
One front door for three campuses, each editing its own pages.
LiveBuilt for the school and live.
Web
The problem
“Where do I see each campus, apply, and find a current contact?”
The school's web presence was a local page from 2021 and a hosting placeholder. Its three campuses, in Gbagada, Festac and Molete, run semi-independently. Each had its own scattered footprint of Facebook pages, YouTube channels and a printed booklet. Parents had no single, current place to see each campus, apply for admission or find contacts. Campus teams had nowhere to publish news, photos or results themselves. A generic template could not carry three campuses with separate admissions queues and separate editors.
Who had it
- Parents and applicantsSee each campus, understand admissions and apply online without confusion.
- Campus teamsPublish their own news, photos and results, and receive their own applications.
- Central officeOne consistent brand and contact details across all three campuses.
What the answer had to survive
- Three campuses must edit one site without touching each other.
- Must run on ordinary, low-cost shared hosting.
- Must be useful from public material before the school supplies more.
- The application form must work even without JavaScript.
- Editors are teachers and office staff, not developers.
What we built
One public site, three campus pages, and a content system each campus runs.
The site gives parents one front door to all three campuses, each with its own page, gallery, contacts and map. An online four-step admission form gives each application a reference and emails the right campus. Behind it, a content system has four logins: one for the central office and one per campus. A campus can edit only its own page, gallery, news, applications and enquiries. Every save is kept and can be restored in one click. It is plain PHP, so it runs on any ordinary hosting account.
What it does
Public pages
- Home with campus cornerstonesA pausable headline and three colour-coded cornerstones, one for each campus, lead into each campus page.
- Campus pagesPrincipal's message, results, student speeches, gallery, videos, contacts and a map for each campus.
- News and galleryNews and photos can be filtered by campus and topic. The site launched with 16 stories and 217 photos.
- Pay fees and portal linksA Pay Fees page explains and links to the school's fees portal. A portal page lists every sign-in.
Admissions
- Four-step online applicationWorks without JavaScript. An optional passport photo is stored privately and shown only inside the dashboard.
- Reference and campus emailEach application gets a reference, and the receiving campus is notified by email.
- Status workflowFrom New to Admitted, with notes and history. Search by campus, class and session, and export to CSV.
- Enquiries inboxThe contact form feeds a separate inbox for each campus.
Campus CMS
- Four logins, hard wallsA campus login reaches only that campus. Everything else shows Not allowed.
- Guided editor formsEvery editable field has help text. Editors never touch page templates.
- Photos from a phonePhotos are shrunk in the browser before upload and stored as WebP, with captions and albums.
- Every save keptThe original plus the latest 30 versions are kept. One click restores any of them.
Safety
- Protected forms and sign-inSpam traps, rate limits and a 15-minute lockout after five failed sign-ins.
- Private uploadsThe uploads folder blocks code execution, and all output is escaped.
- Traceable contentOnly facts traceable to the school's booklet or public pages were published.
A day with it
- 1
Arrive at the home page
A parent sees the pausable headline and the three campus cornerstones.
- 2
Open a campus
The campus page shows the principal's message, results, gallery, videos, contacts and map.
- 3
Read admissions
The process and the common questions are answered before any form is opened.
- 4
Apply online
The parent completes the four-step form, with an optional passport photo.
- 5
Get a reference
The application receives a reference, and the right campus is emailed and sees it in its admissions office.
- 6
Pay fees or sign in
Later, Pay Fees leads to the fees portal, and Portal Login leads to results.
How it works inside
A plain PHP site with no framework and no build step, so it runs on ordinary shared hosting. Default wording lives in files. Edits made in the content system are stored in the database and merged over the defaults, so an unedited page always shows. The site hands off to the school's separate fees and results portals.
Cut the network to see what this system does without it.This one lives on the internet, so it waits, like any website. Its staying power is on our side: backups, health checks and tested recovery.
On the device
- Visitor or editor browserParents browse; campus staff sign in to edit.
Our cloud
- Public pagesHome, campuses, news, gallery, contact.
- Admission form and back-officeFour steps, references, statuses, CSV export.
- Campus CMSGuided editor, versions, uploads, four logins.
- MySQL databaseContent, revisions, news, applications, users.
- Uploads folderWebP images; passport photos kept private.
Outside services
- Campus inboxEmail notice for each new application.
- School fees portalSeparate system; the site links parents to it.
- School results portalSeparate system; opened from Portal Login.
- Campus videosYouTube and Facebook videos shown on campus pages.
Every part and every link, as text
- Visitor or editor browser — Parents browse; campus staff sign in to edit. (on the device)
- Public pages — Home, campuses, news, gallery, contact. (our cloud)
- Admission form and back-office — Four steps, references, statuses, CSV export. (our cloud)
- Campus CMS — Guided editor, versions, uploads, four logins. (our cloud)
- MySQL database — Content, revisions, news, applications, users. (our cloud)
- Uploads folder — WebP images; passport photos kept private. (our cloud)
- Campus inbox — Email notice for each new application. (outside services)
- School fees portal — Separate system; the site links parents to it. (outside services)
- School results portal — Separate system; opened from Portal Login. (outside services)
- Campus videos — YouTube and Facebook videos shown on campus pages. (outside services)
- Visitor or editor browser → Public pages: Reads pages (needs internet)
- Visitor or editor browser → Admission form and back-office: Applies, gets a reference (needs internet)
- Visitor or editor browser → Campus CMS: Campus editors sign in (needs internet)
- Admission form and back-office → MySQL database: Stores application (needs internet)
- Admission form and back-office → Campus inbox: Notifies the campus (needs internet)
- Campus CMS → MySQL database: Edits merged over defaults (needs internet)
- Campus CMS → Uploads folder: Photos stored as WebP (needs internet)
- Public pages → MySQL database: Reads edited content (needs internet)
- Public pages → School fees portal: Pay Fees link (needs internet)
- Public pages → School results portal: Portal Login link (needs internet)
- Public pages → Campus videos: Embedded videos (needs internet)
The hard parts
A CMS designed in from the first day
- The situation
- Each campus would need to edit its own pages later. A site with wording fixed in templates would need a developer for every change.
- What we did
- We kept all default wording in content files and built a layer that defines each editable field and who may edit it. Edits merge over the defaults, so an unedited page always renders. Every save is versioned, and a test checks that an unchanged save leaves the public page identical.
- The lesson
- The site grows with the school and does not depend on its developer for every edit.
Three campuses, one site, hard walls
- The situation
- Three campuses edit one site and receive their own applications. No campus may see or change another's content.
- What we did
- We built role-based access. A general login has full access. A campus login reaches only that campus's page, gallery, photos, news, applications and enquiries. Everything else returns Not allowed. Passport photos are stored privately and open only in the dashboard.
- The lesson
- Branches can share infrastructure without sharing access.
Surviving real shared hosting
- The situation
- The site had to run on a low-cost shared host. After the first upload, the site failed with a server error, and it was not clear which database was in use.
- What we did
- We traced the error to the host's PHP version setting being overwritten during upload, fixed the order of steps and documented it. We built a protected status page showing the database in use, PHP status, folders and error log. Update packages never include live configuration or uploads.
- The lesson
- Delivery includes the unglamorous half, with tools that let a non-engineer see what is wrong.
A moving headline with an off switch
- The situation
- The school wanted motion on the home page without annoying anyone.
- What we did
- We built a rolling headline that cycles the motto and campus names. A pause button remembers each visitor's choice. A no-JavaScript fallback shows the text still, after we found a hidden preview renders no animation frames.
- The lesson
- Animation is a feature with an off switch.
The stack
- Apps
- Plain PHP, no frameworkHand-written CSS and JavaScript
- Data
- MySQL in productionSQLite for local workJSON content defaults
- Infrastructure
- Shared cPanel hostingApache rewritesAutoSSL
- Services
- PHP GD for WebP imagesPHP mail for campus notices
- Testing
- Browser end-to-end scriptsSave round-trip checks
How it came together
- 1ResearchWe started from the school's own public material.
- 2A full first draftEvery page, the admission form and the admin area were built as a first draft.
- 3The school's decisionsThe school's decisions were applied, and the content system and four logins built and tested.
- 4DeployedThe site was deployed to the school's shared hosting on MySQL, with the logins created.
- 5AnnouncedA second domain was redirected with HTTPS, and announcement messages and a screen-tour video produced.