With websites, in general, the way you style your content is separate from the content itself and how it’s stored.
Unfortunately, we’re converting an existing site from WordPress to a hand-crafted, steam-powered one so things are a bit more entangled than usual.
The first and most obvious step is to create a page with as much info in different possible styles in it as a test bed. Done that, apart from the inline images. That’s a bit of a faff, so I’ve paused at that point.
Then, export that page as text-only HTML and delete all of the WordPress guff. Create a new styles.css file, and incrementally re-add styles to it – again, excluding all the WordPress guff around block editor styles. It takes time, but it can all be done locally – no need for web space here.
Structure
The next step – actually – a step alongside – is to look at the file structure.
I found my original Acquis website, believe it or not, and the file structure I used to employ in those days was… interesting. But, relevant to today.
My styles.css file will sit in the root directory, alongside index.html. But what of the rest of the structure?
Images and video can obviously go into a media directory, with further subdivision if required – WordPress doesn’t, except by year and month. The templating files could go into a template folder, which has the benefit of being obvious.
But the content? Well…
It could go into a content folder. Simple enough. But… I need to maintain the four-category approach I have at the moment. I say “at the moment” because it might change one day, and I need to be flexible.
Making each category a top-level folder means that “content/” won’t appear in every URI. In the grand scheme of things, not the biggest issue I’ll face but still worth considering.
I’ll also need a scripts folder, of sorts, because I will inevitably have to make use of some php or jQuery along the way. I’d like the index pages to be automatically generated, for example. Or listing content by tag. Getting tags into content is fairly simple, listing content by tag is much harder without a database.
Inputs
Which raises another issue. How will I write pages in the future? This content was written in Word; how do I convert that to a valid web page, with a common footer and a mostly common header (bearing in mind I need a <title> tag and a <meta name=”description”> tag, plus whatever I do for tags?
Could I create a script that runs locally, that builds the web page on the fly for me? Probably not.
Can I find one and adapt it to suit my needs? Who knows.