Beta testeurs pour la 5.5

bankai

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

cpalo

Bonjour,

J'aurai la même demande

Merci d'avance

Stéphane

@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>

je-evrard

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

bankai

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éphane

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>

je-evrard

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>

je-evrard

tu as été plus rapide que moi stef ! héhé

bankai

Le code fonctionne parfaitement Stéphane, merci beaucoup ( Merci je-evrard aussi)

cpalo

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éphane

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>	

cpalo

Merci . C'est OK

bazooka07

@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.

bazooka07

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.

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éphane

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 ?

Stéphane

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

grisbi

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éphane

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.

sitinweb

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

Gzyg

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

bazooka07

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

Jerry Wham

@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...

grisbi

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éphane

@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

Gzyg

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éphane

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 ?

Gzyg

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éphane

@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 ?

Gzyg

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éphane

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