#wordpress

 ?

piratage je pense : j’ai eu les mêmes textes sur un site #Wordpress

Ah oui : ▻https://www.google.fr/search?q=five%20for%20post
Les blogs du Monde, Harvard, InternetActu...

Le titre m’a fait sourire quand même.

ah il faut demander à @fil ou à @simplicissimus de faire le lien avec une conversation en cours sur cette question, je ne sais plus où c’est.

▻http://seenthis.net/messages/477413 mais là encore rien ne prouve qu’il y ait un lien entre un site mal sécurisé et les terabytes fuités

avec pas mal de liens intéressants aussi, notamment ce migrateur #wordpress → jekyll
▻https://github.com/benbalter/wordpress-to-jekyll-exporter

En dehors de la question de la sécurité liée à un site PHP, et sans doute la tenue en charge d’un site à fort traffic, le reste contient des choses que je trouve vraiment discutables.

– Introduire la difficulté de l’invalidation du cache, alors qu’on évoque des sites qui ne changent que rarement, et qu’on va arriver à un site totalement statique (équivalent à un cache qui ne serait jamais invalidé), c’est pas sérieux.

– Je ne vois pas pourquoi un ensemble de fichiers structurés en Makdown serait fondamentalement plus « accessibles », « réutilisables », facilitant les « migrations ultérieures » que les mêmes « contenus enfermés dans une base de données ». Si la base de données à une structure claire, il n’y a vraiment pas grande difficulté à récupérer les données. Qu’il y ait une grosse mode des prestataires à privilégier des systèmes qui permettent de complexifier la structure de l’information dans le but assez évident d’interdire au client de changer de prestataire, n’est pas un argument pour le statique en tant que tel.

– Le passage sur le refus du Wysiwyg (« accessibles et réutilisables »), je veux bien, mais bon -> SPIP a 16 ans et a toujours argumenté très sérieusement sur son refus du Wysiwyg…

– Je suis très embêté sur la non-réponse au fait que si on a des systèmes permettant le dynamique, c’est parce qu’on a souvent besoin de gérer des informations dynamiques : forums, contributions, compteurs de visites, formulaires, etc. La réponse dans cet article ne me convainc pas : le coup des « microservices », c’est une énorme partie de la mode du « Web 2.0 » et de ses startups, qui a facilement 10 ou 15 ans ; je veux une interface pour les cartes géographiques, hop un web-service ; je veux un compteur, hop un Analytics ; je veux un forum, hop, hop, hop… Résultat : pas trop de libre, une énorme concentration des services (Google Analytics partout, forums Facebook, Google Maps pour les cartes prêtes à l’emploi, la vidéo chez Vimeo ou Youtube…). Ici l’article se termine avec un très beau : « Vous avez envie de réagir ? Laissez une mention sur Twitter. » OK.

Un aspect non abordé, c’est je le crains le fait que les sites se referment et que les aspects très « ouverts » qui nous motivaient il y a 15 ans ne sont plus du tout à la mode (qui veut encore de la « publication ouverte » et/ou un comité éditorial décentralisé, gérer des forums sous les articles… ?).

Bref : très d’accord sur l’intérêt de revenir à du statique dans de nombreux cas. Mais certains arguments ici sont problématiques.

Tout à fait d’accord avec @arno sur la plupart des arguments, sauf peut-être sur la crainte de fermeture : les CMS basés sur MySQL (notamment) ne permettent pas facilement d’en décentraliser la production (cf. l’argument, valable, de la difficulté qu’il y a à "passer en prod" des contenus). (Avec SQLite c’est un peu plus facile, mais bof pour la perf.)

Tandis qu’une série de fichiers à plat, gérés sous git, c’est bonnard : c’est du même coup versionné, décentralisé, ouvert à la participation (via les pull-requests), ouvert aux bidouillages (via clonage et donc copie facile des contenus).

La procédure export / import MySQL, avec les documents joints qui ne suivent pas, les identifiants arbitraires, etc, c’est vraiment problématique de ce point de vue. (C’est la raison notamment du raccourci “ressources” qui cherche à faire ce découplage.)

[je parle plus de techniques (bdd vs statique) mais de contenus/philosophie de publication.]
Ça :

Un aspect non abordé, c’est je le crains le fait que les sites se referment et que les aspects très « ouverts » qui nous motivaient il y a 15 ans ne sont plus du tout à la mode (qui veut encore de la « publication ouverte » et/ou un comité éditorial décentralisé, gérer des forums sous les articles… ?).

Je trouve que c’est central. On m’a demandé récemment d’intervenir sur médias et diffusion des savoirs sur le genre. Bon, je vois vraiment une différence fondamentale entre un projet comme les pénélopes (par ex., mais y’en a d’autres) et les blogueuses féministes qui ont la côte en ce moment. La dimension collective et décentralisée étant un des arguments que je vais avancer pour dire que si il y a effectivement une prolifération de lieux de diffusions de savoir sur le genre (on me pose la question, hein) en ligne, cet « esprit du libre » s’est perdu, l’autonomie et surtout effectivement ces comités éditoriaux décentralisés, la démarche collective en somme, a laissé place au personal branding, à la mise en avant de soi, à la non confrontation avec d’autres dans la production du contenu. A cela tu ajoutes l’essoufflement associatif sur les médias tactiques (dont la définition n’est aujourd’hui plus que celle du marketing publicitaire), bon, alors, oui, on va faire des sites statiques en markdown.

Encore une incitation à la féodalité (feudalism), on peut supposer que les bons maîtres de wordpress.com blogger etc trouvent ça moche, mais il est clair qu’ils vont en bénéficier.

#AMP #Wordpress #webperf #mobile

Ikea : Il est encore temps de sauver les meubles en renforçant la législation européenne - [Les eurodéputés Europe Écologie]
▻http://europeecologie.eu/Ikea-Il-est-encore-temps-de-sauver-les-meubles-en-renforcant-la-legis

http://www.greens-efa.eu/typo3temp/pics/8221f83377.jpg

http://www.ecolo.be/IMG/png/ikea_fr.png

Ceci explique cela...
$23 billion

IKEA founder Ingvar Kamprad amassed 362 billion kronor ($46 billion) in wealth before he died. According to his will, half of that money will go to charity in Sweden, with the rest divided among his children.

▻https://qz.com/index/1231168/ikea-founder-ingvar-kamprad-left-23-billion-to-charity-and-businesses-in-sweden

L’image sous http://www.ecolo.be/IMG/png/ikea_fr.png est désormais introuvable. Une idée où la retrouver ?

Réponse : Après le changement du moteur du site (#SPIP -> #Wordpress) les admins n’ont pas respectés les URLs en place. Désormais c’est à l’adresse https://ecolo.be/wp-content/uploads/2016/02/png_ikea_fr.png

N.B. Quel avantage présente WP par rapport à SPIP ? Je ne comprends pas.

https://ecolo.be/wp-content/uploads/2016/02/png_ikea_fr.png

coucou #SPIP

#wordpress #WP #infographie #statistiques

#spip_blog pour troller un peu ? ^^

Thousands more PHP developers will need to become fluent with JavaScript to recreate their admin interfaces in this fashion.

Héhé, j’en connais qui ne seraient pas rassuré⋅e⋅s par ça ^^

#javascript #REST #API #admin #interface #refonte

En plus des technologies derrières, plein d’idées en #ergonomie de l’admin aussi.

C’est surtout une horreur : pour se connecter à un admin wordpress il faut maintenant télécharger plus de 2 Mo de JS et autres trucs, résultat leur admin ne marche plus en 3G vu le temps fou que ça prend à charger. Et comme ça ne marche pas sans JS, impossible de juste recharger la page, ça ne juste marche pas. Bravo les sous-doués. Facile de designer des trucs qui pètent quand on a de la fibre au bureau. Venez vivre dans le reste du monde. Rien qu’ici en Australie les réseaux mobiles et ADSL sont une horreur, et ça le montre vite. Des sites comme CapitaineTrain, tout à base de JS bien lourd, sans fallback, ne marchent juste pas. Quand tu rapporte le problème on te dis gentiment d’aller te faire foutre. Belle idéologie de web accessible… :(

100% d’accord @bohwaz je suis complètement dans cette approche là : ça doit marcher sans Javascript (ce que j’essaye de faire pour toutes mes interfaces dans SPIP, que ce soit en admin ou en public).

Moi ce qui m’intéresse c’est surtout les améliorations d’ergonomie d’admin.

Mais après, avoir comme cœur une API qui sait vraiment tout faire, et que les interfaces (PHP, JS, client lourd sur le bureau, etc), ça me parait quand même une nécessitée aujourd’hui (et ça on l’a pas dans SPIP). Ce qu’il faut c’est que l’interface fournie par défaut ensuite soit vraiment accessible (ce qui n’est pas le cas ici apparemment).

Au sujet de l’accessiblité, en regardant vite faite leur exemple (une app Desktop et non une webapp), je pense qu’il migre vers un model App d’un côté (sur mobile ou bureau) et serveur API de l’autre.

Et quoi qu’il en soit, dans ce modèle le coût de la première connexion est élevé, mais après les données sont réduites au minimum.

Oui pour cette partie là je suis d’accord : que ce soit une application native ou même une webapp JS : dans les deux cas le but est de la télécharger UNE fois quand t’es dans un endroit avec de débit. Et ensuite c’est terminé, il n’y a plus que des interactions de contenus.

The new WordPress.com | scruffian
▻https://scruffian.wordpress.com/2015/11/23/the-new-wordpress-com

For the last year and some, I have been working on a secret project at Automattic. Today this project was released Open Source for the whole world to see.

This has been a fascinating experience; this project has changed a lot of things about the way we work at Automattic. Many of the changes have been technical; this was my first project using Node and React for example. However for me the biggest change is not the technology but the process.

▻https://github.com/Automattic/wp-calypso/issues le nombre d’issue ouvertes en quelques jours est énorme !

À noter que pour ce projet ils parlent intégralement d’open source, jamais de logiciel libre. Et que ce projet a été développé en secret par une petite équipe, avec le code public dans un second temps.

#open_source…

#wordpress #javascript #REST #API #admin #interface #refonte

►http://seenthis.net/messages/432050

l’effet de bord est en fait limité, dans ce cas d’usage une branche #git locale répond à ce besoin.
Une fois le brouillon publiable, on peut le passer sur la branche principale et publier via un push

Pas pareil car les brouillons d’un CMS, quel qu’il soit, ils sont privés ET sur un serveur (sauvegardé régulièrement etc). Alors qu’en local c’est pas très en sécurité.

Ou alors il faut aussi synchroniser/pusher ses branches locales sur un git en ligne, que ce soit un simple dossier en shell ou un truc plus complet genre gitlab privé. Et là ça devrait être bon. :)

je pensais un tag générique pour les autres logiciels aussi .

précision : je suis newbie avec Wordpress... je sais faire certaines choses, mais vu que je ne suis pas une pro du php, disons que je n’ai pas certains réflexes ;)

A voir, à voir... ;)