Beta testeurs pour la 5.5

13567

Réponses

  • Donc j'ai installé la version 5.5 sur mon blog en production ^^
    Dans mon Home.php j'ai inséré les appels correspondant :
    [== XML ==]
    <span class="blog__date">Écrit le <?php $plxShow->artDate('#num_day #month #num_year(4)'); ?> | modifié le <?php $plxShow-> artUpdateDate('#num_day #month #num_year(4)') ?></span>
    

    Donc si la date est la même pour : "Date de publication" et "Date de mise à jour" ça inscrira deux fois la même date, il faudrait soit pouvoir désactiver dans l'article les dates de mise à jour et de création ou n'afficher que la date de publication si identique de l'une des deux autres dates.

    :P
  • Bonjour,

    J'aurai la même demande

    Merci d'avance
  • StéphaneStéphane Member, PluXml Former Project Manager
    @bankai et @cpalo
    <span class="blog__date">
    	Écrit le <?php $plxShow->artDate('#num_day #month #num_year(4)'); ?>
    	<?php 
    		if($plxMotor->plxRecord_arts->f('date_update')!=$plxMotor->plxRecord_arts->f('date_creation')) {
    			echo '| modifié le ';
    			$plxShow->artUpdateDate('#num_day #month #num_year(4)') ?>
    		}
    	?>
    </span>
    

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • je-evrardje-evrard Member
    février 2016 modifié
    Bonjour,

    Pas de soucis a l'installation.

    Sur le teme par default un soucis sur l'antispam ou je peux mettre qu'une seule lettre.

    commentaires.php
    [== Indéfini ==]
    <input id="id_rep" name="rep" type="text" size="2" maxlength="1" style="width: auto; display: inline;" />
    

    Vraiment un plus l'image de preview du thème (preview.png), ainsi que le fichier infos.xml dans le thème ce qui va permettre de versionner tout ça ! Ca va etre pratique aussi pour la gestion des dépots de thèmes.

    Cordialement

    jeje
  • Stéphane a écrit:
    @bankai et @cpalo
    <span class="blog__date">
    	Écrit le <?php $plxShow->artDate('#num_day #month #num_year(4)'); ?>
    	<?php 
    		if($plxMotor->plxRecord_arts->f('date_update')!=$plxMotor->plxRecord_arts->f('date_creation')) {
    			echo '| modifié le ';
    			$plxShow->artUpdateDate('#num_day #month #num_year(4)') ?>
    		}
    	?>
    </span>
    


    J'ai une erreur serveur 500
  • StéphaneStéphane Member, PluXml Former Project Manager
    Autant pour moi

    Voici le code sans erreur et amélioré
    <span class="blog__date">
    	Écrit le <?php $plxShow->artDate('#num_day #month #num_year(4)'); ?>
    	<?php 
    		$date_creation = plxDate::formatDate($plxMotor->plxRecord_arts->f('date_creation'), '#num_year(4)#num_month#num_day'); 
    		$date_update = plxDate::formatDate($plxMotor->plxRecord_arts->f('date_update'), '#num_year(4)#num_month#num_day');
    		if($date_update!=$date_creation) {
    			echo '| modifié le ';
    			$plxShow->artUpdateDate('#num_day #month #num_year(4)');
    		}
    	?>
    </span>
    

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • et avec ça ?
    [== Indéfini ==]
    <span class="blog__date">
    					Écrit le <?php $plxShow->artDate('#num_day #month #num_year(4)'); ?>
    					<?php 
    						if($plxMotor->plxRecord_arts->f('date_update')!=$plxMotor->plxRecord_arts->f('date_creation')) {
    							echo '| modifié le ';
    							$plxShow->artUpdateDate('#num_day #month #num_year(4)') ;
    						}
    					?>
    </span>
    
    
  • tu as été plus rapide que moi stef ! héhé
  • Le code fonctionne parfaitement Stéphane, merci beaucoup :) ( Merci je-evrard aussi)
  • Super. Cela fonctionne impeccable pour les articles. Encore merci.

    Naturellement j'aurai souhaité la même chose pour les pages statiques.
    J'ai bien sur utiliser staticCreationDate et staticUpdateDate, mais cela n'a pas suffi.
    Comment dois-je modifier ?:
    [== PHP ==]
    $date_creation = plxDate::formatDate($plxMotor->plxRecord_arts->f('date_creation'), '#num_year(4)#num_month#num_day'); 
    		$date_update = plxDate::formatDate($plxMotor->plxRecord_arts->f('date_update'), '#num_year(4)#num_month#num_day');
    		if($date_update!=$date_creation) {
    
  • StéphaneStéphane Member, PluXml Former Project Manager
    Idem mais pour les pages statiques
    <span class="blog__date">
    	Écrit le <?php $plxShow->staticCreationDate('#num_day #month #num_year(4)'); ?>
    	<?php 
    		$date_creation = plxDate::formatDate($plxMotor->aStats[$plxMotor->cible]['date_creation'], '#num_year(4)#num_month#num_day'); 
    		$date_update = plxDate::formatDate($plxMotor->aStats[$plxMotor->cible]['date_update'], '#num_year(4)#num_month#num_day');
    		if($date_update!=$date_creation) {
    			echo '| modifié le ';
    			$plxShow->staticUpdateDate('#num_day #month #num_year(4)');
    		}
    	?>
    </span>	
    

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • Merci . C'est OK
  • @Stephane,

    Je t'ai fait un pull request pour améliorer l'utilisation de mediasManager pour l'image d'accroche. cela porte sur les points suivants :
    éviter de passer une valeur commençant par ../ (PLX_ROOT) pour urlManager, sinon même souci qu'avec plxEditor
    remplacer la multitude de changement de onclick par un addEventListener. C'est plus élégant.

    Cordialement.
  • bazooka07bazooka07 Member
    février 2016 modifié
    Dans le back-office on a toujours les réponses d'un formulaire à enregistrer en cliquant sur sur un bouton valider obtenu avec une balise <input type="submit" />
    Si on ne renseigne par l'attribut value de cette balise, le libellé du boutin est "envoyez". Ce qui n'est pas aussi significatif que "Enregistrer".
    On a le même souci avec les plugins.

    Si on fait, à la racine du site, un "grep -inP '(sauvegarde|enregistre)' core/lang/fr/*.php", on voit que ce libellé est répété plusieurs fois.
    jpierre%40smartteck%3A%20-home-www-test-Pluxml%20-%20Terminal_028.jpg
    voir copie écran

    On pourrait simplifier, si dans les termes génériques en début du fichier core/lang/fr/admin.php, on avait, avant L_SAVE_FILE la constante générique :
    [== PHP ==]
    'L_SAVE' => 'Enregistrer',
    

    On a le même souci avec "supprimer"
    voir copie écran
  • StéphaneStéphane Member, PluXml Former Project Manager
    je-evrard a écrit:
    Sur le teme par default un soucis sur l'antispam ou je peux mettre qu'une seule lettre.

    commentaires.php
    [== Indéfini ==]
    <input id="id_rep" name="rep" type="text" size="2" maxlength="1" style="width: auto; display: inline;" />
    

    Salut

    De quel antispam parles-tu ?

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • StéphaneStéphane Member, PluXml Former Project Manager
    bazooka07 a écrit:
    @Stephane,

    Je t'ai fait un pull request pour améliorer l'utilisation de mediasManager pour l'image d'accroche. cela porte sur les points suivants :
    éviter de passer une valeur commençant par ../ (PLX_ROOT) pour urlManager, sinon même souci qu'avec plxEditor
    remplacer la multitude de changement de onclick par un addEventListener. C'est plus élégant.

    Cordialement.

    Pris en compte.
    Super le travail que tu as fais.
    Un grand merci

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • Bonjour

    Etant donné que par exemple chaque niveau d'utilisateur utilise le même formulaire pour se connecter
    pourquoi ne pas remplacer le lien "administration par un lien "connexion"

    sinon de belles avancée pour PluXML vraiement du bon boulot

    A+
  • StéphaneStéphane Member, PluXml Former Project Manager
    grisbi a écrit:
    Bonjour

    Etant donné que par exemple chaque niveau d'utilisateur utilise le même formulaire pour se connecter
    pourquoi ne pas remplacer le lien "administration par un lien "connexion"

    sinon de belles avancée pour PluXML vraiement du bon boulot

    A+

    Tu peux changer le terme dans les fichiers de langue du thème. ça te donne la souplesse de cette façon de mettre le nom du lien que tu préfères.

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • sitinwebsitinweb Member
    février 2016 modifié
    Bonjour à tous
    Petit nouveau sur le forum, je me suis inscrit pour apporter mon aide avec cette version Bêta.
    J'utilise Pluxml depuis plus d'un an, il est temps de contribuer au développement de cet outil que j'utilise tous les jours.

    Deux situations de test :
    - labo.sitinweb.info/pluxml => Installation vierge sur mon serveur chez O2Switch
    - sitinweb.info => Mise à jour d'un Pluxml version 5.4 en production avec les plugins : MyBetterUrls, spxtynimce, plxMyAutoMetaDescription et thème html sur mon serveur O2Swtich.

    Edit : Mise à jour avec succès de mon site sitinweb.info.

    Bonne journée
    Anthony
  • Bonjour,

    Il semble que la pagination ne fonctionne pas pour la page "Catégorie". (OK pour les autres pages : home, archives, tags).

    (thème par défaut)


    à plus,

    Gzyg
  • Bonjour,

    Quelqu'un sur un autre forum a voulu mettre en place une instance Pluxml dans le dossier personnel de chacun des utilisateurs de son serveur.

    Cela correspond à la directive userdir d'un serveur Apache. Voir la doc ici.
    Sur le serveur mon_serveur, on arrive au Pluxml de l'utilisateur toto par l'adresse http://mon_serveur/~toto ou http://monserveur/~toto/pluxml selon l'installation faite au lieu du cas général http://monserveur/ ou http://monserveur/pluxml.

    Sauf que dans ce cas là, le serveur est Nginx et que la configuration est moins simple. (voir fil de discussion). Dans un premier temps, le texte de la page d'accueil s'affiche, sans que les feuilles de style du thème soient appliquées.
    En fouillant un peu dans Pluxml, j'ai vu que la fonction class.plx.utils::getRacine() s'appuie sur la variable globale $_SERVER. Cela est incorrect car elle indique l'emplacement du fichier php par rapport à la racine du site. La variable $_SERVER est plus appropriée car elle indique l'adresse URL demandée par le visiteur, diminuée du nom d'hôte, et éventuellement du numéro de port.

    Voici la fonction getRacine() qui me semple plus correcte :
    [== PHP ==]
    public static function getRacine() {
    
    		$protocol = (!empty($_SERVER['HTTPS']) AND strtolower($_SERVER['HTTPS']) == 'on') || (!empty($_SERVER['HTTP_X_FORWARDED_PROTO']) AND strtolower($_SERVER['HTTP_X_FORWARDED_PROTO']) == 'https' )?        'https://' : "http://";
    		$servername = $_SERVER['HTTP_HOST'];
    		$serverport = (preg_match('#:\d{1,5}$#', $servername) OR $_SERVER['SERVER_PORT'])=='80' ? '' : ':'.$_SERVER['SERVER_PORT'];
    		$dirname = preg_replace('#(core/admin/|plugins/)?([\w+]+\.php)?$#i', '', explode('?', $_SERVER['REQUEST_URI'])[0]);
    		if (substr($dirname, -1) != '/') {
    			$dirname .= '/';
    		}
    		$racine = $protocol.$servername.$serverport.$dirname;
    		if(!plxUtils::checkSite($racine, false))
    			die('Error: wrong or invalid url');
    		return $racine;
    	}
    
    J'en profite pour retoucher le calcul de $serverport qui est plus strict.

    J'ai fait les essais sur les 4 serveur suivants : Lighttpd, Apache2, Nginx et PHP.
    Pour lancer le serveur interne de PHP, se placer dans le dossier de Pluxml et taper "php -S adresse_ip:numero_de_port". adresse_ip ressemble à quelque chose comme 192.168.1.64 et numero_de_port est en général 8080. Pour accèder au site, taper dans le navigateur http://192.168.1.64:8080.

    Pour faire quelques vérifications, j'ai mis dans le header du fichier core/admin/top.php les lignes suivantes :
    [== PHP ==]
    <!--
    <?php
    echo "  \$_SERVER['SCRIPT_NAME']: ".$_SERVER['SCRIPT_NAME']."\n";
    echo "  \$_SERVER['REQUEST_URI']: ".$_SERVER['REQUEST_URI']."\n";
    echo "\$_SERVER['DOCUMENT_ROOT']: ".$_SERVER['DOCUMENT_ROOT']."\n";
    echo "        dirname(__FILE__): ".dirname(__FILE__)."\n";
    echo "    plxUtils::getRacine(): ".plxUtils::getRacine()."\n";
    ?>
    -->
    
    Cela permet de connaitre la valeur de quelques variables en affichant le code source de la page sans perturber le serveur.
    Dans le cas général voici les valeurs qu'on obtient quand on pointe sur l'adresse http://bananapi/pluxml-55/core/admin/ :
    [== Indéfini ==]
    Lighttpd/1.4.35:
      $_SERVER['SCRIPT_NAME']: /pluxml-55/core/admin/index.php
      $_SERVER['REQUEST_URI']: /pluxml-55/core/admin/
    $_SERVER['DOCUMENT_ROOT']: /var/www
            dirname(__FILE__): /home/www/PluXml/core/admin
        plxUtils::getRacine(): http://bananapi/pluxml-55/
    
    Apache/2.4.10 (Debian):
      $_SERVER['SCRIPT_NAME']: /pluxml-55/core/admin/index.php
      $_SERVER['REQUEST_URI']: /pluxml-55/core/admin/
    $_SERVER['DOCUMENT_ROOT']: /var/www
            dirname(__FILE__): /home/www/PluXml/core/admin
        plxUtils::getRacine(): http://bananapi/pluxml-55/
    
    Nginx/1.6.2:
      $_SERVER['SCRIPT_NAME']: /pluxml-55/core/admin/index.php
      $_SERVER['REQUEST_URI']: /pluxml-55/core/admin/
    $_SERVER['DOCUMENT_ROOT']: /var/www
            dirname(__FILE__): /home/www/PluXml/core/admin
        plxUtils::getRacine(): http://bananapi/pluxml-55/
    
    PHP 5.6.17-0+deb8u1 Development Server:
      $_SERVER['SCRIPT_NAME']: /core/admin/index.php
      $_SERVER['REQUEST_URI']: /core/admin/
    $_SERVER['DOCUMENT_ROOT']: /home/www/PluXml
            dirname(__FILE__): /home/www/PluXml/core/admin
        plxUtils::getRacine(): http://192.168.30.132:8080/
    

    les valeurs de $_SERVER et dirname(__FILE__) ne coincident pas car la valeur /var/www est en fait un lien symbolique pointant sur /home/www/ (système de fichier ext4 sous Linux). Et la variable $_SERVER ne fait pas la résolution du nom de fichier comme __FILE__.

    Quand on pointe à l'adresse http://bananapi/~jpierre/pluxml-54/core/admin/ du serveur Pluxml de l'utilisateur jpierre, voici ce qu'on obtient :
    [== Indéfini ==]
    Lighttpd/1.4.35:
      $_SERVER['SCRIPT_NAME']: /~jpierre/pluxml-55/core/admin/index.php
      $_SERVER['REQUEST_URI']: /~jpierre/pluxml-55/core/admin/
    $_SERVER['DOCUMENT_ROOT']: /home/jpierre/public_html
            dirname(__FILE__): /home/jpierre/public_html/PluXml/core/admin
        plxUtils::getRacine(): http://bananapi/~jpierre/pluxml-55/
    
    Apache/2.4.10 (Debian):
      $_SERVER['SCRIPT_NAME']: /~jpierre/pluxml-55/core/admin/index.php
      $_SERVER['REQUEST_URI']: /~jpierre/pluxml-55/core/admin/
    $_SERVER['DOCUMENT_ROOT']: /var/www
            dirname(__FILE__): /home/jpierre/public_html/PluXml/core/admin
        plxUtils::getRacine(): http://bananapi/~jpierre/pluxml-55/
    
    Nginx/1.6.2
      $_SERVER['SCRIPT_NAME']: /pluxml-55/core/admin/index.php
      $_SERVER['REQUEST_URI']: /~jpierre/pluxml-55/core/admin/
    $_SERVER['DOCUMENT_ROOT']: /home/jpierre/public_html
            dirname(__FILE__): /home/jpierre/public_html/PluXml/core/admin
        plxUtils::getRacine(): http://bananapi/~jpierre/pluxml-55/
    
    PHP 5.6.17-0+deb8u1 Development Server:
      $_SERVER['SCRIPT_NAME']: /core/admin/index.php
      $_SERVER['REQUEST_URI']: /core/admin/
    $_SERVER['DOCUMENT_ROOT']: /home/jpierre/public_html/PluXml
            dirname(__FILE__): /home/jpierre/public_html/PluXml/core/admin
        plxUtils::getRacine(): http://192.168.30.132:8080/
    

    Si l'erreur est transparente dans la plupart des cas, ce n'est pas le cas pour Nginx.

    En passant, j'attire votre attention sur le fait que mettre le nom de l'hôte et le numéro de port dans getRacine est inutile et alourdit la page car les navigateurs peuvent utiliser les valeurs de l'adresse de la page affichée.

    Désolé d'être un peu technique
  • @bazooka07 : je ne sais pas ce qu'en pense Stéphane, mais la configuration que tu décris est quand même assez exotique.

    Et dire que mettre le nom d'hôte et le numéro de port dans getRacine alourdit la page, je ne vois pas comment, vu que les navigateurs n'ont justement pas à chercher quel est l'hôte et le port...
  • Bonjour
    je m'incruste ici pour apporter une petite idée

    Ne serait il pas bien de créer une nouvelle version de test exemple pluxml-5.5beta1 , 5.5beta2 ....
    après correction des bugs ou amélioration ce qui pourrait éliminer certains désagrément pendant
    les test par les beta-testeurs

    merci de votre avis

    a+
  • StéphaneStéphane Member, PluXml Former Project Manager
    @grisbi: tu as entièrement raison

    je publie donc une beta 2, disponible ici

    PluXml 5.5: Beta 2 (17/02/2016)
    https://github.com/pluxml/PluXml/releases/tag/5.5-beta-2

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • Bonne idée effectivement, J'en profite pour confirmer le bug sur la pagination des catégories sur cette version aussi (cf #81 de ce même fil).


    à plus,

    Gzyg
  • StéphaneStéphane Member, PluXml Former Project Manager
    Gzyg a écrit:
    J'en profite pour confirmer le bug sur la pagination des catégories sur cette version aussi (cf #81 de ce même fil).


    à plus,

    Gzyg

    Je viens de tester avec la beta 2. La pagination fonctionne chez moi.
    Pouvez-vous me donner + d’éléments sur votre environnement de test et le comportement du bug ?
    Qu'avez-vous dans la colonne Nb art/page sur l'écran de config des catégories ?
    Utilisez-vous des plugins ?

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • GzygGzyg Member
    février 2016 modifié
    Pluxml-.5.5-beta-2 - thème defaut - aucun plugin
    Création de deux articles
    Paramètres d'affichage article par page : 1
    Paramètres d'affichage archive par page : 1

    Résultat :
    - les pages home, archives et tags affichent bien un seul article avec le module de pagination en dessous de chaque article.
    - la page catégrorie affiche les deux articles (sans le module de navigation, forcément).

    (navigateurs : chrome, firefox, opera, konqueror, w3m et lynx sur Debian "Jessie")


    à plus,

    Gzyg
  • StéphaneStéphane Member, PluXml Former Project Manager
    @Gzyg: pour les catégories, la pagination dépend du paramètre dans la colonne Nb art/page sur l'écran de config des catégories ?
    Combien as-tu pour ta catégorie ?

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • Ha ok :)
    J'avais jamais fait attention à ce paramètre sur cette page... Pourquoi ne pas l'avoir mis sur la page de configuration de base ?
    Ça me semblerait plus logique d'avoir la même configuration pour toutes les options paginables (ou alors prévoir une config différenciée pour chaque option).


    à plus,

    Gzyg
  • StéphaneStéphane Member, PluXml Former Project Manager
    parce que c'est lié à chaque catégorie, avec un paramètre propre par catégorie.
    il faut donc que ce soit en rapport avec la configuration des catégories

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

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