For Sobol school, we created a website on Grav CMS with content management and three enquiry workflows. This case study covers the website structure, enquiry storage and public-page checks. Development results refer to the report dated 2 October 2026.
Project website: Sobol School
Initial task
A school needs pages with content that changes throughout the season: schedules, events, news, and cost of classes. The store and registration for training add individual visitor actions that also need to be supported.
The work was divided into creating the theme and structure of the CMS, public sections and processing requests. This way you can check each part separately: the presence of a page does not confirm that the enquiry has been saved from its form.
Work and documented results
| Work | Result | Period or source |
|---|---|---|
| Website development with Grav CMS | 12 public sections checked: HTTP 200 | Based on the report dated 2 October 2026 |
| Enquiry forms and HTTPS | 3 enquiry types stored in the admin area | Based on the report dated 2 October 2026 |
Website development with Grav CMS
12 public sections checked: HTTP 200 · Based on the report dated 2 October 2026
We built the theme and content management. Added a shop, gallery, news, events, timetable and lesson price calculator.
We created a Grav theme and content management. The structure includes a shop, gallery, news, events, timetable and training-price calculator. The content is managed through the CMS.
According to the report, as of October 2, 12 public sections were checked: all responded with HTTP 200. This check confirmed the availability of the selected routes as of the report date.
For the owner, the CMS makes it possible to maintain information sections without separately editing the template each time the text is changed. Functional changes, such as a new store scenario, still require development and testing.
Enquiry forms and HTTPS
3 enquiry types stored in the admin area · Based on the report dated 2 October 2026
Training bookings, event registrations and shop orders. We restored HTTPS and set up redirects from HTTP and www.
We set up three types of requests: registration for a training session, registration for an event, and ordering in a store. The data is saved in the admin panel, so the result of the submission can be checked by record, and not just by the message on the page.
We restored HTTPS and configured transitions from HTTP and the domain option from www. When checking addresses, both the final page and the chain of redirects are important: the visitor must get to a working, secure version.
Public screenshots show pages and mobile interface. They help evaluate the structure and presentation of information, but do not show visitors' private records.
How we verified the result
The published card contains 12 available public sections and three types of requests that are saved in the admin panel. These results refer to the report as of October 2 and are not a guarantee of continued availability in the future.
While preparing this case study, we reopened the public website and captured its desktop and mobile interface. We did not send any new test enquiries to the school's website.
Scope of the result
In the original report, setting up SMTP and Telegram was classified as remaining tasks. Therefore, here we confirm the saving of requests in the CMS, but do not declare the launch of all notification channels.
The number of sections reviewed describes the scope of the technical review. It is not an indication of traffic, student numbers or store sales.
What to consider for a similar project
For a website with several signup workflows, check each workflow separately. Acceptance needs working pages, stored data and a separate status for notification delivery.