WordPress le retour

Il y a huit mois, j’ai annoncé que je laissais tomber la plateforme de blog de Tumblr pour passer à Wintersmith.

Aujourd’hui, je suis bien obligé d’avouer que je change à nouveau d’outil de blog pour finalement passer à… WordPress.

Pourquoi quitter Wintersmith ?

Wintersmith aura été presque parfait en tout points :

  • Il m’a permis de bidouiller, d’explorer et tester de nouvelles choses, c’est comme ça que je me forme
  • C’est un système très simple, rapide, basé sur markdown parce que je ne peux plus m’en passer
  • Il me permet d’être totalement maître de mes contenus, ne pas les perdre dans les limbes du cloud n’importe quand
  • Et surtout il est devenu inutile pour moi de devoir patcher toutes les 5min mon blog pour des failles ou des mises à jour

Alors pourquoi WordPress à nouveau ?

L’énorme point noir de Wintersmith est le déploiement, qui n’est tout simplement pas prévu.
Il est donc nécessaire de passer par FTP ou de configurer plusieurs outils conjointement. Ce dernier point est particulièrement gênant car je suis susceptible de rédiger et publier de différentes manières possibles (bureau, maison, tablette, smartphone).

D’autre part, je regrette amèrement le manque de fonctionnalités par défaut (recherche, commentaires, articles connexes, partage sur les réseaux sociaux, etc.) et le manque de convivialité (« human friendly ») de l’outil : au final Wintersmith ne m’a pas vraiment facilité la vie au quotidien.

Je me suis donc penché une nouvelle fois vers les solutions telles que Ghost, Tumblr, WordPress, Kirby, pluXML, Jekyll / Github pages, et un certain nombre de cette liste de générateurs statiques.

Mon souci principal étant que je ne souhaite vraiment pas être ennuyé par de mises à jour, ou des patchs à effectuer régulièrement.

En re-découvrant StackEdit, et ses fonctionnalités de publication, mon choix s’est alors tout naturellement porté vers une solution hébergée sur les serveurs de WordPress.com.

StackEdit ?

Cela fait un petit moment que j’utilise sporadiquement StackEdit pour rédiger mes billets. Couplé à un blog WordPress, je sens qu’il va devenir mon meilleur ami :

  • Rédaction de billets en Markdown ♥
  • Interface très agréable (meilleure que d’autres outils du même type, selon moi)
  • Rédaction en mode offline
  • Synchronisation (et sauvegarde) des billets sur Dropbox, je conserve donc chaque fichier .md toujours sur moi
  • Publication directe dans WordPress (avec modifications ultérieures possibles), plus besoin de FTP ou de s’arracher les cheveux.

Ce billet en est un bon exemple. Il a été rédigé en plusieurs fois, depuis plusieurs sources différentes. Le fichier est automatiquement synchronisé sur Dropbox, et sa publication sur le blog s’est faite en un clic.

La contrepartie

Mon choix de blog hébergé sur wordpress.com empêche malheureusement la modification des permaliens et la possibilité d’URL-rewriting.

En clair, mes anciennes adresses de billets n’existent plus, mènent vers une 404, et ne peuvent pas être dirigées. Sauf si vous avez une super idée à me communiquer !

16 réflexions au sujet de « WordPress le retour »

    1. J’ai déjà un fichier txt avec la correspondance des URL, mais je ne sais pas trop quoi en faire : je n’ai pas trouvé comment sur un site hébergé sur wordpress.com

      1. Et une presta personnalisée ? Une solution serait de trouver un prestataire en freelance qui facturerait par exemple sous la forme d’un forfait annuel pour la maintenance plus des rallonges pour les demandes particulières. Ce sera certes plus cher que les grosses plateformes.

      2. De toute manière WordPress.com est une solution de bonne facture.
        Ça tiendra bien, euh, six mois ? :p

  1. Et j’ai aussi perdu tes articles/test de Lab.goetter.fr maintenant redirigé vers Codepen.

  2. J’ai lu les commentaires mais je souhaitais à mon tour partager mon indignation :

    « WordPress.com c’est le mal, faut auto-héberger surtout quand c’est ton job »
    Voilà, c’est fait, je peut maintenant vivre en paix…

    Plus sérieusement c’est pas si problématique que ça les patchs, MAJ, etc… tu peux régler ça en automatique.

    Quand aux failles… selon ton hébergeur tu peux avoir des backup régulières, sans compter celles faites par des plugins comme ceux qui export ton site tout entier vers dropbox (ou par mail).

    Bref, même si tu as une faille, une bien béante, tu ne perdra pas ton site (et je sais que tu le sais). AU BUCHER L’HÉRÉTIQUE ! 🙂

    1. Merci pour ton retour.
      Mais du coup :
      1- non, ce n’est pas mon métier
      2- j’ai beaucoup de mal avec les « il faut »

      Si je suivais tous les « il faut », je ne développerais plus que du Gulp sur VIM avec un Mac et je n’utiliserais plus aucun CMS parce que ce sont tous des usines à gaz.

      Au vu de mes objectifs et contraintes, je suis plutôt satisfait de mon choix pour l’instant 🙂

      1. Bon, j’admets que j’ai fait un grossier raccourci entre « être dev front » et « assurer la sécurité d’un CMS ultra populaire dont le code est open source et les failles sont terriblement destructrices dès lors qu’une est découverte ». ^^

        Faut pas écouter les « il faut », je me suis pris la tête avec Gulp des jours avant de me dire « fuck it, j’achète prepros ». Mais quand je vois les limitations de mon choix (un choix sécuritaire, avec moins de contraintes) je vois aussi ses limites 🙂

Les commentaires sont fermés.