Je manque un peu de temps, mais je voudrais commencer à récapituler les éléments qui compliquent l’aspiration d’un site #SPIP en local (ou en « statique » – utile aussi pour faciliter la sauvegarde d’un site en ligne – site d’archives par exemple). À compléter…
– Rappel, on peut aspirer tout un site d’un coup avec la commande :
wget -r -k -np -e robots=off AdresseDeLaPage▻http://seenthis.net/messages/130117
[Edit] Ajouter -e robots=off, sinon le robots.txt usuel de SPIP bloque les éléments dans squelettes (donc par exemples les webfonts).
– D’abord passer en URL qui se terminent avec les terminaisons .html. Personnellement je préfère simplifier au maximum avec le format d’URL « URLs Objets HTML » (de la forme article1.html…) ; il faudrait faire des essais avec des URL qui provoquent des noms de fichiers en arabe (ou chinois ou ce que tu veux) pour voir ce que ça donne en local sur différents systèmes.
– robots.txt de SPIP est trop restrictif et bloque l’aspiration des fichiers dans /IMG, /plugins, etc. (Perso je vire robots.txt.html.)
▻http://seenthis.net/messages/405944
– Évidemment, les contenus dynamiques et les formulaires (recherche, forums…) sont à éviter.
– Les appels des fichiers cachés (non liés depuis le page HTML). Pour les plugins image_responsive et inclure_ajaxload, j’ai ajouté la constante _SPIP_LIER_RESSOURCES qui, si elle est initialisée à true, va forcer l’insertion de balises <link href…> dans le code HTML :
►http://seenthis.net/messages/374212
– La pagination de SPIP (signalé par @fil je crois).
– Les timestamps ajoutés par SPIP aux fichiers :
▻http://seenthis.net/messages/391910
– Les URL relatives dans les CSS qui sont transformées, après concaténation, en URL absolues pointant vers le site en ligne. Celle-ci est assez casse-pied, parce qu’on ne s’en rend pas compte si on ne coupe pas sa connexion internet lorsqu’on teste les fichiers en local (puisque ça va chercher le fichier qui « manque » sur le serveur distant).
