Ma’had Nurul Ilmi is a pesantren that combines Qur’an memorization with nature-based education, and its programs and daily activities were already being shared across YouTube, Instagram, TikTok, and Facebook. It needed an official website that brings everything together in one place for prospective students and parents, including those from outside the area. The site was built as a custom child theme on top of Blocksy with a companion settings plugin, with every page built in Tailwind CSS and no page builder, and each section’s content editable from its own place in the dashboard.
A scrollable look at the finished site, exactly as a visitor would browse it.
Desktop
Mobile
Work like this is usually split between a developer, a UI/UX designer, a graphic designer, and a marketer. On this project, one person holds all four of those skill sets, so every decision came from someone who understood the whole project, not just their own part of it.
16
standards met, from code to marketing.
Business impact here is measured across 5 areas: Presence, Quality, Trust, Conversion and Growth. Together they cover how the business is found, perceived, and acted on.
Information that stays findable, not buried
Before
A pesantren relying only on social media, YouTube, Instagram, TikTok, and Facebook, to share its programs has that information buried under newer posts within days, with no dedicated place a prospective parent can go back to and check.
After
A website turns that same information into a proper, professional destination, organized by page instead of buried in a feed, so a prospective parent always finds exactly what they need before ever visiting.
Each project draws on a mix of disciplines: here’s how they came together on this one.
The tools and technologies that came together to bring this project to life.
The problems that came up while building this project, and what came out of solving them.
Settings That Reset Without Warning
WordPress stores theme settings per theme folder, so the child theme started from defaults with no error at all. Copying the settings wasn’t enough either, since Blocksy writes its styles to a generated stylesheet that only its own hooks refresh. The fix was to copy the settings, trigger Blocksy’s official cache refresh, and check the generated values against the stored ones.
Keeping Pages Up if the Field Plugin Fails
Every static page reads its content through ACF, so a failed update or an accidental deactivation would break all of them at once. A fallback layer now covers the front end while staying out of the dashboard and background tasks, so ACF can still be reactivated cleanly, verified by force-disabling it and checking every page.
A Database Export the Host Couldn’t Import
Production receives the full build from local, database and files together. The host’s database import tool rejects large files, and a plain find-and-replace on the domain would corrupt serialized settings, so the domain was replaced serialization-safely and the export was split into parts, each tested against an empty database first.
The technical problems fixed while building this project.
Pages stay up even if ACF fails
Settings carried over, verified in the output
Reduced attack surface
Every import tested before going live
Images under 200KB
Automatic compression on every future upload
No page builder overhead
Autoload: 161KB to 74KB
Settings independent of the theme
One file per section, reused across pages
Version control for custom code only
Monitored and maintained, not left to drift
Before
Every static page reads its content through ACF, so a failed update or an accidental deactivation would turn every page into a fatal error.
After
A fallback layer returns empty values on the front end when ACF isn’t loaded, while staying out of the dashboard, CLI, and cron so ACF can still be reactivated. With ACF force-disabled, every static page kept loading normally.
Before
WordPress stores theme settings per theme folder, and Blocksy only regenerates its dynamic stylesheet through its own hooks, so the child theme would quietly fall back to default styling with no error.
After
The existing settings were copied over and Blocksy’s official cache refresh was triggered, then verified by comparing the generated stylesheet’s values against the stored settings.
Before
A default WordPress install exposes information attackers can use to research a target before attempting anything else.
After
Layered hardening in the settings plugin closes those gaps across multiple points, from login protection to server configuration, and two rounds of payload testing found no critical issues.
Before
Production receives the full build from local, database and files together. A plain domain find-and-replace corrupts serialized settings, and the host’s import tool rejects large SQL files.
After
The domain is replaced serialization-safely, the database is exported in parts that are each tested against an empty database first, and server-level hardening rules ship with every deploy package.
Before
High-resolution images across the site, not just one section, risked slowing down every page.
After
Every image across the site is compressed to WebP and kept under 200KB, keeping pages fast without a visible drop in quality.
Before
Compression only happened as a one-time manual pass, so any photo the client uploads later would arrive at full, uncompressed size.
After
A custom pipeline now compresses and converts every future upload automatically, so pages stay fast without relying on anyone remembering to optimize an image by hand.
Before
A page builder loads its own scripts, styles, and deeply nested markup on every page, and Blocksy loads its own copy of the fonts by default.
After
Pages are built as Tailwind templates compiled into one stylesheet containing only the classes in use, fonts are loaded once by the child theme, and the hero photo takes loading priority over the logo.
Before
Options set to autoload had grown to 161KB, all of it loaded on every single request.
After
The autoloaded options were trimmed to 74KB, cutting what WordPress has to load before rendering any page.
Before
WordPress’s built-in theme settings are stored scoped to whichever theme happens to be active.
After
A separate settings plugin now stores brand colors, contact details, social media, and footer settings independently of the theme, and every part of the site reads contact details from that one source.
Before
Building each page as one long template would mix every section’s markup and logic together, and sections shared between pages would end up duplicated.
After
A semi-atomic structure keeps page templates as thin orchestrators, gives every section its own self-contained file and field group, and reuses shared sections across pages instead of copying them.
Before
A WordPress project mixes core files, third-party plugins, uploads, and configuration with the code actually written for it, making version history noisy and risky to share.
After
A whitelist-based repository tracks only the custom child theme, settings plugin, server templates, and documentation, keeping core, plugins, uploads, and configuration out by default.
Before
A site left unmaintained after launch, unpatched plugins, no uptime monitoring, quietly accumulates risk and downtime that often goes unnoticed until something actually breaks.
After
Ongoing maintenance keeps plugins and themes updated and monitors performance and uptime, catching issues before they become visible problems.
