De nombreux changements depuis la version 1.5.2 sont visibles côté utilisateur, les changements sont impressionnants, tous orientés intuitivité et facilité d'utilisation, grâce à des simplifications d'interface et une bonne dose d'ajaxification (dynamisme façon applications de bureau) :
- Côté rédaction, un éditeur riche a fait son apparition, il est désactivable pour chaque utilisateur, sa zone de saisie est redimensionnable, il est possible de replier toutes les zones de saisies d'un article et la prévisualisation utilise désormais le thème du site, donnant donc plus bas, et après sauvegarde, l'image exacte que l'article aura sur le site.
- Un nouveau système de rôles et de capacités remplace les niveaux des utilisateurs, les développeurs de greffon peuvent ainsi ajouter des capacités liées à leurs nouvelles fonctionnalités.
- Et puis enfin, les méta-données utilisateurs intègrent un champ pour votre adresse Jabber.
- Autre avancée très pratique, chaque image et/ou fichier uploadé par l'éditeur dans un article a désormais une page associée, avec possibilité de les commenter.
- Les thèmes sont prévisualisables grâce à une imagette.
- Deux greffons sont intégrés par défaut : un anti-spam de commentaires et un outil de sauvegarde de base de données.
Le tout est assez bluffant !
La partie cachée de l'iceberg, de très nombreux changements qui ont eu lieu sont invisibles à l'utilisateur, mais certainement pas pour le développeur ou l'utilisateur qui utilise la liberté de regarder sous le capot. Un certain nombre d'ajaxifications, utilisables également par les greffons, permettent une gestion plus souple par glissé-déposé, animations, transparence, etc. Le vrai fun, la partie visible de la communauté particulièrement active de WordPress devrait commencer dans quelques semaines à quelques mois, avec tous les nouveaux greffons et thèmes qui feront leur apparition. Outre la centaine de bugs corrigés, voici une liste de changements visibles et utiles à l'utilisateur, aléatoirement traduits du second lien :
- Couche de données plus abstraite
- Nouveau système d'import
- Redesign du panneau d'administration
- Editeur riche
- Upload de fichiers et/ou images
- Prévisualisation améliorée
- Méta-données utilisateur
- Niveaux d'utilisateurs remplacés par les rôles et capacités
- Prévisualisation des thèmes
- Ajout de catégorie de AJAX
- Gestion de listes en AJAX
- Javascript et images déplacés en dehors du répertoire admin
- Pages d'administration de thèmes
- Suppression des durées de ping
- Cache persistant
- Versionnement de base de données
- Greffons intégrés : anti-spam et sauvegarde de base de données
WordPress 2.0 nécessite PHP 4.2 et MySQL 3.23.23 au minimum.
Aller plus loin
- Le site officiel de WordPress (1 clic)
- Les nouveautés de la version 2.0 (1 clic)
- Téléchargez WordPress 2.0 (0 clic)
- Le site de développement (trac) (1 clic)
- Planète WordPress : les blogs des développeurs (1 clic)
- Liste des plugins compatibles (0 clic)
# AJAX
Posté par blenderman . Évalué à 2.
C'est dommage qu'elle n'ai pas été utilisée plus tôt...! (C'est un peu grâce à google finalement que les choses ont bougé non ?)
Ce qui est bien aussi avec AJAX, c'est que ca va calmer tous les petits 'ingénieur informaticien' qui croient savoir faire un site parce que ils savent utiliser FrontPage ou que sais je d'autre de similaire...
Les webmaster ont encore un avenir !
[^] # Re: AJAX
Posté par Gniarf . Évalué à 10.
[^] # Re: AJAX
Posté par Gabriel . Évalué à 8.
Est-ce qu'on utilise maintenant la bonne méthode?
Je préférerais un bon standard w3c.
[^] # Re: AJAX
Posté par Jean-Marc Leroy . Évalué à 6.
Le bon webmaster doit apprendre à utiliser les "technos ajax" à bon escient : un interface d'administration est l'endroit où le besoin d'ergonomie est le plus criant, et qui a le moins besoin d'être référencé. Un interface de réservation en ligne ou un formulaire un peu compliqué a-t-il vraiment besoin d'être référencé? Par contre, côté compatibilité, c'est clair que c'est plus délicat.
Utiliser Ajax juste pour la beauté du geste ne sert à rien. L'utiliser pour alléger les peines du serveur parce que l'entièreté du contenu n'est pas toujours nécessaire lors de la visite d'une page, c'est déjà quelque chose de plus intelligent.
Sinon, Ecmascript (le nom obscur de javascript) est un standard depuis un bail, non? Je ne vois donc pas où est le problème, sauf à permettre aux utilisateurs dressés à bloquer javascript pour raisons de sécurité de continuer de faire joujou. Dans ce cas-là, pour calmer tout le monde, le mieux est de conserver une porte de sortie moins ergonomique mais garantie sans ajax et sans javascript, sur le côté.
[^] # Re: AJAX
Posté par Éric (site web personnel) . Évalué à 5.
> depuis un bail, non?
Le standard ne définit je crois que la structure du langage, pas les fonctions dispo (en tout cas pas la fameuse xmlhttprequest qui est la base d'ajax)
> Je ne vois donc pas où est le problème, sauf à permettre aux
> utilisateurs dressés à bloquer javascript pour raisons de sécurité de
> continuer de faire joujou.
Je ne vais pas dire que je navigue avec Links, je déteste ça. Par contre il m'arrive tout de même régulièrement de devoir jouer avec par ssh. Et je vais voir deux choses dans ces cas là : des documentations et des interfaces d'administration. Ca me ferait mal que ces dernières imposent Ajax.
> Dans ce cas-là, pour calmer tout le monde, le mieux est de conserver
> une porte de sortie moins ergonomique mais garantie sans ajax et
> sans javascript, sur le côté.
Sauf qu'au niveau boulot ça augmente considérablement le travail
# des pages web de plus en plus complexes ... ajax et le reste
Posté par Mildred (site web personnel) . Évalué à 9.
C'est bien, ca permet un meilleur confort mais je me pose des questions.
A l'origine les pages web n'étaient prévues que pour afficher du texte structuré en titres différents, listes et ... les liens.
Maintenant, avec le même support (les pages HTML) on fait de véritables applications en ligne. Cela me fait une drole d'impression, de détourner un format de fichier pour une utilisation toute autre (cela s'est fait au cours du temps, c'est vrai). Ne serait il pas plus intéressant d'utiliser d'autres méthodes ?
Pourquoi ne pas utiliser des applications client/serveur classiques utilisant par exemple la méthode HTTP PUT ou encore XUl ?
Pourquoi include dans des pages HTML (à l'origine pour présenter des informations de manière structurée) des interfaces de plus en plus complexes ?
D'autant plus que Javascript n'est pas vraiment le même sur tous les moteurs Web ... Le javascript Gecko est différent de celui d'Opera ou de KHTML ... et encore plus de celui de Microsoft, non ?
Je me demande alors si il est vraiment intéressant d'utiliser le support HTML, même si a l'heure actuelle, on ne peux pas trouver mieux.
[^] # Re: des pages web de plus en plus complexes ... ajax et le reste
Posté par dragoonway . Évalué à 7.
Dites moi si je me trompe, mais AJAX est bien basé sur les standards de programmation dictés par le W3C, donc il est compatible avec tous les navigateurs (du moment que le programmeur respecte ces règles) ?
[^] # Re: des pages web de plus en plus complexes ... ajax et le reste
Posté par gasche . Évalué à 2.
tous les navigateurs... qui respectent les standards !
Je sais pas si c'est comme pour XHTML/CSS, mais traditionellement ca fait pas beaucoup :)
[^] # Re: des pages web de plus en plus complexes ... ajax et le reste
Posté par Éric (site web personnel) . Évalué à 10.
Ecmascript est normalisé par ... l'Ecma (d'où le nom), pas le W3C.
Par contre le W3C peut tout à fait normaliser certaines API qui seront utilisables entre autres par javascript. C'est le cas de DOM par exemple.
Pour ajax : pas mieux. La méthode xmlhttprequest() qui est finalement la seule partie technique du modèle Ajax n'est pas normalisé par le W3C à ma connaissance.
> dictés par le W3C, donc il est compatible avec tous les navigateurs
Euh .... là même dans mes rêves les plus fous je n'y ai jamais cru.
Puis les navigateurs sont des logiciels comme les autres. Ils peuvent respecter des normes quand ils font des choses, mais n'implémentent pas forcément tout (ni tout de suite), voire implémentent différement quand ils ont une bonne raison de le faire.
Ce n'est pas parce que le W3C (ou un autre organisme de normalisation) fait passer une spécification par un processus de publication que d'un coup ça marche partout. Ca n'est pas le cas et ça ne le sera jamais.
[^] # Re: des pages web de plus en plus complexes ... ajax et le reste
Posté par Mathieu Pillard (site web personnel) . Évalué à 5.
C'est vrai mais ca change:
http://www.w3.org/2006/webapi/
Tant qu'on est a parlé de ca, ya un groupe dont on entend peu parler mais qui amha est plutot interessant, c'est celui qui s'occupe des web services: http://www.w3.org/2002/ws/
[^] # Re: des pages web de plus en plus complexes ... ajax et le reste
Posté par dragoonway . Évalué à 1.
En gros, je voulais justement faire remarqué que même les "recommandations" de programmation, dans quelque langage que ce soit perdent de leur sens lorsque l'on quitte le terrain du commun. Ou autrement dit AJAX est encore balbutiant et cherche son terrain de jeu.
[^] # Re: des pages web de plus en plus complexes ... ajax et le reste
Posté par Guillaume DESRAT . Évalué à 8.
D'ailleurs, même si je me suis mis à "mettre de l'AJAX" dans ce que je fais, je me pose toujours cette question : la masse totale de données qui vont être téléchargées (la page HTML, les fichiers Javascript, les feuilles de style, les images) ne va-t-elle pas être trop importante ?
Et il y a la problématique des signets : si on enregistre l'adresse d'une page, mais qu'une partie de son contenu a été précédemment changé par une technique AJAX, quand on retournera à l'URL sauvegardée, on ne retrouvera pas la même page.
Bref, AJAX, c'est bien, mais à utiliser intelligemment.
Pour en revenir à ta question, il y a XUL (http://www.mozilla.org/projects/xul/ et http://www.xulfr.org pour plus d'information) comme alternative pour créer des interfaces dites "riches". Mais voilà, XUL ne fonctionne (à ma connaissance) que sous Gecko, et je vois mal Microsoft (par exemple) adopter une technologie aussi importante (stratégiquement) alors qu'il n'en contrôle pas le développement et la diffusion.
A mon avis, aujourd'hui, et il faut s'y faire, le seul format d'affichage de données à peu près respecté partout, c'est le HTML.
Toutefois, un espoir subsiste, puisque le W3C travaille sur la question : http://www.w3.org/2006/rwc/
[^] # Re: des pages web de plus en plus complexes ... ajax et le reste
Posté par djano . Évalué à 4.
[^] # Re: des pages web de plus en plus complexes ... ajax et le reste
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 6.
Je n'ai pas trop suivi les évolutions du HTML, mais je crois qu'il y a eu plusieurs autres tentatives pour rajouter cette dynamique.
Personnellement, ma lecture de l'évolution d'Internet c'est que l'on a été obligé de réinventer la simplicité du HTML des débuts avec RSS, Atom and co.
Je crois que l'essor d'AJAX c'est qu'aujourd'hui la plus grande partie des navigateurs supportent Javascript mais pas encore XUL et autres. Du coup, comme on a vraiment besoin de dynamique du coté du client (pour limiter les échanges de pages entières avec le serveur), ben on est parti à fond dans cette voie.
Je pense que dans quelques année, si une autre technologie arrive à s'imposer comme le nouveau format de page dynamique, alors AJAX disparaîtra peu à peu.
[^] # Re: des pages web de plus en plus complexes ... ajax et le reste
Posté par Éric (site web personnel) . Évalué à 3.
Certes, et Rest ou Xul sont intéressants on est d'accord. Ce sont clairement des choses à pousser au niveau des navigateurs et des outils.
Maintenant, pour un logiciel de publication concret, qui cherche à fonctionner aujourd'hui ... tu proposes quoi à la place d'ajax pour faire des choses un peu plus avancées que le simple page à page statique de HTML ? Xul ne fonctionne que sur Gecko, PUT n'est utilisable par aucun. C'est bien normal que les outils type wordpress utilisent ajax massivement : ils n'ont rien d'autre à disposition.
> Le javascript Gecko est différent de celui d'Opera ou de KHTML ... et
> encore plus de celui de Microsoft, non ?
Oui, mais la base est la même, et cette base est suffisament importante pour faire des choses sympa avec un minimum de cas spécifiques. Avec XUL que tu cites ce n'est pas un moteur différent qu'il y a, c'est carrément une absence de moteur (et chez des navigateurs tout à fait "bons" et modernes comme Opera et Safari). Pire, pour faire ton interface XUL il te faudra du javascript, et pour faire une interface XUL pas mal dynamique il est loin d'être impossible que tu utilises le XMLhttprequest+DOM d'Ajax.
Tu peux difficilement demander un support XUL et le justifier par le fait que les moteurs js ne sont pas strictement identiques chez MS Opera et Gecko, ça serait encore pire en XUL de ce point de vue là.
[^] # Re: des pages web de plus en plus complexes ... ajax et le reste
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Ok, tu peux avoir à utiliser de l'ajax. Mais avec le système de template de XUL, tu n'a pas pratiquement rien à faire en JS, pour rafraichir un morceau de l'écran; une liste etc... Juste dire à recharger les données du template, ce qui te prend une ligne de JS.. Faire la même chose dans un contexte HTML demande un travail plus important...
Et puis bon, tout ce qui est widget/interface (menu deroulant ou autre), tu as quasiement rien à faire avec JS, tandis qu'en HTML, tu passes ton temps à (mal) simuler des widgets avec des librairies JS dans tout les sens.
[^] # Re: des pages web de plus en plus complexes ... ajax et le reste
Posté par Éric (site web personnel) . Évalué à 5.
# Attention quand même.
Posté par Sarki . Évalué à 10.
Il s'avère après quelques recherches et touffes de cheveux, qu'il faut réaliser trois étapes :
- Se déloguer (sur la page d'accueil)
- Supprimer tous les fichiers présents dans le répertoire "wp-content/cache"
- Se reloguer.
Et là miracle !
J'ai joué avec la base (jusqu'à la virer complêtement), trifouillé les droits directement depuis phpmyadmin (en me basant sur le codex de wordpress) et rien ne semblait tenir jusqu'à ce que je vire c'te *$%&§£ de cache...
Je le dis ici, sait-on jamais ça pourrait éviter pas mal de stress à certains. (moi le premier si j'avais su)
# Wordpress vs dotclear
Posté par Natja . Évalué à 10.
Mais comment choisir ?
Quels sont les avantages de l'un et de l'autre, et leurs inconvénients ? L'un des deux surpasse-t-il vraiment l'autre, ou se valent-ils plus ou moins ? Qu'en est-il au niveau sécurité, rapidité, fonctionnalités, etc ?
(ceci est une vraie question, pas un appel au troll...)
[^] # Re: Wordpress vs dotclear
Posté par Zec . Évalué à 7.
Mais là, ayant essayé Wordpress 2.0 en Beta, je peux te dire que je ne repasserais plus sous Dotclear, rien que pour l'éditeur WYSIWYG, il est génial !
Et globalement je trouve l'administration de Wordpress mieux foutu que Dotclear.
PS: Je compare là un Wordpress et un Dotclear sans plugins hein, bien sur.
[^] # Re: Wordpress vs dotclear
Posté par grafit . Évalué à 10.
(avis d'un néophyte)
J'ai installé dotclear récemment. J'avais hésité avec wordpress.
Parmis les majeurs inconvénients de WP < 2.0 qui m'ont fait pencher pour dotclear étaient:
* l'interface admin très spartiate et trop compliquée, touffue, mal présentée...
* en particulier l'écriture de billets... (un comble pour un blog!)
* ...et l'insertion d'images. Qui pour moi devrait se résumer à écrire billet, choisir image sur disque, cliquer, continuer d'écrire.
Je viens de rejouer rapidement avec WP 2.0. L'interface admin a été nettement améliorée (avec de joli effets graphics pour les messages de confirmation :) Et il utilisent (enfin) un éditeur de billet avancé, et les images s'insèrent facilement.
Les plus de wordpress:
* le dashboard, notement qui te prévient des dernières avancées du logiciel, et des failles de sécurités (heu... plus dans la version 2.0 ???)
* la gestion des utilisateurs (mais pas géniale à mon gout) pour restreindre l'acces de certains billets à certaines persones
* édition des fichiers par l'interface admin (notement les templates, et feuilles de style)
* WP2 prévisualisation avec le style final
Les plus de dotclear:
* une interface admin simple et très claire (même vs. WP2)
* un gestionnaire de plugins "plug and play" \o/
* "made in France" (ca compte ?)
* paneau d'information sur le system (notemment indique les problemes d'accès :)
Parmis les plugins dotclear que je trouve interessant,
* L'utilisation de tags pour "classifier" les billets, et leur représentation en nuage
http://www.brindilles.net/index.php?2005/10/07/54-des-tags-e(...)
* L'intégration (très bien faite) d'une galerie d'images (de fichiers quelconques en fait)
Je vais rester avec Dotclear pour l'instant ;)
[^] # Re: Wordpress vs dotclear
Posté par Xavier Verne (site web personnel) . Évalué à -1.
Même passage dotclear vers Wordpress.
Ce dernier est plus "tout".
Dans ma boîte d'info on avait une expression pour dire qu'un client en voulait toujours plus dans sa gestion d'informations, notamment sur les fonctionnalités ou les notions gérées.
On disait qu'il voulait une appli "multi-tout".
En résumé, Wordpress est plus multi-tout que Dotclear, même si ce dernier reste un poil plus simple à utiliser.
[^] # Re: Wordpress vs dotclear
Posté par Gabriel . Évalué à 1.
Pour moi ça compte, quand l'auteur est une personnalité que l'on peut connaître et apprécier, quand les docs sont en français - mieux vaut une bonne doc en bon français qu'en mauvais anglais.
Maintenant, si Dotclear suffit, pourquoi aller courir l'échalotte et virer DC juste parce que WP semble mieux? Si les fonctionnalités ne te manquent pas? Libre à toi, ô lecteur!
J'aime bien l'interface d'admin de DC. Ceci dit , je trouve aussi les thèmes sont moches - gros souci qd même...
[^] # Re: Wordpress vs dotclear
Posté par gph . Évalué à 5.
Enfin les gouts et les couleurs ca ne se discute pas, d'ailleurs tu peux toujours creer le thème que tu veux par toi même.
[^] # Re: Wordpress vs dotclear
Posté par Gabriel . Évalué à 5.
le souci c'est que... non, justement. En graphisme je suis une sous-quille, le mauvais parmis les mauvais. Si je fais un truc ce sera horrible.
Je veux bien reprendre le code de dotclear (quoi que , franchement, c'est pas facile), y rajouter des tucs et des machins, mais ne me demande pas d'accorder deux couleurs. Même avec des sites qui référencent des "couleurs qui vont bien ensemble", ça rendra pas.
Mais bon, ça m'empêche que je préfère DotClear, qui m'a fait comprendre qu'un programme plus simple peut être la meilleure politique. (une bonne règle: un objet fait une seule chose mais la fait bien)
[^] # Re: Wordpress vs dotclear
Posté par iznogoud . Évalué à 6.
http://www.dotclear.net/trac/wiki/DotClear/Themes
Y'a plein de thèmes recencés, beaucoup (tous ?) sous licence libre, et beaucoup sont fort sympathiques (j'ai personnellement récupéré Jour d'automne, je pense y faire quelques modifications, mais il est déjà très sympa)
[^] # Re: Wordpress vs dotclear
Posté par jemore . Évalué à 1.
J'avais regardé il y'a quelques temps, le code de Dotclear pour l'adapter à PostGresql, mais le code etait plutot crado a l'époque.
# Wordpress est il toujours aussi lourd ?
Posté par xavier dumont . Évalué à 4.
J'ai installé et essayé pendant quelques jours wordpress sur un site free. Bon, c'était pas mal fait, mais quelle lenteur par rapport à spip !
Je pense que c'est dû à la gestion des pages en cache...(?)
En tous cas j'ai arrêté de l'utiliser à cause de ça.
[^] # Re: Wordpress est il toujours aussi lourd ?
Posté par Sarki . Évalué à 4.
Ne serait-ce que le "Dashboard" qui chez moi prenait bien 8-10s à s'afficher entièrement sous la 1.5.2 s'affiche désormais en 4.41s ...
Je doute que ça vienne de l'utilisation de cache (obligatoire pour les infos données) mais plutôt de la mise en forme de l'ensemble ainsi que la quantité de requêtes que doit gérer leur site mère.
J'ai un blog qui tourne lui aussi sur free et la différence est notable.
Il faut aussi garder en tête que free ne stocke pas ses comptes sur une seule machine et qu'il arrive d'avoir un serveur php un peu... mou, selon l'ancienneté du compte, la version de php utilisée ne faisant pas vraiment de différence.
# par rapport à SPIP?
Posté par zimmermann jérémie (site web personnel) . Évalué à 1.
[^] # Re: par rapport à SPIP?
Posté par Mildred (site web personnel) . Évalué à 7.
SPIP est un système de publication complet aloors qye WP est un blog ... j'ai des doutes sur la faisabilité de la chose.
[^] # Re: par rapport à SPIP?
Posté par nonas . Évalué à 3.
Là avec WordPress ou DotClear, tu uploades, et deux trois opérations (simples) de configuration plus tard, tu as un blog totalement fonctionnel prêt à publier.
Donc pour ceux qui veulent juste un blog c'est franchement plus simple.
Quand à migrer de l'un vers l'autre il faut regarder au niveau des tables de la base de données et de comment chacun y accède. Mais je vois pas ça très facile.
[^] # Re: par rapport à SPIP?
Posté par zimmermann jérémie (site web personnel) . Évalué à 4.
Il suffit ensuite d'ajouter un squelette orienté "blog", et zou, vous avez un SPIP en forme de blog.
Maintenant c'est vrai que SPIP commence un peu à dater, il n'est notamment pas XML-RPC, ni AJAX, ne gère pas (par défaut, je crois que certains squelettes le font) les trackbacks et autres machins-modernes-de-blogs-qui-n'existaient-pas-de-mon-temps-ma-bonne-dame...
[^] # Re: par rapport à SPIP?
Posté par armanoid . Évalué à 3.
Un flux RSS : http://www.spip-contrib.net/Un-fil-RSS-2-et-un-fil-ATOM-3
Tout y est ;)
J'apprécie énormément le système de cache de SPIP, ce thread m'a donné l'envie d'essayer d'en faire un blog pour m'amuser
Pour l'ajax, je suis encore parmis les neutres. Est-ce une mauvaise chose? je ne le pense pas. Est-ce une bonne chose? oui parce que ça donne des interfaces super interactives et non parce que il y a un risque de non-compatibilité tandis qu'Internet c'est fait pour avoir une compatibilité inter-plateformes/systèmes. Néanmoins je vois d'un bon oeil les panneaux d'administrations ajax.
[^] # Re: par rapport à SPIP?
Posté par zimmermann jérémie (site web personnel) . Évalué à 4.
- lorsque tu insères une image pendant la rédaction de ton article, tu fais soit "sauvegarder l'image" soit "sauvegarder les modifications de l'article", mais tu ne peux pas faire les deux en même temps.
- lorsque tu souhaites ajouter N mots-clé tu dois recharger la page N fois.
- tu n'as pas de fonction pour sauvegarder en cours de route ton édition (comme un ctrl+s) sans faire "sauvegarder" / que la page se recharge / faire "modifier" / que la page se recharge / retourner au point ou tu en étais / reprendre ton édition et perso ça me stresse.
etc.
La version actuelle pourrait toujours être un fallback pour les navigateurs connus comme étant incompatibles avec les bases de l'AJAX (y en a-t-il encore aujourd'hui, à part IE 5.x? ahahahaherrmrrmm...)
# Et pour continuer les comparaisons, par rapport à Nucleus ?
Posté par Jean-Christophe Berthon (site web personnel) . Évalué à 4.
J'utilise Nucleus CMS (http://nucleuscms.org/) sur un site hébergé par Free.fr. Ca tourne assez bien avec les quelques lenteurs dû au serveur de free sur lequel je suis qui est un peu molasson.
Que pourrait m'apporter Wordpress ? Quelqu'un a-t'il déjà fait le saut de Nucleus à Wordpress ? Est-ce plus rapide ? Est-ce plus facile d'écrire des articles sans passer par du code HTML tout en ayant une mise en page riche (certains des auteurs de mon blog ne connaissant pas du tout le HTML...) ? Existe-t'il des passerelles de Nucleus vers Wordpress ?
Merci pour votre aide (comme précédement, ce n'est pas un appel à troll)
Jean-Christophe
# Ajax/Mysql
Posté par zorel . Évalué à 2.
# NewsForge : WordPress 2.0 is better than ever
Posté par Nÿco (site web personnel) . Évalué à 1.
http://internet.newsforge.com/article.pl?sid=06/01/04/232424(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.