Weekly Wildcat launched its first website back in January 2026. At the time it was just a normal WordPress site. Cheap theme, hosting through 1&1, some random Christmas deal that made the first year cost like $7. For a brand new student newspaper with basically no budget, that was a no brainer. We needed a site, it was cheap, and WordPress seemed easy enough that we could just start publishing.

We spent the whole school year writing articles, posting photos, building out sections, figuring out what kind of paper Weekly Wildcat was even going to be. The problem was the site itself never got any better. We all complained about it constantly. (it was absolutely terrible)

If something on the header broke, I’d have to sit there and wait forever for the admin dashboard to load. Then trying to change something that felt like it should be simple meant digging through random theme files, Elementor settings, and plugin menus that never worked. Switching between pages in the WordPress admin took like ten seconds every time. I guess that’s what $7 gets you

The public side wasn’t much better. Mobile layout was awful, homepage felt generic, Elementor blocks didn’t work consistently and sometimes just didn’t show up at all. Lists would randomly turn into checkboxes for no reason (drove us insane). Changing the header, footer, basically any big layout piece meant digging through files and settings until something finally moved.

It sucked.

There aren’t many things worse than the Netherlands’ performance in the World Cup, but our website was definitely one of them.

We wanted the site to look like it was made on purpose. Like an actual newspaper, not just a website that happened to have articles on it. But Elementor didn’t give us any real way to manage fonts without paying for more features, and the theme wasn’t built in a way that made typography easy to touch. We’d try to make what felt like a pretty normal design change and the whole thing would just start falling apart. I remember editing a config file once to fix a layout issue and the entire homepage just disappeared.

At some point it was obvious we were spending way more time fighting the website than improving it. So we decided it was time to just rebuild the whole thing.

we tried to stay in WordPress first

Our first idea was to build a custom WordPress theme. That lasted for a little while.

I figured it’d be the easier path since we were already in WordPress. The articles were there, the media library was there, writers already knew the dashboard, the basic publishing system worked fine. In theory a custom theme would let us keep everything and just replace the parts we hated.

An absolute mess.

I only had a little PHP experience at the time and WordPress themes get complicated fast. Templates, hooks, plugin behavior, theme settings, block behavior, old conventions, new conventions, and then all the little stuff that only becomes obvious once something breaks. I got far enough in to realize I did not want to build the future of this site on top of a theme I’d be untangling forever.

So I gave up on that and switched to something I actually knew better, Next.js. The idea was pretty simple. WordPress stays, it just stops being the thing readers actually see.

Instead WordPress becomes the CMS running quietly in the background. Writers and editors keep logging in, drafting stories, uploading photos, assigning categories, scheduling posts, same workflow they already know. But the actual public site gets built separately with Next.js.

That gave us a clean break from the old theme without making the whole staff learn a brand new system.

The site is still WordPress under the hood. It just doesn’t look like it anymore.

the new setup

The new setup is split into two sides now.

The public site is still at weeklywildcat.com, that’s what readers actually see. Built with Next.js, deployed through Cloudflare Workers.

The CMS lives at cms.weeklywildcat.com. That’s the back room of the newspaper now, where stories get written, images get uploaded, author info gets managed, everything gets organized before it goes live.

Here’s the part I still think is kind of funny. WordPress is running in a Docker container on my homelab server. Same server that used to just sit there running Home Assistant for my house. That was legit its entire job before this. Now it’s also quietly running a newspaper’s entire CMS. I got lucky that it’s a fairly nice box with 16GB of RAM so it handles the extra load pretty easily, but it’s still a little weird knowing the paper’s whole backend lives on the same machine that we use to turn off the lights.

It’s exposed through a Cloudflare Tunnel, and the WordPress admin is behind Cloudflare Access too, so it’s not just sitting wide open on the internet for bots to find (hopefully)

Is this more complicated than the old setup? Yes, a lot more.

A normal WordPress site is one thing, you pay a host, install WordPress, pick a theme, done. This has a CMS, a separate frontend, a GitHub repo, Cloudflare Workers, a tunnel, Docker containers, a custom plugin, and deployment logic tying it all together. More pieces. More stuff that can break. More things I personally have to keep in my head.

But there’s also just way more control. The old site gave us a box full of limitations. This one gives us an actual foundation we can keep building on.

trial and error

The first version of the Next.js site was not good. It technically existed but it didn’t feel like Weekly Wildcat yet. Layouts were rough, stuff broke constantly, and the homepage changed practically every day for a while. I redesigned it over and over before it started looking like something I’d actually want people using.

That first week was mostly just trial and error. Build something, look at it, absolutely hate it, change it, break it, fix it, move to another part of the site, repeat. The homepage went through the most versions because that’s the page that matters most, and it needed to feel focused instead of crowded.

The author pages might be my favorite part of this whole redesign. On the old site, authors got a small box with their name (not even a picture) Now authors get their own pages where readers can see who’s writing, browse their other stories, get more of a sense of the actual people behind the paper.

WordPress is great once you stop asking it to be the whole website

One of the biggest things I learned doing this: WordPress was never really the problem. It’s still good at what it does.

For writers nothing really changed. Write a story, add media, pick categories, save a draft, hit publish. No code, no thinking about how the frontend works at all. And we don’t have to deal with Elementor anymore (Thank God — that was a mess)

I still remember opening the rebuilt CMS the first time and clicking between pages, and it was instant. There was a fade transition and I genuinely didn’t know WordPress even had that, because I’d never once seen it not buried under ten seconds of loading.

We also ended up building a custom WordPress plugin, which was its own whole adventure since I’d never built one before and again, pretty limited PHP going in. The plugin handles stuff that doesn’t fit neatly into a default WordPress setup. Image credits, author details, sports info, event stuff. Things a student paper actually needs but that no generic theme or random plugin ever handles well. Building our own tools means the CMS gets shaped around how Weekly Wildcat actually works, instead of us bending our workflow around someone else’s idea of a news site.

verifying our sports data with MaxPreps

We had a lot of raw sports data pulled in from different sources, and we wanted to actually verify it was accurate. MaxPreps doesn’t let you reuse its data directly (it’s against the TOS), but pulling scores from it gave us something to compare against, and that’s how we found and fixed a bunch of issues in the data we already had. I ended up writing a simple script to help with that.

publishing still feels simple

For staff, publishing is still just WordPress. Write a story, add images, fill in the info, and hit publish. Once the public site rebuilds it shows up on weeklywildcat.com.

The images still live in WordPress but the public site itself gets deployed as a static site. That means readers get a way faster experience without us giving up the media library or changing how staff upload photos. It also means the site isn’t generating every page live every time someone visits, readers just get a finished page instead of waiting on WordPress, PHP, plugins, and the old theme to all do their thing at once. Way better fit for a news site.

hello, spam

One of the less fun parts of running a public site is bots find you almost instantly. We got hit with a lot of spam traffic and spam comments, a good chunk of it from outside the US. To be clear that doesn’t mean everyone outside the country is some kind of problem, obviously our reporting should be accessible to anyone who wants to read it. But automated/bot traffic is a way different story.

definitely not the final version

The site now is way better than what we launched with back in January, but it’s still early days. The design system needs more work, there’s still stuff to clean up around consistency and components, and the publishing pipeline needs to get more automatic. The whole setup needs to get easier to maintain in general.

And eventually, honestly, the CMS probably needs to move off the server that’s sitting in my living room under the TV. Hosting WordPress on my homelab is great right now, it keeps costs down and gives us total control, but I’m not going to be running this newspaper’s infrastructure forever. A student paper that depends entirely on one guy’s home server humming away in his house isn’t really a long term plan.

We want the publication to last longer than our time @ NSHS. That’ll probably mean simplifying the stack down the line, moving the CMS somewhere more permanent, making deployment less manual, cutting down the number of moving parts. Probably all of it eventually. Maybe even moving back to a Full WordPress stack.

why the code is open source

The Weekly Wildcat site is open source on GitHub. Right now it’s not exactly plug and play, another school couldn’t just download it, swap a logo, and have a finished site by that afternoon. There’s still a lot of work before it gets to that point.

But that’s the direction I want to take it. Student newspapers shouldn’t have to pick between expensive publishing platforms, ugly templates, or sites that feel impossible to touch. A small student org should be able to have a modern site without a huge monthly bill or a full dev team behind it.

There are already solid low cost and free options out there for hosting parts of a project like this. I use Wasmer’s hobby plan for this blog and it’s worked well, and Cloudflare Pages is a good option too when you need more bandwidth. (note that they serve different purposes)The bigger point is just that schools and student orgs deserve more control over their own websites.

This whole thing is still at the beginning. It’s not perfect and it’s definitely more complicated than buying a theme and clicking install. But it’s ours. WordPress still gives us a solid place to write and publish, Next.js gives us a public site that actually feels designed for Weekly Wildcat, Cloudflare handles deployment and keeps the bots off our backs, and a server that used to just run my Home Assistant install is somehow now also running our newsroom. And we’re finally not stuck trying to force a seven dollar theme to do things it was never built for.