On Thursday, October 9th, 2025 at 8:22 AM, Dick Steffens 
<[email protected]> wrote:

> On 10/9/25 07:33, Paul Heinlein wrote:
> 
> > 1. Assume that the church staff or another volunteer will at some
> > point take over site management,
> 
> 
> I've definitely thought of that.
> 
> > so document EVERYTHING and then
> > train at least one other person on site basics. Document all
> > questions raised during the training and their answers. Did I
> > mention documentation?
> 
> 
> +1 on documentation. Not sure who else will be able to pick up on it. At
> least one member has a son who works in IT, so he might be a good choice.
> 
> > 2. Make sure the documentation includes any and every customization
> > you configured into your site, whether it's installing a plugin,
> > changing variables in some PHP code, adding images or photos, etc.
> 
> 
> Definitely understood.
> 
> > 3. WordPress and its plugins have a long, long history of security
> > vulnerabilities and exploits. Devise and document a plan for
> > keeping track of WP security issues and the exact steps necessary
> > for remediation.
> 
> 
> Where do I keep up to date on those things? Is there a WP forum or some
> such?
> 
> > 4. Once more: document and train. Document and train. The number of
> > congregational IT projects setup by well-meaning volunteers that go
> > orphaned and unmaintained when the volunteer becomes unavailable
> > exceeds the number of dead Assyrian soldiers left outside Jerusalem
> > during Hezekiah's reign. If you care for your congregation enough
> > to get this site up and running, then also take care that it can be
> > well and lovingly maintained when you are (for whatever reason)
> > unavailable.
> 
> 
> Understood. Back before 2016 I produced a site with mostly hand coded
> PHP and HTML. Then someone decided to have an outside party do the job.
> She just decided she's no longer doing websites, which is why I'm
> looking into learning WP. Plus, we need to figure out what the look and
> feel needs to be, and produce a bunch of new photos. Big tasks. Sigh.
> 
> Thanks for all your recommendations. I made some progress yesterday, and
> have a little bit better understanding of how to proceed.
> 
> --
> Regards,
> 
> Dick Steffens

If this site is small enough and updates are infrequent (weekly updates count 
as infrequent in terms of web services) then you could probably look at the 
problem from a different angle. 

A Static Site Generator might be enough for this organization. This would solve 
a lot of the problems with security since your web host only has to serve plain 
HTML/CSS and maybe simple javascript. The flow of updating the website would 
also be easier for less technical people to wrap their head around. You still 
need to document it as others have mentioned, but the flow would basically look 
like this:

1) make the edit
2) re-generate site/page
3) upload to server

This can all be automated. And since the generator is not an online program you 
don't need to be paranoid about security.

This also eliminates the need for a database. Full blown CMS systems like 
wordpress are generally best if you want to have multiple people updating a 
blog at the same time. But if just one person is responsible for updating the 
website (As is often the case for small orgs) then you can greatly simplify the 
rollout with tool that doesn't need a full LAMP stack.

Just a thought. Not sure how big or active this church group is. 
-Ben

Reply via email to