▲ | entrepy123 15 hours ago | |
# Regarding Option A: HTTP basic auth to gate access to an admin PHP page that contains a custom form that lets one make the required changes makes sense to me. I've done it for some (recent) microsites where I didn't want more technical overhead than it was worth (or where I didn't know how to do better more easily). The worst that will happen is the web host's PHP gets upgraded and breaks the site, and a computer person has to go in and fix the PHP (maybe with a little help from an LLM). Or, the PHP was insecure and the site gets hacked, in which case I hope the web host had auto backups turned on set at a suitable cadence. Either generate static HTML files, or render as PHP files that read from a single SQLite db file. No RDBMS dependencies. The PHP writing and reading the SQLite may get updated and break some scripts in the future, but LLMs may be able to fix it even. One more concept, I stage my rollouts. So, I edit as admin from PHP form, then I can check the changes in the admin section's viewing page to make sure it all looks good. Then, once satisfied, I can promote the updated changes to the publicly visible section. This may be too much effort for your workflow/users, but it gives me peace of mind that I never royally mess something up with this process. I usually don't preview my changes, since I am now confident my scripts work. But I make this available to myself in case I make some weird changes. # Consider Option B: Think about DokuWiki as a CMS. Make the pages the site needs. Make a Sidebar page for navigation. Make the settings work for the site. Assign users to admin and editor roles that can edit/create pages and upload media (your PDF calendars) as they require. Make user accounts so only your club can read certain pages, etc. I think that should be really stable over time. No database to think about. All site content is stored in a hierarchy of files, which could be backed up and restored to a fresh DokuWiki install if ever needed. For Calendar, I would run a separate system though, and link to that (or embed that). I imagine there is at least one decent FOSS PHP calendar system available, probably available on cheap hosting and installable through cPanel/Softaculous. If the Calendar ever gets borked, I would just forget about any entries on it, reinstall a fresh Calendar solution, and let required entries get re-made. # As for hosting I would pick a "fast" (NVME), inexpensive, and trustworthy web host for the main site and for the Calendar system. Last I checked, r/webhosting was making good recommendations in this regard. |