[5.1beta1] Sitemap.php renvoi <loc>monsite.com/article0/_</loc>

SuricatSuricat Member
Bonjour,

Le reste du Sitemap est OK, mais il y 2 fois une mauvaise url :
...
<url>
<loc>
http://www.monsite.com/article0/_
</loc>
<lastmod>_</lastmod>
<changefreq>monthly</changefreq>
<priority>0.5</priority>
</url>
<url>
<loc>
http://www.monsite.com/article0/_
</loc>
<lastmod>_</lastmod>
<changefreq>monthly</changefreq>
<priority>0.5</priority>
</url>
</urlset>
Connaissez vous la raison ?

Merci.

Réponses

  • StéphaneStéphane Member, Former PluXml Project Manager
    Bonjour

    article0 ???

    ça, ça devrait pas exister.
    verifie le nommage des fichiers .xml dans /data/articles

    Consultant PluXml

    Ancien responsable et développeur de PluXml (2010 à 2018)

  • SuricatSuricat Member
    Merci de votre réponse rapide.

    J'ai vérifié mes fichiers .xml dans /data/articles mais il n'y a rien d'anormal :
    -1 fichier .htaccess
    -3 fichiers xml correspondant à mes 3 articles du type : 0001.000.001.201104301638.nomarticle.xml

    J'ai fait plusieurs sites Web avec PluXml 5.1 et certains ont une seule URL du type http://www.monsite.com/article0/_ affiché dans sitemap.php et d'autres 2...
  • SuricatSuricat Member
    mai 2011 modifié
    Bon, j'ai trouvé la raison.

    Il y a 2 erreurs dans le fichiers sitemap.php

    *** La première erreur qui m'a perturbé car je ne comprenais pas le code au début est une mauvaise position du crochet de fermeture de foreach($aFiles as $k=>$v)

    Il faut remplacer ligne 83
    foreach($aFiles as $k=>$v) { # On parcourt tous les fichiers
        $array[ $k ] = $plxMotor->parseArticle(PLX_ROOT.$plxMotor->aConf['racine_articles'].$v);
        # On stocke les enregistrements dans un objet plxRecord
        $plxRecord_arts = new plxRecord($array);
        }
    
    par
    foreach($aFiles as $k=>$v) { # On parcourt tous les fichiers
        $array[ $k ] = $plxMotor->parseArticle(PLX_ROOT.$plxMotor->aConf['racine_articles'].$v);
    }
    # On stocke les enregistrements dans un objet plxRecord
    $plxRecord_arts = new plxRecord($array);
    
    *** La deuxième erreur qui génère l'anomalie doit se produire selon les versions ou options de PHP. Le Sitemap.php génère en effet un bon Sitemap en local mais pas sur mon serveur OVH.

    Le problème est l'utilisation du mot clé "array" comme nom de tableau. Une chose à ne jamais faire. :mad:

    Pour résoudre le problème, il suffit de renommer la variable :
    if($aFiles = $plxMotor->plxGlob_arts->query('/^[0-9]{4}.([0-9,|home]*).[0-9]{3}.[0-9]{12}.[a-z0-9-]+.xml$/','art','rsort', 0, false, 'before')) {
        $TArticle = array();
        $plxRecord_arts = false;
        foreach($aFiles as $k=>$v) { # On parcourt tous les fichiers
            $TArticle[ $k ] = $plxMotor->parseArticle(PLX_ROOT.$plxMotor->aConf['racine_articles'].$v);
        }
        # On stocke les enregistrements dans un objet plxRecord
        $plxRecord_arts = new plxRecord($TArticle);
        ...
    
    $array est utilisé pas mal de fois dans PluXml pour déclarer un tableau, c'est à modifier car ça peut expliquer d'autres bugs...

    Cordialement,

    Suricat :cool:
  • StéphaneStéphane Member, Former PluXml Project Manager
    Bonjour Suricat

    Merci pour t'etre penché sur ces problemes et d'avoir fournit la solution.

    Mon point de vue sur l'utilisation d'une variable $array.
    Absolument pas d'accord avec toi. Une variable on la nomme comme on veut, et elle a avec une durée de vie locale (dans un fonction par exemple) ou globale (dans une page) suivant son utilisation.

    En revanche si ici son utilisation pose probleme c'est à cause de la configuration php du parametre register_globals à vrai, qui permet de préserver le contenu d'un variable d'une page à une autre. Je considère ce parametre positionner à on tres maladroit car c'est sujet aux failles de securité.
    Donc mon avis, un hebergeur qui autorise un register_globals est un hébergeur mal paramètré, sujet aux problèmes de sécurité.

    Maintenant s'il fallait remettre à blanc ou vider le contenu de chaque variables globales en fin de script pour eviter des effets de bords sur d'autres pages, ça devient un peu ingérable.

    Néanmoins cela n'empeche pas de programmer proprement et je reconnais que le fichier sitemap.php pourrait etre mieux construit et utiliser une classe objet par exemple, pour eviter ce genre de probleme de variable globale dans la page.

    Consultant PluXml

    Ancien responsable et développeur de PluXml (2010 à 2018)

  • SuricatSuricat Member
    mai 2011 modifié
    Merci de ta réponse.

    Effectivement c'est dommage que le paramètre register_globals soit à ON par défaut (c'est sans doute par soucis de compatibilité avec le plus grand nombre d'applications Php).

    Je vais donc ajouter l'élément suivant à mon .htaccess :
    SetEnv REGISTER_GLOBALS 0

    "SetEnv REGISTER_GLOBALS 0" est l'écriture acceptée par OVH pour désactiver register_globals
    (php_flag register_globals Off est utilisé habituellement).

    Concernant le mot clé array, c'est vrai que je ne suis pas spécialiste de PHP, mais il s'agit d'une bonne pratique en général dans les langages de programmation de ne pas utiliser les mots clés du langage comme nom de variable.

    Mais tu as raison, on peut l'utiliser.

    Citation de la page http://www.manuelphp.com/php/reserved.keywords.php :
    "[Les mots clés PHP] Vous pouvez les utiliser comme noms de variables, mais cela risque de vous mener des confusions."

    Surtout dans un projet opensource, je crois qu'il est important de ne pas troubler les autres programmeurs en utilisant des mots clés comme nom de variable.

    Mais ceci n'est qu'une suggestion, merci pour le taf réalisé sur PluXml...
  • StéphaneStéphane Member, Former PluXml Project Manager
    en fait le probleme vient aussi du fait que la variable $array n'est pas initialisée

    avant la ligne
    foreach($aFiles as $k=>$v) {
    
    ajoute
    $array=array();
    

    Consultant PluXml

    Ancien responsable et développeur de PluXml (2010 à 2018)

Connectez-vous ou Inscrivez-vous pour répondre.