A Website for the Ages: Egyptology in North Texas

A Temple to Outlive Its Builder

Incantations of the Techno Priests:
- Language: PHP (runs everywhere, easy to hire for)
- Requires server-side capabilities for authenticated admin tools
- Static site wouldn't work (no secure file handling)
- Backup medium: USB drive, updated regularly

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 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 a website service 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.

I wanted to keep this one simple. I chose one of the most widely understood web languages because it runs on virtually every hosting provider. Any competent web developer can pick up this project and understand what it does.

If something happens to me, another board member already has a current backup in hand (never more than two months old) ready to pass to a new tech person. 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

Incantations of the Techno Priests:
- Cloud storage: Object storage (S3-compatible) for durability
- Security: Custom PHP stream wrapper extension written in Go
- Interfaces with PHP's C internals via cgo
- Validates path traversal attacks, whitelists file extensions
- Runs inside web server process (no separate ports/services)

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. Servers come and go. If the server 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 the cloud. 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 storage 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 malicious 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 security layer intercepts all content requests, validates identifiers, rejects sneaky path attacks, and only permits approved file types. The security layer lives inside the web server with no separate entry points to secure. The website code has no idea it exists.

I would not have chosen to build this without AI coding assistance. Having an AI collaborator that could work across multiple technical layers 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

Incantations of the Techno Priests:
- Read-only content: Deployed from source control (git)
- Editable content: Written via PHP file functions, synced to S3
- Two-tier resolution: Check static store first, fall through to cloud-backed store
- Directory listing: Lazy-sync from cloud on first access, then cached locally

Some content should be harder to delete. The chapter's charter, contact information, and structural pages are authored by the developer and deployed with each update. 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 while the site is running. The only way to change it is to update the master copy and redeploy. Only the designated scribes get to update the sacred texts.

When the site 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. The site 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 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

Incantations of the Techno Priests:
- Member database: File-based (no traditional RDBMS), stored as JSON/markdown
- Syndication: Single entry triggers website update, email, and social posts
- Spreadsheet import: Parse CSV/XLSX for member contact data
- All data stored as human-readable files (survives any technology change)

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, succession documents so every board role has a living manual for the next person, and eventually automated promotional materials generated from the same 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