A Website for the Ages: Egyptology in North Texas

A Temple to Outlive Its Builder

This article describes the Scribe's Palette, a durable information engine I built for an Egyptology club (North Texas ARCE) website. It's designed to preserve institutional knowledge across decades and leadership changes. Importantly, it is meant to be invisible and durable.

When I joined the board in 2026, the chapter's web presence was solid again, but only after previous websites had been lost when their creators moved on or passed away. Another board member before me who had worked hard to restore a fraction of the information that was lost and stand up the website again. As I took on the role and began making improvements, I kept seeing how to solve small problems for the board and club. Why pay for SquareSpace when I can make them a gift of a custom web editor tool. Why not keep useful things in a central place they can share control over.

But creating such tools would come with quite the obligation to make sure it was a fit and better than what exists now. Whatever I built next would need to get the club at least 10 years into the future without the same level of overhaul again.

My web systems usually run a bit more arcane, but I wanted to keep this one simple. I chose PHP for the new site because it is one of the most widely understood server-side languages on the web. It runs on virtually every hosting provider. Any competent web developer can pick up a PHP project and understand what it does. I needed server-side capabilities (you can't do authenticated admin tools or secure file handling in a purely static site) and I didn't want to build something that required specialized knowledge to maintain.

If something happens to me, someone else already has a USB drive they can hand to a new tech person to get things back up again. Maybe the fancy site editing features don't work anymore. But all of the information is still there and ready to go again.

Carved in Stone, Stored in the Sky

The chapter needs to manage content that changes: upcoming events, board member lists, meeting minutes, documents. But the server that hosts the site is disposable. Cloud instances come and go. If the instance crashes, or gets reinstalled from scratch, the information on the website has to survive... in one piece, not split in half with some sitting in a forgotten database somewhere.

The system I built (I call it the Scribe's Palette*) keeps a working copy of all chapter activity history on the server and mirrors it to cloud object storage. When the server starts fresh, it pulls down what it needs on demand. Writes go to both the local copy and the cloud simultaneously. The chapter's information is always in two places, and neither place requires the other to function. The site serves content from local disk for speed, and the cloud copy is what stays in place when the site has to be replaced or restarted.

Most content management systems give the web server broad permission to read and write files. That's convenient until it becomes a vulnerability. Beyond losing websites to leadership changes, I've seen small organizations lose everything to hackers who exploited file upload forms. An unrestricted upload handler can be tricked into writing executable code to the server, and suddenly everything is gone or held for ransom.

I wanted the opposite: a content engine where every operation passes through a single, tightly controlled channel. A custom server extension intercepts all content requests, validates identifiers, rejects path traversal attacks, and only permits whitelisted file types. The extension runs inside the web server process with no separate ports or services to secure. PHP code has no idea it exists.

I would not have chosen to build this without LLM coding assistance. This literal custom PHP extension (compiled and added to the web server) required writing in Go, interfacing with PHP's C internals, and navigating stream wrapper APIs that are sparsely documented outside of the PHP source code itself. Having an AI collaborator that could work across those layers (Go, C, PHP internals, cloud SDKs) turned a project that would have taken easily a week or two into an afternoon of iterative building and testing.

The Great Archive

Saves & Retains what's needed

Forbidden Writing

Can't overwrite certain things

Some content should be harder to delete. The chapter's charter, contact information, and structural pages are authored by the developer and deployed from source control. Other content (events, meeting minutes, the officers list) needs to be freely editable by board members through admin tools.

Editable content flows through freely: created, updated, deleted, synchronized to the cloud. But the permanent content is immutable at runtime. The only way to change it is to update the source code and redeploy. Only the designated scribes get to update the sacred texts.

When PHP code requests a piece of content by name, the engine checks the read-only store first. If it's there, that's what you get. If not, it falls through to the editable store, fetching from the cloud if the local copy doesn't have it yet. PHP sees a single unified content space. The two-tier architecture is invisible.

The engine also supports directory listing with an optimization for the cloud layer. The first time an admin tool requests a listing of a content directory, the engine synchronizes that directory from cloud storage, pulling down anything not already cached locally. Subsequent listings serve from the local cache. This warm-on-first-access pattern means the admin interface is fast after the initial load, and a fresh server deployment doesn't require any pre-warming step.

The Dynasty Continues

The engine is the foundation, but what gets built on top of it is what I'm most excited about. The next phase is a board admin area where non-technical board members can manage events, upload documents, and maintain the chapter's institutional knowledge through simple forms.

The vision is a content syndication pipeline: a board member fills in the details for an upcoming lecture (speaker, title, date, abstract) and marks it ready to publish. From that single entry, the system updates the website, sends the announcement to the mailing list, and cross-posts to social media. Humans decide what to say. Machines handle where and how it goes.

Beyond events, I'm building a member database that works without a traditional database engine, succession documents so every board role has a living manual for the next person, and eventually automated promotional materials generated from the same structured content. This will be able to ingest the latest spreadsheets, and reveal exactly who we need to reach out to and when. And I am wanting to dramatically improve how we are available to members through various contact channels between meetings. From the outside, I initially had found a couple of unintentional barriers to finding the chapter. These are easy to fix and underway.

I also have some ideas to make things easier for our hardworking vice president. These would be tools to help manage the speaker booking pipeline. She books amazing speakers for us, and it is a lot of work. The idea would be to provide some timesavers for her process, and make it easier for her to transfer and delegate things in the future when she wants to.

All of it will sit on top of the Scribe's Palette. Every document the board uploads, every event they publish, every piece of institutional knowledge they record: it all flows through the same controlled channel, stored as readable files, mirrored to the cloud, and protected by the same validation layer.

The Many Works of the Scribe's Palette Await

Calling the tool the Scribe's Palette was inspired by the late Dr. Clair Ossian's immeasurable contributions to the club and Menhedj newsletter. I know this dedicated group will make sure the club carries into the future, and any investment of time to create tools will be put to good use over many years to come.

Back to Home