Remplacer la fonction PHP htmlentities ? (Créer un compte)

  • Statut : non résolu
15 sujets de 46 à 60 (sur un total de 77)
  • Auteur
    Messages
  • #782522
    luciole135
    Participant
    Maître WordPress
    13714 contributions

    le problème n’est pas de savoir si une valeur est nulle ou pas !

    Quand il y a un jour sans aucune visite, il n’y a aucun enregistrement dans la BD, donc les requêtes ne renvoient rien du tout pour ce jour puisqu’il n’y a eu aucun enregistrement.

    Alors comparer avec NULL ou autre ne change rien : la table est VIDE pour ce jour, donc on ne peut faire aucune comparaison.

    Suis-je clair ?

    #782519
    luciole135
    Participant
    Maître WordPress
    13714 contributions
    xknown wrote:
    Je n’ai pas lu votre article, mais je crois que les jointures externes peuvent être utiles (sauf si vous les aviez déjà essayées).

    Un simple UNION ici résout le problème :
    L’Union de l’ENSEMBLE des jours avec une visite réelle (le nombre de visites est plus grand que 0) et de l’ENSEMBLE de TOUS les jours tous comptés sans aucune visite (donc avec 0 visite).

    #782523
    Guy
    Participant
    Maître WordPress
    14817 contributions
    luciole135 wrote:
    le problème n’est pas de savoir si une valeur est nulle ou pas !

    Quand il y a un jour sans aucune visite, il n’y a aucun enregistrement dans la BD, donc les requêtes ne renvoient rien du tout pour ce jour puisqu’il n’y a eu aucun enregistrement.

    Alors comparer avec NULL ou autre ne change rien : la table est VIDE pour ce jour, donc on ne peut faire aucune comparaison.

    Suis-je clair ?

    Non, ce n’est pas clair, dans ma réponse, j’évoquais le fonctionnement du prédicat IN, qui renvoie trois valeurs, TRUE, FALSE ou NULL, précisément pour faire la différence entre une valeur vraie, fausse ou une valeur inexistante.

    Pour paraphraser, chouf1, je fréquente SQL d’un peu loin, mais j’avais tout de même saisi la différence entre aucun enregistrement et un enregistrement présent.

    #782524
    luciole135
    Participant
    Maître WordPress
    13714 contributions

    Puisque vous n’avez pas lu mon article, j’explique à nouveau le problème que résout cette requête : Quand on demande par exemple le nombre de visites qu’a reçu le site les 30 derniers jours, la requête compte toutes les visites de chaque jour. Mais si un jour, il n’y a aucune visite, alors la requête ne renvoit rien du tout pour ce jour, ni NULL, ni 0, rien du tout puisque ce jour n’a enregistré aucune visite.
    N’ayant enregistré aucune visite, la requête ne les trouve évidemment pas.

    Pour pallier à ce problème, le programme original boucle en faisant autant de requêtes que de jours, les requêtes vides sont celles où évidemment il y a eu 0 visite.
    En bouclant sur les jours, il fait 30 requêtes par jour pour un tri donné. Et comme il fait 4 tri différents, il fait donc 4×30 = 120 requêtes pour afficher un graphe de 30 jours qui affiche 4 tri différents.

    Revenons à nos moutons :
    Ainsi, la requête renvoie l’ENSEMBLE des jours ayant eu réellement des visites avec le nombre de visites de chaque jour. Le jour sans visite n’est pas en résultat de la requête puisque la table de données est VIDE pour ce jour là (aucune visite). Donc on ne peut pas faire un graphique avec le nombre de visites de chaque jour puisqu’il manque le jour sans visite.

    Pour résoudre, ce problème, il suffit de PENSER ENSEMBLES (au sens de la théorie des ensembles) : la requête est l’ENSEMBLE des jours AVEC visite. Il manque à cette requête l’ENSEMBLE des jours SANS visite.
    Il suffit de faire la REUNION de ces deux ENSEMBLES (le deuxième ensemble est FICTIF donc), pour avoir en résultat, l’ENSEMBLE de TOUS les jours avec ou sans visite qui permet lui de faire le graphe.

    La deuxième requête construit l’ensemble des jours sans visite, c’est à dire avec 0 visites. pour cela, elle sélectionne tous les jours enregistrés dans la BDD et leur affecte à tous le total de 0 visites. La REUNION des deux ensembles est donc lui aussi fictif, mais donne le résultat des visites de chaque jour 0 ou plus.

    Le problème qui se pose alors est : s’il n’y a eu aucune visite, aucun enregistrement dans la BDD, alors on ne peut pas sélectionner ce jour sans visite puisque’il est absent. Il faut donc qu’il y ait continuité dans les DATES enregistrées dans la BDD.

    J’ai écrit un petit programme PHP qui vérifie la continuité des dates sur l’ensemble des jours devant être affichés.
    En cas de discontinuité des dates, ce programme enregistre uniquement la date manquante et aucune autre donnée (qui donc seront NULL). Les dates étant alors effectivement en enregistrement continu dans la BDD, la requête sélectionne effectivement tous les jours avec ou sans visite.

    Dans la pratique, le problème de la discontinuité des dates n’en est pas un car un site web à au moins une visite par jour, si ce n’est pas un visiteur, cela peut-être un robot d’indexation comme Google qui passe tous les jours. Dans la réalité, les dates sont toujours en enregistrement continu sauf panne du site WEB pendant 24h de 0h00 à 24h00, ce qui est rare. La deuxième cause de discontinuité est la desinstallation du plugin pendant quelques temps, sans destruction de la BDD et la réactivation sur la même BDD, il y aura alors des jours manquant.
    La vérification de la continuité est donc nécessaire pour pallier à tous les cas de figure.

    le SQL doit se penser en termes d’ENSEMBLES (au sens de la théorie), car les BDD sont des ENSEMBLES de données et les requêtes sont des SOUS-ENSEMBLES de la BDD.

    C’est pour cela que les programmeurs de PHP/HTML codent mal leurs requêtes, car ils pensent les requêtes comme une instruction PHP (un ordre séquentiel) et non pas comme un ENSEMBLE de données.
    La requête est vue comme une instruction supplémentaire à PHP, pas comme un ENSEMBLE de données.

    Suis-je plus clair ?

    #782525
    Guy
    Participant
    Maître WordPress
    14817 contributions
    luciole135 wrote:
    C’est pour cela que les programmeurs de PHP/HTML codent mal leurs requêtes, car ils pensent les requêtes comme une instruction PHP (un ordre séquentiel) et non pas comme un ENSEMBLE de données.
    La requête est vue comme une instruction supplémentaire à PHP, pas comme un ENSEMBLE de données.

    Suis-je plus clair ?

    eh ben…. j’ai donc regardé la requête. Un pauvre programmeur PHP n’aurait peut-être pas fait comme ça (et encore je ne vois pas pourquoi), mais le postulat de base est qu’il ne l’aurait pas fait.
    Il n’aurait fait qu’une seule requête (au lieu de l’union de deux requêtes), mais il n’est pas complétement idiot le programmeur PHP, il avait appris dès son plus jeune age la théorie des ensembles, il se serait posé la question est ce que quand je veux afficher un graphe sur une certaine période, à la suite de mon appel SQL, j’ai un ensemble fini et continu et il aurait fait le nécessaire pour afficher quelque chose de cohérent.

    Tout ça pour dire qu’il n’y a jamais qu’une seule solution, je n’ai aucune idée en termes de performances si il vaut mieux construire un tableau de date vide avec MySQL ou avec PHP, cela pourrait être intéressant de le mesurer, mais ce n’est pas le sujet.

    #782526
    luciole135
    Participant
    Maître WordPress
    13714 contributions

    Tout à fait, je n’ai pas choisi l’option PHP car je ne savais pas à l’époque bien lire en PHP les résultats de requêtes.

    J’y ai pensé moi aussi, construire l’ensemble des jours continu en PHP, cela doit être plus rapide.
    Découvrant d’abord le SQL, les relations entre PHP et les requêtes n’étaient pas claire dans mon esprit. Je n’arrivais pas à accéder comme je le voulais aux résultats des requêtes. je croyais que c’étaient des tableaux et en fait ce sont des objets mais je n’ai pas encore bien compris leur syntaxe et leur usage. Chaque fois que je veux accéder à un élément particulier de l’objet résultat d’une requête, je n’y arrive pas. je suis contraint de faire un foreach.

    Alors, je n’ai pas approfondi la piste PHP. Mais je pense que les calculs PHP doivent être plus rapide. Il est facile de créer en PHP, le tableau des jours manquants. Il faudra donc entrer 0 dans le résultat de la requête précédente et ça je ne suis pas arrivé à le faire correctement. Chaque fois que j’insère quelque chose dans un objet résultat de requête, j’ai une erreur. Alors, il a été plus facile pour moi de résoudre le problème en SQL.

    #782527
    Guy
    Participant
    Maître WordPress
    14817 contributions

    Comme je te l’ai dit, je n’ai aucune idée en termes de performances, cela dépend de plus pour des sites en ligne des différents temps d’accès à la base, aux scripts, etc…
    MySQL doit être codé en C++, on peut donc penser qu’en interne c’est plus rapide, PHP étant un langage interprété.

    #782528
    luciole135
    Participant
    Maître WordPress
    13714 contributions

    Quelle est la syntaxe exacte pour insérer dans le résultat de cette requête, les données qui sont égales à 0 ?

    $qry = $wpdb->get_results
    (« SELECT count($select) AS total, date
    FROM $table_name
    WHERE $where AND date BETWEEN $limitdate AND $currentdate
    GROUP BY date );

    Lorsque je fais $qry->total[$date] = 0; pour entrer 0 j’ai une erreur.

    Quelle est la syntaxe exacte ? est-ce possible d’insérer une valeur dans le résultat d’une requête ?

    #782529
    Guy
    Participant
    Maître WordPress
    14817 contributions

    arf :( j’ecris un truc vite fait, ça ne marchera pas mais c’est le principe de ce que je ferai

    $debDate = ‘2011-07-01’;
    $finDdate = ‘2011-07-20’;
    $dates = array($debDate);
    while ($debDate != $finDate)
    {
    $debDate = date(‘Y-m-d’, strtotime($debDate . ‘ +1 day’));
    $dates[$debDate] = 0;
    }

    $qry = $wpdb->get_results
    (« SELECT count($select) AS total, date
    FROM $table_name
    WHERE $where AND date BETWEEN $limitdate AND $currentdate
    GROUP BY date );

    foreach ( (array) $qry as $row )
    $dates[$row[‘date’]] = $row[‘total’];

    Observations:
    Dans tout ça, il faut vérifier le format des dates pour les faire coincider, le format nous est donné par date(‘Y-m-d’, …) .
    J’ai mis (array) devant $qry, ce n’est peut-être pas nécessaire.
    Je me suis servi de strtotime pour la boucle qui construit le tableau de date vide, ce n’est peut être pas le plus optimisé. mktime est certainement plus approprié en l’incrémentant de 24h dans la boucle.

    #782530
    luciole135
    Participant
    Maître WordPress
    13714 contributions

    Si, cela est revient au même, vous mettez à jour la liste des jours en insérant les visites réelles dans la liste de tous les jours tous comptés sans aucune visite.

    Je vais l’essayer avec un chrono interne pour comparer les performances, je pense que cela sera plus rapide, il n’y a pas la perte de temps à lire et écrire dans une BDD. surtout si le graphe oblige à lire loin dans la BDD, la requête sera moins performante.
    Elle induit beaucoup d’opération de lecture alors qu’en PHP, il n’y a qu’un tableau à faire.

    Pourquoi vous n’avez pas créé un objet ?

    C’est moins performant qu’un tableau ?

    #782531
    Guy
    Participant
    Maître WordPress
    14817 contributions

    je ne me suis pas posé la question 🙂, ici nous avons typiquement un tableau, j’ai donc converti le résultat en tableau. Les objets véhiculent des propriétés que les tableaux n’ont pas, mais la différence à l’exécution pour un tableau de cette taille ne doit pas être sensible.

    Assurez vous que le format du tableau de date est bien identique à celui retourné par SQL.

    Cela revient exactement au même, on doit avoir un ensemble continu à partir d’une requête qui risque de renvoyer des éléments discontinus, il n’y a pas 36 moyens de faire l’union des deux.

    #782532
    luciole135
    Participant
    Maître WordPress
    13714 contributions

    Oui, pour le format des dates celui choisi par le concepteur est ‘Ymd’, il a l’avantage de pouvoir comparer les dates comme si c’était des entiers, mais il n’est pas allé jusqu’au bout de son raisonnement car il stocke dans la BDD les dates sous forme de chaîne de caractères et pas d’entier. Alors que dans tout le programme il compare en PHP et en SQL les dates en utilisant l’avantage de la notation ‘Ymd’ qui est que les dates se rangent très facilement dans l’ordre croissant ou décroissant « hier est plus petit qu’aujourd’hui » car 20110722 < 20110723.

    S’il avait stocké les dates sous forme d’entiers, la lecture des dates dans la BDD serait d’après mes différentes recherches, 3 fois plus rapide et idem pour l’écriture…

    Je dois donc aussi me renseigner comment on fait pour mettre à jour le type de données dans une base de données WordPress. Je ne sais pas encore comment il faut procéder. De plus, je voudrais ajouter un index sur les dates, mais je ne sais pas encore comment il faut le choisir, l’idéal, je pense qu’il vaut mieux que la date soit un index à elle toute seule car presque toutes les requêtes font des tris sur les dates :
    Graphique des visites sur une période de temps donnée, nombre total de visites du mois précédent, du mois en cours, de hier, d’aujourd’hui, etc.
    Presque toutes les requêtes ont une condition WHERE sur les dates. Il est donc intéressant d’avoir des dates indexées pour accélérer les recherches, c’est à dire éviter que la requête parcoure toute la table de donnée pour calculer le nombre de visiteur d’hier, par exemple.

    Je dois encore me documenter sur cette partie. je sais que tout cela est possible, je ne sais pas encore comment.

    #782533
    Guy
    Participant
    Maître WordPress
    14817 contributions

    effectivement la date aurait pu être stockée sous forme d’unsigned int (qui prend 4 octets au lieu des 8 nécessaires en stockant en text).

    Les fonctions classiques de modification des tables fonctionnent avec WordPress mais il est toujours délicat de mettre à jour des bases installées en modifiant le type d’une des colonnes. C’est toujours possible en testant et comparant un numéro de version du plugin et des tables de la base mais j’agirai avec une extrême prudence, j’imagine sans difficultés des cas où l’on pourrait trouver une nouvelle version de la base et une ancienne version du plugin, sans oublier les opérations de modification de la base qui peuvent échouer lors de l’installation de la nouvelle version du plugin.

    Pour ce qui est d’indexer les dates, cela accélérerait la lecture sans aucun doute, il faut savoir tout de même que la création d’un index prend de la place en mémoire et qu’à chaque modification/écriture, la table d’index est recalculée, ce qui peut considérablement alourdir les opérations d’écriture.

    #782534
    luciole135
    Participant
    Maître WordPress
    13714 contributions
    Guy wrote:
    Les fonctions classiques de modification des tables fonctionnent avec WordPress mais il est toujours délicat de mettre à jour des bases installées en modifiant le type d’une des colonnes. C’est toujours possible en testant et comparant un numéro de version du plugin et des tables de la base mais j’agirai avec une extrême prudence, j’imagine sans difficultés des cas où l’on pourrait trouver une nouvelle version de la base et une ancienne version du plugin, sans oublier les opérations de modification de la base qui peuvent échouer lors de l’installation de la nouvelle version du plugin.

    Je dois avant de faire ce genre d’opération être sûr et certain de ce que je fais.
    Alors, j’hésite soit à refaire le même plugin mais avec un nom différent et avec une nouvelle table de données (avec un nouveau nom) indexée correctement : c’est à dire pas trop pour ne pas ralentir mais suffisamment pour accélerer. Faire un nouveau plugin avec un nom différent permet d’éviter le problème du changement de type de données dans la table.

    Car il est vrai que les utilisateurs font comme moi, ils n’hésitent pas à passer d’une version plus récente à une version plus ancienne (De WP 3.1 à 2.9, par ex) et alors, le problème c’est que les tables de données auront le même nom et que les anciens plugins n’ont pas de numéro de version de la base de données, donc les anciens plugins ne fonctionneront pas sur les nouvelles tables.

    Il y a un nouveau plugin (NewStatPress) qui s’est intéressé à ce problème et a créé 10 d’index supplémentaires, 5 uniques et 5 multiples sur les 15 champs de données (cela accroit la taille de la base de données de 80% et augmente la vitesse de 50% d’après son concepteur). Je ne suis pas convaincu par sa solution, « trop d’index tue l’index « ai-je pu lire régulièrement sur l’optimisation des tables de données. Il vampirise la table originale de StatPress en gardant son nom mais en changeant la table. Ainsi, le StatPress original fonctionne mal sur la nouvelle table. Il a gardé les même noms des champs et ajouté des index en appelant sa table « statpress » et non pas « Newstatpress ».

    En plus il a repris à l’identique toutes les requêtes du StatPress original et donc celles des graphes qui sont mal conçues, je me demande s’il y gagne vraiment.

    Il est peut-être plus intéressant de repartir sur une nouvelle analyse de la base de données et de reprendre tout au propre.
    J’ai vu qu’il y avait des normes dans la conception d’une base de données, il va falloir que j’étudie çà.
    http://www.sqlspot.com/sites/sqlspot.com/IMG/pdf/Norme_de_developpement_BD.pdf

    Guy wrote:
    Pour ce qui est d’indexer les dates, cela accélérerait la lecture sans aucun doute, il faut savoir tout de même que la création d’un index prend de la place en mémoire et qu’à chaque modification/écriture, la table d’index est recalculée, ce qui peut considérablement alourdir les opérations d’écriture.

    Pour les index, je lis à gauche et à droite tout ce que je trouve sur les tables de données et leur optimisation. Ici, comme presque toutes les recherches se font sur des dates, cela accélèrera l’accès aux données.

    Il n’y a que les requêtes pour écrire le journal des visites du site (appelé SPY par le concepteur) qui ne les utilise pas. Il trie les 20 dernières IP différentes, puis pour chaque IP fait le tri des 20 dernières visites.
    Il fait donc ici, 21 requêtes pour afficher 20 IP, 41 pour afficher 40 IP.
    Il peut ici, être intéressant de faire un index sur les IP.

    J’ai contourné le problème en utilisant l’index naturel de la table de donnée du plugin :

    Comme cette table inscrit les données dans l’ordre croissant du temps, l’index naturel est équivalent à un timestamp.

    De plus, un journal des visites (un log, en anglais), c’est tout simplement un tri décroissant dans le temps. Il est possible de ranger facilement une table en la rangeant dans l’ordre décroissant du temps. Il suffit lors de ce tri de mémoriser les 20 dernieres visites des 20 deniers visiteurs.
    Mais, je n’ai pas pu faire avec MySQL un LIMIT sur le deuxième champ du ORDER BY MaxId DESC id DESC. Le LIMIT ne limite que les 20 dernières en tout, donc si je met un LIMIT 20, il n’y aura que 20 visites et visiteurs confondus affichés.
    Un ORDER BY MaxId DESC LIMIT 20, id DESC LIMIT 20 ne donne que les 20 dernières visites.
    Le LIMIT concerne les deux champs du tri (MaxId et id), on ne peut pas limiter séparément à 20 IP et 20 visites pour chaque IP, du moins avec MySQL.

    Alors, j’ai fait une requête qui fait une auto-jointure entre l’ensemble des 20 dernières IP (en ayant pris soin de mémoriser le maximum et minimum de l’index naturel pour chaque IP) avec la table de donnée entière sur les IP identiques, groupées et ordonées primo sur l’index Maximum et deuxio sur les index décroissants.

    Bon, le problème, c’est que si une personne vient tous les jours, j’aurai toutes ses visites de la première à la dernière. je limite simplement l’affichage à 20 maximum, mais toutes les autres visites non affichées sont renvoyées en résultat dans le requête, ce qui peut faire beaucoup si le site a des visiteurs fidèles et non pas uniques comme le mien…

    Sur un site comme le mien, cela ne pose aucun problèmes car ceux qui l’ont lu ne reviennent pas souvent le lire, une fois qu’ils ont compris l’effet des additifs du tabac, ils n’ont plus besoin de relire les pages. Donc, dans mon cas particulier où presque toutes les visites sont nouvelles chaque jour, cela améliore la rapidité d’excécution par 3 (En fait, comme 80% des IP sont dynamiques, dans 80% des cas, sur tous les sites, les IP sont nouvelles chaque jour ).

    Je n’ai pas pu étendre cette solution à l’ensemble des recherches faites sur les dates car les « dates » que j’insère en plus avec la requête union créent des problèmes sur les index. Il est certain qu’en supprimant toutes ces insertions artificielles une bonne fois pour toutes, je pourrais étendre ce système à toutes les recherches faites sur des dates. Cela évitera de créer un index sur les dates, mais en contrepartie cela nécessitera une première lecture de la table pour mémoriser l‘index minimum et maximum de l’intervalle de temps concerné par la requête.

    C’est une solution pour les requêtes de la page principale qui font 4 tris différents sur les dates du mois dernier, du mois en cours, d’hier et d’aujourd’hui et sur la totalité des visites depuis le début des stats. Il y a un tableau de 4×5= 20 données, donc au minimum 20 requêtes. En faire une de plus pour aller chercher les MinId et MaxId peut-être rentable.

    Maintenant, avec votre solution codée en PHP de la REUNION des ensembles de jours avec et sans visites, cela va être possible.

    Toutes les autres requêtes ont une condition WHERE sur la date. Et au fil du temps, ce qui va augmenter considérablement, c’est le nombre de dates différentes. alors l’index sur les dates sera de plus en plus intérressant au fil du temps.

    Donc, il y a deux index possibles : les IP et les dates. Faire des index multiples pour faire la différence entre un visiteur et une visite (un visiteur peut faire plusieurs visites), entre un visiteur et un robot d’indexation (spider) ne me semble pas extrêmement utile à première vue.

    #782535
    chamomor
    Participant
    Maître WordPress
    1912 contributions

    Chouf1, ton message ci-dessous est brillant. Presque utilisable tel quel comme plaidoyer pour faire appel à un professionnel de fabrication de sites et plugins.
    Je plussoie en tout ta description des choses.
    En tous les cas il fait du bien et m’a fait rire. Merci. :D

    chouf1 wrote:
    Pour ton anglais, tu devrais prendre la chose autrement.: tu n’es pas le commun des mortels. Vu comme tu transpires sur ta màj de plugin, plus tu pratiqueras l’anglais, plus tu te sentiras à l’aise (et de moins en moins « commun(e) »). Parce que ce n’est pas demain la veille que tu pourras développer en français. English is the language of coding, c’est ainsi depuis le début de l’informatique et de ce qui en a découlé.

    Hélas, je n’ai pas de doc en français du TRAC en ma possession. Et je crains que cela n’existera jamais. Qui veut perdre son temps à traduire des rapports de bugs commentés ? WP sort des versions à tour de bras ! C’est impossible comme travail et surtout inutile.
    Tous les devs du monde (je m’avance: je n’en suis pas un) ont pour objectif de développer, pas de faire des tutos sur la moindre petite modification qu’ils apportent à longueur de temps à leurs codes. Sans parler qu’ils doivent suivre les màj, ajouter/retirer des fonctions, j’en passe et des meilleures. Alors passer des heures sur un forum à dépatouiller des gens qui ne parlent par leur langue….hein ?… Bon !!!

    Sur ce forum, comme sur quasiment tous les autres, énormément de personnes débarquent avec THE question cruciale qu’elles envoient à la communauté. Peu y répondent, statistiquement parlant. Un bon tiers doit même trouver sa réponse sans demander. En retour: rien, nada, même pas merci. C’est un fait, pas un critique.

    La plupart des visiteurs, une fois la réponse obtenue, disparaissent. Tout simplement.
    Peu reviennent pour ne serait-ce que pour essayer d’aider les autres, en juste de retour de ce qu’ils ont eux-même reçu. C’est un fait, pas une critique.

    Autre exemple criant, le codex en français. De loin pas complet. Un appel à participer s’étale pourtant en gras sur la page d’accueil. Cet appel est là depuis trèèèèèèèèèèès longtemps. Qui s’en soucie ? Tout le monde veut savoir « comment je fait pour… », personne ne veut rédiger un tuto utile pour la communauté, ou alors juste sur leur blog auto-proclamé « spécialiste wordpress », truffé d’adsenses pour faire « pro ». C’est un fait, pas une critique.

    Et maintenant un constat: 90% des problèmes WP évoqués sur ce forum résident entre la chaise et le clavier. Principalement parce que ces personnes ne lisent pas la doc. Et beaucoup ont beau la lire, ils ne la comprennent pas. Le PHP n’est pas du HTML et le chinois n’est pas du français. Il faut 5 ans minimum pour maîtriser les bases du français. Il en faut tout autant pour n’importe quel autre langage. C’est un fait, pas une critique.

    Les tournevis et les clés de 12 sont en vente libre à des prix dérisoires. Ce n’est pas pour autant que les millions d’automobilistes qui les achètent s’improvisent garagistes. Certains outils open source eux semblent subir un sort inverse.
    Faut croire que WP est victime de son slogan « the 5 minutes install ». Malheureusement, un paquet d’usagers lambda se prennent pour Matt Mullenweg ou Linus Torvalds en 5 minutes aussi. C’est juste de l’humour.

    Les pros du code échangent par mails, via des listes de diffusion, entre gens du même monde. Pas sur des forums grand public.
    http://lists.automattic.com/mailman/listinfo/wp-hackers
    http://groups.google.com/group/wp-hackers

    Et les développeurs sont tous cités ici, donc facile à retrouver sur les réseaux
    http://wordpress.org/about/

    Mais l’anglais est indispensable pour entrer en contact avec eux. Ah l’anglais…….. :wp:

15 sujets de 46 à 60 (sur un total de 77)
  • Vous devez être connecté pour répondre à ce sujet.