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

  • Statut : non résolu
15 sujets de 61 à 75 (sur un total de 77)
  • Auteur
    Messages
  • #782538
    luciole135
    Participant
    Maître WordPress
    13751 contributions
    chamomor wrote:
    Chouf1, ton message ci-dessous est brillant. Presque utilisable tel quel comme plaidoyer pour faire appel à un professionnel de fabrication de sites et plugins.

    Ben, il va pas faire fortune le concepteur professionnel de plugins WordPress, vu le nombre de gratuits disponibles…

    #782537
    chamomor
    Participant
    Maître WordPress
    1914 contributions
    luciole135 wrote:
    chamomor wrote:
    Chouf1, ton message ci-dessous est brillant. Presque utilisable tel quel comme plaidoyer pour faire appel à un professionnel de fabrication de sites et plugins.

    Ben, il va pas faire fortune le concepteur professionnel de plugins WordPress, vu le nombre de gratuits disponibles…

    Détrompe toi, les développeurs professionnels, ou concepteurs de sites web comme moi ou d’autres ici présents, qui fabriquent des thèmes wordpress ou des plugins, malgré les gratuits existants, gagnent très bien leur vie. Simplement parce que si l’objectif du site web est professionnel, il faut des solutions professionnelles et non du bricolage pas mis à jour. Les entreprises le savent très bien.

    #782536
    Lumiere de Lune
    Participant
    Maître WordPress
    19379 contributions
    luciole135 wrote:
    Ben, il va pas faire fortune le concepteur professionnel de plugins WordPress, vu le nombre de gratuits disponibles…

    Je te remercie de te soucier de moi ^^
    Blague à part il y a un marché pour le développement professionnel de plugin (comme pour le développement professionnel de thèmes, malgré les nombreux gratuits qui existent) pour tous ceux qui veulent avoir une solution taillée sur mesure.

    Les autres moyens de gagner sa vie sont :
    – profiter de a notoriété pour vendre des services
    – vendre au dela du plugin gratuit des fonctions premiums
    – vendre le conseil et le support

    #782539
    luciole135
    Participant
    Maître WordPress
    13751 contributions
    Lumière de Lune wrote:
    luciole135 wrote:
    Ben, il va pas faire fortune le concepteur professionnel de plugins WordPress, vu le nombre de gratuits disponibles…

    Je te remercie de te soucier de moi ^^
    Blague à part il y a un marché pour le développement professionnel de plugin (comme pour le développement professionnel de thèmes, malgré les nombreux gratuits qui existent) pour tous ceux qui veulent avoir une solution taillée sur mesure.

    Les autres moyens de gagner sa vie sont :
    – profiter de a notoriété pour vendre des services
    – vendre au dela du plugin gratuit des fonctions premiums
    – vendre le conseil et le support

    Ce que je veux dire c’est que les particuliers qui comme moi ont installé un site non professionnel préfèrent passer du temps à bidouiller comme je le fais qu’à payer pour un site qui ne rapporte presque rien.

    Pour les entreprises, évidemment, le problème n’est pas le même, elles ont tout intérêt à installer des plugins fiables, mais là, il faut mettre le prix.
    Les plugins en téléchargement sont pour la plupart écrit par des amateurs (à part celui que je tente d’améliorer, le concepteur du plugin est un professionnel de l’informatique Italien). Il s’en sert de vitrine…

    Je passe mon temps libre à apprendre d’abord le SQL, puis le PHP et à me documenter sur WordPress, j’apprends beaucoup de choses, il y a des problèmes intéressants à résoudre, c’est assez amusant de bidouiller…

    Et heureusement qu’il y a des professionnels bien payé car c’est vraiment prise de tête les problèmes informatiques…

    #782540
    Lumiere de Lune
    Participant
    Maître WordPress
    19379 contributions

    C’est clair.
    Mais il ne faut pas croire que l’écosystème de wordpress se limite aux particuliers ^^

    Par ailleurs

    Les plugins en téléchargement sont pour la plupart écrit par des amateurs

    Euh… non 🙂 enfin ça dépend, mais la majorité des plugins à succès sont écrits par des pros. Ou des gens qui sont en train d’étudier pour le devenir.

    #782541
    luciole135
    Participant
    Maître WordPress
    13751 contributions
    Guy wrote:
    $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:

    C’est déjà bien, mais je dois l’adapter au cas particulier du plugin. Le graphique affiche 4 tris en même temps au moyen de rectangles colorés (visiteurs uniques, pages vues, feeds et spider).
    C’est pourquoi je me demande s’il ne vaudrait pas mieux faire un objet des différents critères de tri avec comme élément le tableau du nombre de visites quotidiennes.
    Comme $dates->visitors[$debDate] = 0;
    $dates->pagevues[$debDate]=0; etc

    Ou alors un tableau de tableau ?

    Qu’est-ce qui est préférable ?

    #782542
    Guy
    Participant
    Maître WordPress
    14830 contributions

    Je ne me suis pas penché à fond sur l’analyse que tu as détaillé dans un de tes posts précédents en particulier pour les visites, je te soumet donc une une proposition qui risque de ne pas avoir tenu compte de tous les paramètres que tu as bien en tête.

    Mon interrogation concerne le nombre de requêtes vers la base qui sont faites pour afficher le tableau. Si je comprends bien, une page affiche toujours les statistiques depuis le début, du mois précédent, du mois courant, d’hier et d’aujourd’hui. J’ai cru comprendre que tu faisais une requête pour chaque cas, or “aujourd’hui” est inclus dans “depuis le début” et “mois courant”, de même que “hier”, etc…
    Une seule requête retournant l’ensemble devrait suffire pour construire une ligne de tableau d’affichage et cela réduirait le nombre d’appel à la base de 20 à 4 (visiteurs uniques, pages vues, feeds et spider), je me trompe ou il y a des données que j’ai oublié de prendre en compte?

    #782543
    luciole135
    Participant
    Maître WordPress
    13751 contributions
    Guy wrote:
    Mon interrogation concerne le nombre de requêtes vers la base qui sont faites pour afficher le tableau. Si je comprends bien, une page affiche toujours les statistiques depuis le début, du mois précédent, du mois courant, d’hier et d’aujourd’hui. J’ai cru comprendre que tu faisais une requête pour chaque cas, or “aujourd’hui” est inclus dans “depuis le début” et “mois courant”, de même que “hier”, etc…

    Oui, c’est tout a fait cela, je n’ai rien changé à la version originale du plugin dans cette partie.

    Guy wrote:
    Une seule requête retournant l’ensemble devrait suffire pour construire une ligne de tableau d’affichage et cela réduirait le nombre d’appel à la base de 20 à 4 (visiteurs uniques, pages vues, feeds et spider), je me trompe ou il y a des données que j’ai oublié de prendre en compte?

    Ben, je ne sais pas si c’est possible ou pas et je connaît pas toutes les subtilités de MySQL, a priori je ne vois pas comment car une requête trie sur la condition WHERE qui elle doit être précise. Et comme ce WHERE est justement une condition sur les dates, cela reviendrait en PHP à faire un tri dans l’ordre chronologique inverse avec des points de stockage des informations aux frontières des intervalles de temps.

    Je ne sais pas si cela est possible, peut être en utilisant les CASE, je vais continuer mes lectures des cours de SQL pour voir si c’est possible. Si c’est possible, c’est une très bonne idée.
    déjà, dès que l’on passe de aujourd’hui à hier, il faut lors de ce passage, stocker le nombre d’aujourd’hui et ne pas refaire le même test à la deuxième lecture d’une entrée d’hier. Donc, il faut un test qui assure que la condition ne se remplie qu’une seule fois, au passage de aujourd’hui à hier et non pas une condition sur la date d’hier qui sera remplie à chaque lecture d’un enregistrement de la date d’hier.
    C’est déjà plus difficile de trouver une condition qui n’est valable qu’au changement de date.

    Bon, sinon, dans le case, je peux stocker à chaque lecture d’un enregistrement de la date d’aujourd’hui le total de celle-ci et des antérieures.
    Lors du changement de date à hier, j’ajoute pour chaque lecture le total au nombre total d’hier.
    etc
    C’est peut-être possible, je vais devoir me taper les sites anglais, le CASE n’est pas bien référencé en français…

    Mais ca va être galère quand aujourd’hui est le premier jour du mois et hier le dernier jour du mois précédent.
    Dans ce cas, le total du mois en cours et du mois précédent est plus difficile à calculer.
    Si hier et aujourd’hui sont dans le même mois, cela doit être faisable. S’il sont de mois différents, cela complique encore…Il va falloir donc faire les totaux du mois en cours et précédents en PHP, plus souple.

    #782544
    Guy
    Participant
    Maître WordPress
    14830 contributions

    Je ne voyais pas une selection faite par SQL, étant donné que tu fais nécessairement une requête sur l’ensemble des données, le script PHP peut sans grande difficulté afficher des résultats correspondants à des sous ensemble de la totalité.

    La question qui peut se poser tient au volume des données recueillies. Est il nécessaire de de recevoir la totalité?

    Peux tu me donner un lien pour télécharger le plugin, que je me rende compte de qui est présenté à l’écran.

    #782545
    luciole135
    Participant
    Maître WordPress
    13751 contributions
    #782546
    Guy
    Participant
    Maître WordPress
    14830 contributions

    merci, je vais charger cela, par contre je ne vais pas regarder ce soir, la nuit porte conseil 🙂

    #782547
    luciole135
    Participant
    Maître WordPress
    13751 contributions

    Oui, c’est mieux, ces problèmes de tris sont vraiment prises de tête à faire en MySQL…

    #782548
    luciole135
    Participant
    Maître WordPress
    13751 contributions
    Guy wrote:
    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.

    J’ai codé en PHP votre solution, j’ai remplacé le while par un for car le while ne s’arrêtait jamais et je n’avais pas vraiment envie de me prendre la tête avec les dates.

    Résultat, comme je le pensais, c’est plus rapide sur 10 graphiques de 31 jours, pour la page principale, le gain est de vitesse est entre 8% et 14%, ça vaut vraiment le coup de minimiser les requêtes SQL.

    Cela va donc accélérer grandement les pages où je fais entre 20 et 100 graphes !

    Il paraît que les serveurs Apache sont optimisé, ai-je lu, pour l’applicatif et non pas l’accès aux données.

    #782549
    Guy
    Participant
    Maître WordPress
    14830 contributions

    parfait, while et for sont identiques en termes de performances, ce ne sont que des facilités d’écriture.

    En regardant la fonction, je l’avais écrite vraiment vite fait :(, cela ne m’étonne pas qu’elle puisse ne pas marcher, en outre c’est un peu idiot d’appeler strtotime qui doit interpréter une chaine pour la convertir en date, l’incrémenter par une autre chaine, puis la formater à nouveau en chaine, il vaudrait mieux employer mktime et incrémenter de 24 heures dans la boucle for, les opérations d’addition sont beaucoup plus rapide qu’un décodage de chaine de caractères.

    Sinon, j’ai installé le plugin ce matin, et il va me falloir un peu de temps pour assimiler tout ce qu’il contient 🙂. N’hésitez pas si vous pensez que l’on risque de polluer le forum avec nos interrogations à m’écrire en mail.

    #782550
    luciole135
    Participant
    Maître WordPress
    13751 contributions
    Guy wrote:
    parfait, while et for sont identiques en termes de performances, ce ne sont que des facilités d’écriture.

    En fait, c’est qu’avec le for, je n’ai fait que copier-coller une solution déjà existante dans le plugin. Et comme de plus, les dates en PHP, c’est pour moi la galère, j’ai pris la solution de facilité, mais qui n’est pas bien programmée…

    Guy wrote:
    En regardant la fonction, je l’avais écrite vraiment vite fait :(, cela ne m’étonne pas qu’elle puisse ne pas marcher, en outre c’est un peu idiot d’appeler strtotime qui doit interpréter une chaine pour la convertir en date, l’incrémenter par une autre chaine, puis la formater à nouveau en chaine, il vaudrait mieux employer mktime et incrémenter de 24 heures dans la boucle for, les opérations d’addition sont beaucoup plus rapide qu’un décodage de chaine de caractères.

    Je vais essayer de m’intéresser à la génération des dates autrement qu’en copiant l’existant et tenter votre suggestion…
    ben, mktime, n’est pas pratique lorsque les dates sont dans le format ‘Ymd’, je trouve.
    Pour l’instant, voilà ce que fait le plugin :

    for ($i=0; $i <$graphdays; $i++) 
    $Date = gmdate('Ymd', current_time('timestamp') – 86400 * ($graphdays * $pp-$i-1 ));

    $graphdays est le nombre de jour du graphe et $pp, le numéro de la page courante dans le slug.
    Cela fonctionne très bien, mais ça fait beaucoup de calculs, je trouve…

    Guy wrote:
    Sinon, j’ai installé le plugin ce matin, et il va me falloir un peu de temps pour assimiler tout ce qu’il contient 🙂. N’hésitez pas si vous pensez que l’on risque de polluer le forum avec nos interrogations à m’écrire en mail.

    En fait, il est très simple, il a beaucoup de pages, mais il y en a quelques unes que j’avais écrites au départ pour moi uniquement et qui à l’usage ne servent pas à grand chose, alors, je les ai mis en option.
    Mais, cette solution des pages “optionnelles” n’est pas mûre dans cette version : il faut supprimer soi-même les fichiers.
    Pour la prochaine version, j’ai amélioré ceci en faisant le choix des pages que l’on ne veut pas directement dans la page “option” du plugin, c’est beaucoup plus pratique et cela libère aussi bien de la RAM (enfin, pas beaucoup de 0,05 Mo à 0,15 Mo)…

    J’ai donc appris comment on fait un formulaire avec des cases à cocher et tout et tout !

    Je ne pense pas que l’on pollue le forum au vu du nombre de lectures du fil de discussion, on s’est tout simplement un peu éloigné du sujet…

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