A Backup Restore Is Not a Backdoor: A Carabin Law Website Story

This is the technical companion to my article about autism, trust, and why I would rather drive a school bus than return to the management environment I experienced at Carabin Law.

This article is different.

It is about WordPress, access, backups, passwords, software licenses, and what happens when technical responsibility and technical authority stop matching.

It is also about a word that has a specific meaning in technology: backdoor.

I was later accused of placing “back doors” and “traps” in websites to maintain unauthorized control.

I dispute that allegation.

What I actually did during one of the most important website incidents was much less dramatic.

I called the hosting company.

The access problem existed before the website failed

While I worked at Carabin Law, my WordPress administrative access was reduced even though I was still expected to help maintain and troubleshoot the website.

The firm had hired a Director of IT. At the time, my understanding was that he was still in school for cybersecurity and that the IT department effectively consisted of him.

My concern was not his title or the fact that he was still learning.

Everyone learns.

My concern was that greater authority over a production website was being given to someone who, in my experience, had very limited practical WordPress administration and recovery experience.

I had already warned him not to interrupt the update

Before the failure, I had explained how the WordPress and Elementor update process needed to be handled.

One of the basic instructions I give anyone who wants to perform their own updates is simple:

I had specifically warned him to wait for the update to complete.

During an Elementor update, he refreshed the page anyway.

The website then went into a WordPress critical-error state.

I do not think one mistake proves that someone is incompetent.

Websites break. Updates fail. Plugins conflict. Developers make mistakes.

The issue was what happened next.

The person with the authority did not know how to recover the site

I was sent a screenshot of the WordPress critical-error message.

I explained that the problem was extremely difficult to resolve without administrator access.

Later I wrote:

That was the contradiction.

I was still expected to recover the production website, but I no longer had the normal application-level authority required to do it.

So I used a different layer of the system.

The website came back because the hosting company restored a backup

WordPress is not the entire system.

The website lived on a hosting platform.

The hosting provider maintained backups.

Because I did not have enough WordPress access to perform the recovery normally, I contacted the hosting company's technical support and asked them to restore the previous day's backup.

They restored it.

The website came back.

There was no secret WordPress account involved.

There was no exploit.

There was no hidden login.

There was no magical access path.

I simply knew that the website had another recovery layer below WordPress.

The messages afterward made the situation even clearer

Once the site returned, the Director of IT wrote:

I did not explain at the time that hosting support had restored the previous day's backup.

I was focused on getting the site working again.

To me, those messages demonstrated the larger operational problem.

He had the authority.

I had the recovery knowledge.

And once the site failed, the firm still needed the person whose access had been reduced.

Then came the “backdoor” accusation

After I resigned from Carabin Law, I received a payroll email accusing me of creating “back doors” and “traps” to maintain unauthorized control over the websites.

I dispute that characterization.

A backdoor, in normal security terminology, is a mechanism that bypasses ordinary authentication or access controls.

Asking the authorized hosting provider to restore its own backup is not the same thing.

In fact, I used that method because my normal WordPress access had been restricted.

That distinction matters to me because technical language can sound frightening when it is used imprecisely.

“Backdoor” sounds like hacking.

“I called the hosting company and asked them to restore yesterday's backup” sounds much less dramatic because it is.

Password practices were another source of disagreement

I also used unique passwords for accounts assigned to me.

I was questioned about why I did not use what was described as a master password.

I disagreed with that approach.

If the same credential is reused across multiple systems, one compromised password can expose more than one system.

Shared credentials can also reduce accountability because it becomes harder to determine who performed an action when multiple people use the same access.

My preference was simple:

• unique credentials,
• least privilege,
• clear account ownership,
• and enough access for the person actually responsible for the system.

I considered that especially important for a law firm handling sensitive information.

Disconnecting my licenses did not mean destroying the websites

Some of the commercial software used on the websites was licensed through accounts that belonged to me.

That included Elementor Pro and BPS Pro.

These were licenses I could use on websites I actively worked on.

When my employment ended, I remember giving the firm some time to obtain licenses of its own, although I no longer remember the exact timeframe.

After that, I disconnected my licenses from websites I no longer managed.

A software license and the software installation are not the same thing.

Disconnecting my license did not delete the site.

It did not erase Elementor layouts.

It did not delete the domain.

It did not create a secret future failure.

It meant that a site I no longer worked on could no longer continue relying on my personal commercial license.

Good offboarding should make the former employee unnecessary

I also remember being contacted after I left by at least one employee asking about a password.

I do not remember enough of that exchange to characterize the reason for the request, so I will not speculate about it.

But it reinforced a principle I still use today:

Accounts should be transferred.

Credentials should be rotated.

Company-owned licenses should be in company-controlled accounts.

Personally controlled licenses should be replaced.

Hosting, domains, analytics, Search Console, WordPress access, and other administrative systems should have documented ownership.

Years later, I can still see two different development philosophies

I still use essentially the same core WordPress philosophy across the websites I build.

I prefer a relatively lean stack.

I try to avoid overlapping plugins when one well-maintained tool can do the job.

I want clear ownership of licenses and accounts, dedicated SEO tooling, analytics, caching, security, and accessibility built into the site rather than treated as an afterthought.

When I reviewed the publicly delivered source code of another website I built for the same organization, Together We Will Rise, in September 2026, I could still recognize that architecture.

The site still exposed The SEO Framework, Elementor and Elementor Pro, Google Site Kit, Microsoft Clarity, and LiteSpeed Cache.

The current Carabin Law website has moved in a much heavier direction. Its publicly delivered source exposed All in One SEO, MonsterInsights, Google Site Kit, Elementor, Essential Addons for Elementor, Jeg Elementor Kit, MetForm components, Smush, WPtouch, and additional WordPress tooling.

None of those plugins is automatically bad.

My criticism is architectural.

Every additional dependency becomes another thing that must be updated, secured, tested, maintained, and checked for conflicts.

Web design and web development overlap, but they are not the same thing

Visual design matters.

I care about layout, branding, photography, usability, and presentation.

But a website is also a system.

• semantic HTML,
• keyboard access,
• SEO,
• security,
• privacy,
• account ownership,
• hosting,
• backups,
• structured data,
• analytics,
• performance,
• maintenance,
• and disaster recovery.

When I look at the current Carabin Law implementation, my opinion is that it reflects a more design-led and plugin-led WordPress approach than the development approach I use.

That is not a statement that visual design is unimportant.

It is a statement that the visual layer is only one layer.

Installing an SEO plugin is not the same thing as doing SEO

One current team biography provides a simple example.

The current site uses All in One SEO.

Yet a substantial employee biography currently uses the generic description:

The actual biography contains far more specific information than that description.

That is why one of my basic rules remains:

The same principle applies to accessibility

A website does not become accessible because it looks polished.

When I later spot-checked the current Carabin Law site with accessibility testing tools, I found alerts involving accessible names, keyboard access, and elements requiring contrast review.

I am not claiming that one automated test proves that every page fails every accessibility requirement.

Accessibility conformance requires broader testing.

But those issues are another reason I treat accessibility as part of development rather than something added after the visual design is finished.

My own approach is to build around WCAG principles from the beginning, including semantic structure, keyboard access, accessible naming, contrast, focus behavior, and responsive use.