Content and software are seperate. Were talking about content and not the software. Sure you fix the flaw in the software that allowed the expliot or the weak password or however the site was taken over, but it is a seprate issue.
They are separate in the PHP software that gets targeted by "the vast majority of hacks". Those hacks are against popular CMS packages that can be scanned for and exploited in an automated fashion. In a CMS, the software being exploited and the content are separate, in PHP as every other language.
The PHP files where the content and the system are one and the same (hand written pages not using a packaged CMS) aren't part of "the vast majority of hacks" category. Compared to exploiting a WordPress vulnerability in 50+ million installs, someone trying to mess with the black box that is someone's custom written page happens insignificantly rarely. Your retort doesn't hold water.
> The PHP files where the content and the system are one and the same (hand written pages not using a packaged CMS) aren't part of "the vast majority of hacks" category.
Speaking from experience, this is simply not true. There are automated scanners in the wild which will attempt to detect and exploit common vulnerabilities in simple PHP templating systems and CMSes. One frequently exploited vulnerability is in applications which use URLs of the form:
index.php?page=foobar
With supporting code along the lines of:
$page = $_GET["page"]; /* if register_globals isn't set */
include("pages/$page.html");
Until relatively recently, when PHP started rejecting filenames with embedded null bytes, code like this was vulnerable to input such as:
