• [^] # Re: Wordpress puxore

    Posté par . En réponse au journal Code facétieux dans Piwik 1.9.2. Évalué à 2.

    Je fais faire un peu de promo, mais tes griefs contre wordpress, je les connais. C'est bien pour cela que je suis parti sous Django. Et ceux voulant un CMS, peuvent se tourner vers Django-CMS.
    Alors je ne peux pas répondre à tout, car je ne connait pas tout, mais je peux te répondre pour ce que je connais de Django. Je préviens d'avance que Django est écrit en Python et que donc tous les hébergeurs ne le supporte pas. Mais ayant acheté un Raspberry pi, j'ai pus m'auto-héberger.

    Performance minable hors anglais : .po énorme et utilisation d'une implémentation de gettext en php

    Avec Django, aucun problème avec la langue. Mon site web actuel a le multilinguisme d'activé, mais non traduit. Dans ma version de dev, j'ai tout traduit, et toujours aucun soucis. Les fichiers .po sont d'ailleurs séparés. Django à le sien, et j'ai les miens à raison de 1 par application, ce qui facilite la redistribution d'application. C'est d'ailleurs pour cela que j'ai tapé le fuck à Wordpress. Je refusais de devoir payer 80€ pour avoir le multilinguisme via une application tierce. Et ne parlons pas du multilinguisme natif à Wordpress pour ne pas être vulgaires.

    Performance minable en général à cause du php (chargement de l'appli énorme à chaque requête). Zend limite un peu le problème mais plante aléatoirement sur ma machine

    Aucun problème de performance avec Django, puisqu'étant du Python. Les applications comprennent peu de codes, et en se documentant un peu, on peut encore réduire le nombre de lignes de codes. Mon site avait un peu de mal au début, mais c'était parce que je ne connaissais pas comment régler Apache et que ce dernier me bouffait toutes les ressources du Raspberry pi. À présent, mon site s'affiche rapidement. Et bien sûr, aucun plantage.

    Pas optimisé pour l'utilisation avec un reverse proxy : aucun header lié au cache positionné (Expires…). Au final, tout le monde utilise "WP-Supercache" qui ne résoud que partiellement le problème

    Je ne suis pas sûr de savoir de quoi tu parles, mais ce dont je suis sûr, c'est que Django doit certainement le permettre de base.

    Sécurité à la rache : l'utilisateur est incité à laisser les permissions en écriture sur tout, pour permettre une mise à jour à partir de l'interface web

    Pas de problème niveau permissions. La mise à jour se fait soit par ton gestionnaire de paquets, soit manuelle via l'archive officielle, soit easy-install, soit par pip.

    Chemins en dur de partout : à quoi sert de paramétrer une url racine et d'avoir une bibliothèque d'image si tous les chemins sont en dur dans les posts ? Il est donc très difficile de changer l'url d'un site, d'autant plus que la BDD contient des objets php sérialisés et non des chaînes dans beaucoup de cas.

    Pas de chemin en dur sous Django. Pour tout ce qui est css, images, js, etc., tu règles le répertoire dans le fichier settings.py et l'url qui lui est attribué. Pour les urls des différentes vues (une vue est généralement une page statique ou une page dynamique), tu as une balise {% url lenomdetavue %}, où lenomdetavue est le nom que tu auras donné à ta vue dans le fichier urls.py. Django fera le reste. Pour la BDD, aucun soucis du côté là.

    J'ai beaucoup parlé de Django, mais pour ceux qui ont la flemme de se coder un blog (ce qui prend moins d'une après-midi) ou qui veulent des fonctionnalités sans trop se fouler, il y a django-cms, qui est une application pour django. Car contrairement à Wordpress, on peut installer une application tierce sans que cela foute la merde partout. Donc si vous êtes convaincus, et un peu anglophobes, je vous conseille de commencer par là : Site du zéro : Django
    Et une fois les bases acquises, et si vous voulez un CMS, allez faire un tour ici : Django CMS