web-dev-qa-db-fra.com

Comment verrouiller une ancienne installation wordpress que je n'ai pas l'intention de mettre à jour?

Je commence un nouveau blog wordpress et ne mets plus à jour un ancien. L’ancien reçoit encore 400 à 500 visites par jour, donc je voudrais le garder à des fins d’archivage, car les gens sont toujours liés à ses publications. De toute évidence, le problème est que WordPress et les plugins seront mis à jour, et je n’ai aucune envie de le maintenir. Comment puis-je verrouiller l'installation de wordpress afin de ne pas avoir à la maintenir? J'ai déjà vu quelqu'un suggérer de créer une version statique qui ressemble à beaucoup de travail. Une solution plus raisonnable à laquelle j'ai pensé consistait à désactiver l'accès en écriture à la base de données au niveau utilisateur. Je vais bien avec désactiver les commentaires à partir de maintenant.

Ne hésitez pas à partager des pensées ou des commentaires à ce sujet.

Merci d'avance.

archivessecurityupdates
6
Relequestual

Avec un CMS dynamique comme WordPress, il n’existe aucun moyen réel de le "verrouiller". À mesure que le Web évolue, des failles de sécurité jusque-là inconnues sont découvertes et corrigées dans de nouvelles versions. En réalité, sauf si vous utilisez toujours la dernière version de WordPress (actuellement la version 3.0.4), votre site est en quelque sorte vulnérable. Si vous n'avez pas l'intention de le mettre à jour à nouveau, la création d'une version statique est la meilleure et la plus sûre des options - pas "conversation folle.

Une possibilité forte consiste à utiliser un plug-in de mise en cache et à définir le cache pour qu'il n'expire jamais. Le plug-in créera automatiquement des versions statiques de vos pages selon leurs besoins. Vos liens continueront de fonctionner et les personnes seront dirigées vers les versions HTML statiques de chaque publication et page plutôt que vers les versions dynamiques, générées par une base de données.

En générant une version statique, vous n'aurez plus à vous soucier des mises à jour de base de données, des mises à jour WordPress, des mises à niveau de plug-ins ou des nouvelles versions de thèmes. Cela ne nécessite aucun entretien, mais est également "gelé" dans le sens où les commentaires ne fonctionnent pas et vous ne pouvez pas ajouter de nouveau contenu ... ce qui est probablement bien dans ce cas.

Une autre solution consiste à maintenir le dynamisme et à externaliser la tâche de mise à jour de votre site. Demandez à quelqu'un comme WordPress.com d'héberger le site et de pointer tous vos liens vers cette version du site. Le service hébergé (en particulier celui-ci) aura toujours les derniers correctifs de sécurité sans aucune intervention de votre part.

4
EAMann

Salut! Je pense que votre question est vraiment utile car elle représente un scénario très valable et clair.

La portée de votre question est importante:

  1. accès en écriture désactivé à la base de données.
  2. Je vais bien avec désactiver les commentaires à partir de maintenant.

Le deuxième point n’est pas très important pour ma réponse, car vous pourriez probablement comprendre le contenu de l’utilisateur comme "votre" contenu.

Tant que vous utilisez mod_rewrite pour afficher votre blog (, Pretty Permalinks est la devise du monde wordpress), vous avez le pouvoir de terminer rapidement tout en conservant votre blog en entier.

Ce que je suggère est de faire une copie statique de votre blog en utilisant une technique très fondamentale d'hébergement Web/php/statique. Il utilise essentiellement les avantages de l'abstraction via les serveurs Web/HTTP: le navigateur ne se soucie pas de savoir si vous exécutez une application Web plus longtemps (ici: blog wordpress) ou si le serveur Web ne sert que des pages statiques.

Wordpress a déjà intégré cette fonctionnalité. Tout fonctionne au niveau du serveur dans httpd.conf ou .htaccess:

Le serveur Web vérifie si le fichier existe. Si tel est le cas, le fichier statique sera renvoyé. Sinon, il appellera wordpress à la place. Si vous comparez cela au réglage standard de wordpress .htaccess pour de jolis permaliens:

RewriteBase /blog/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]

Vous pouvez voir que le fichier et le répertoire inexistants sont d'abord vérifiés. Imaginons maintenant qu'index.php ne renvoie pas simplement le contenu des emplacements demandés, mais qu'il enregistre le contenu en tant que fichier dans le système de fichiers, ce à quoi les vérifications précédentes auraient retourné la valeur TRUE, afin de servir le fichier statique à la place. d'appeler la webapplicaiton.

La magie est donc déjà présente. Une fois existant, il s'agit d'un "cache" qui n'expire jamais tant que vous n'avez pas supprimé les fichiers statiques.

Ce principe est d'ailleurs très ancien. Il est connu pour être le "moyen PHP" par certains. La première requête génère la page complète, la seconde requête n'aura probablement même plus besoin de mod_rewrite. Ce n'est rien que j'ai inventé non plus, oh mec, j'ai adoré ce document de Ralf S. Engelschall datant de décembre 1997 , cherchez À la volée Content-Regeneration:

Régénération de contenu à la volée

La description:

Voici une caractéristique vraiment ésotérique: les pages générées dynamiquement mais servies statiquement, c’est-à-dire que les pages doivent être livrées sous forme de pages statiques pures (lues depuis le système de fichiers et qu’elles viennent de traverser), mais elles doivent être générées dynamiquement par le serveur Web si elles sont manquantes. De cette façon, vous pouvez avoir des pages générées par CGI qui sont servies de manière statique à moins qu'un (ou un cronjob) ne supprime le contenu statique. Ensuite, le contenu est actualisé.

Solution:

Cela se fait via les règles suivantes:

 RewriteCond %{REQUEST_FILENAME}   !-s
 RewriteRule ^page\.html$          page.cgi   [T=application/x-httpd-cgi,L]

Ici, une demande à page.html conduit à une exécution interne d'un page.cgi correspondant si page.html est toujours manquant ou a la taille de fichier null. Le truc ici est que page.cgi est un script CGI habituel qui (en plus de son STDOUT) écrit sa sortie dans le fichier page.html. Une fois exécuté, le serveur envoie les données de page.html. Lorsque le webmaster souhaite forcer une actualisation du contenu, il supprime simplement page.html (généralement effectué par un cronjob).

(cité dans le document lié, il suffit de le chercher)

Donc, fondamentalement, avec cette approche, vous pouvez résoudre votre problème. Si vous obtenez une couverture 100% URL et que tous vos documents sont générés, vous pouvez même éteindre mysqldb. C’est quelque chose que je souhaiterais obtenir: une version complète et statique de votre site Web. Cela rend même très facile la migration vers un serveur "archive", donc certains serveurs servent juste à la tâche.

Comment se figer en statique avec Wordpress?

Voici un peu de code qui injecte "sortie sur disque" dans n'importe quelle application basée sur PHP. N'hésitez pas à l'utiliser pour ce que bon vous semble:

class htmlCached {
    static $instance;

    public static function bootstrap() {
        $file = $_SERVER['REQUEST_URI'];
        if ( '/' == substr($file, -1)) {
            $file .= 'index.html';
        }
        $self = dirname($_SERVER['PHP_SELF']).'/';

        if ($self != substr($file, 0, strlen($self))) {
            return;
        }

        $local = substr($file, strlen($self));

        // var_dump($file, $local, $self, $_SERVER);
        self::$instance = new htmlCached($local);
    }

    private $_file = '';
    public function __construct($file) {
        $this->_file = $file;
        ob_start(array($this, 'callback'));
    }
    public function callback($buffer) {
        $file = $this->_file;
        file_put_contents($file, $buffer);
        chmod($file, 0644);  // octal; correct value of mode
        return $buffer;
    }
}

Vous aurez peut-être besoin de cela pour que Wordpress l’adopte un peu (car ce n’est pas à partir d’une installation WordPress), mais en gros, il a tout ce dont vous avez besoin:

  1. wp-config.php est un tout premier point d’entrée, vous pouvez aussi pirater index.php pour une approche plus directe. Injectez la définition de la classe dans index.php. Index.php est ce que l’on appelle le contrôleur frontal pour la plupart des problèmes.
  2. ajoutez un htmlCached::bootstrap(); devant. cela fera le travail. Le travail est le suivant:
    1. htmlCached activera la mise en mémoire tampon de sortie avec une routine de rappel.
    2. l'application fonctionne normalement
    3. htmlCached voit quand l'application s'arrête (c'est-à-dire, quand Wordpress a tout fait, c'est une application assez stupide, vous pouvez donc faire ces astuces)
    4. À l’arrêt, htmlCached enregistre la réponse du serveur sur le disque (à côté de l’envoyer au navigateur).
    5. Apache servira le contenu statique à la demande suivante.

C'est donc facile pour le moment. Ce que vous devez vérifier avec wordpress sont des fichiers CSS, des scripts JS et probablement des images/fichiers (multisite!).

Si vous n'exécutez pas de plug-ins de mise en cache multisite ni compliqué, vous serez peut-être déjà prêt.

Vérifiez quels fichiers/URL ont été demandés pendant la durée de vie de votre site. Construire une liste, demander tous les fichiers une fois. Travail accompli.

Supprimez ensuite tous les fichiers .php.

Tuez la base de données.

Vous venez de geler votre site.

Si votre structure Permalink ne s'est pas terminée en .html pour tous les liens, je vous suggère d'enregistrer tous les fichiers au format .html (.html ajouté à la demande), puis de configurer le fichier .htaccess en conséquence. Donc, pour vérifier REQUEST-URL + .html pour -f et s’il n’existe pas, exécuter htmlCached WP (qui ajoute également .html au nom du fichier, si ce n’est pas déjà dans mon exemple de code ).

Bonne implémentation. Sauvegardez d'abord (comme d'habitude). Pour les tâches de migration, vous pouvez rendre votre base de données en lecture seule en définissant les droits correspondants pour l'utilisateur MySQL. Je le ferais entre les deux, vous n'avez donc pas besoin de vous dépêcher pour le mettre en œuvre. Par exemple. rechercher toutes les URL demandées depuis environ 10 ans peut être un défi et peut prendre un certain temps.

6
hakre