5.6 rc4

abdelkader · février 2017

Bonjour

Est ce qu'on pourra avoir des sous-catégorie en cette nouvelle version ?

Stéphane · février 2017

abdelkader a écrit:

Bonjour

Est ce qu'on pourra avoir des sous-catégorie en cette nouvelle version ?

Bonjour. Non

Stéphane · février 2017

Dudy a écrit:

@Stephane, juste pour info, mon server est configuré avec la version 5.6.25
peut être que je dois faire une mise a jour vers la version 7?

Non je ne pense pas que le problème vienne de la version de php

Yannic · février 2017

[del]J'ai aussi eu un probleme d'image avec cette version en local sans utiliser ckeditor, plxeditor ou autre juste en utilisant la reecriture d'url par defaut, mais pas eu le temps pour le moment de tester sur mon serveur pour voir si cela venais de moi ou de la version.[/del]
Edit: mon problème était du à plxMyMultiLingue 0.8 pre1

Dudy · février 2017

Stéphane a écrit:

Dudy a écrit:

@Stephane, juste pour info, mon server est configuré avec la version 5.6.25
peut être que je dois faire une mise a jour vers la version 7?

Non je ne pense pas que le problème vienne de la version de php

@Stephane
je viens d'installer le plugin MybetterUrl et tout marche bien avec l'ecriture Url activé, l'image est present Back et frontEnd
bonne journée

Stéphane · février 2017

Version 5.6 pre3 dispo

Correction d'un bug dans la réécriture d'url empechant l'affichage des images dans les articles

Pre-release 3 (23/02/2017)
https://github.com/pluxml/PluXml/releases/tag/5.6pre3

Liste des évolutions et des changements:
https://github.com/pluxml/PluXml/blob/5.6pre3/readme/CHANGELOG

Kristen · février 2017

C'est pas un bug mais avec la version 5.6 on ne peut plus mettre en place un édito comme indiqué ici vu qu'il n'y a plus de fichier style.css ?

Stéphane · février 2017

Kristen a écrit:

C'est pas un bug mais avec la version 5.6 on ne peut plus mettre en place un édito comme indiqué ici vu qu'il n'y a plus de fichier style.css ?

utilise le fichier themes/defaut/css/theme.css

Kristen · février 2017

Merci c'est ce que j'étais en train de regarder.

Kristen · février 2017

Stéphane a écrit:

Kristen a écrit:

C'est pas un bug mais avec la version 5.6 on ne peut plus mettre en place un édito comme indiqué ici vu qu'il n'y a plus de fichier style.css ?

utilise le fichier themes/defaut/css/theme.css

Ça fonctionne en mettant dans le home.php

[== Indéfini ==]
<article role="article" class="edito">
<?php $plxShow->lastArtList('<header><h1><a href="#art_url" title="#art_title">#art_title</a></h1><p>Par #art_author</p></header><section>#art_content(9999)</section>', 1, '002') ?>
</article>

[del]mais si on met
[/del]

[== Indéfini ==]
<?php 
$catEdito = '002';
if($plxShow->plxMotor->aCats[$catEdito]['active']) {
	$plxShow->lastArtList('<article role="article" class="edito"><header><h1><a href="#art_url" title="#art_title">#art_title</a></h1><p>Par #art_author</p></header><section>#art_content(9999)</section></article>', 1, $catEdito); 
}
?>

[del]ça ne fonctionne plus

[/del]
ÉDIT
si ça fonctionne autant pour moi, j'ai du me mélanger les pinceaux, désolé

NaBiSs · février 2017

Salut Stéphane,

J'ai détecté un problème de réécriture d'URL sur les pages statiques, quand on utilise un lien avec ancre dans une même page statique.

Version : PluXml 5.6pre3

Pour reproduire le défaut :
Créer une page statique, et mettre un lien commençant par un #: <a href="#ancre"></a>

Ce lien sera réécrit de cette façon : http://racine/#ancre à la place de http://racine/staticX/nomdepage#ancre

Stéphane · mars 2017

Release Candidate 1 (01/03/2017)
https://github.com/pluxml/PluXml/releases/tag/5.6rc1

Liste des évolutions et des changements:
https://github.com/pluxml/PluXml/blob/5.6rc1/readme/CHANGELOG

Stéphane · mars 2017

NaBiSs a écrit:

Salut Stéphane,

J'ai détecté un problème de réécriture d'URL sur les pages statiques, quand on utilise un lien avec ancre dans une même page statique.

Version : PluXml 5.6pre3

Pour reproduire le défaut :
Créer une page statique, et mettre un lien commençant par un #: <a href="#ancre"></a>

Ce lien sera réécrit de cette façon : http://racine/#ancre à la place de http://racine/staticX/nomdepage#ancre

Confirmé.
https://github.com/pluxml/PluXml/issues/205

Merci

EDIT: résolu
https://github.com/pluxml/PluXml/commit/cb3ce3aa8d5b727e4df056377b7bea8036108404
nb: le correctif n'est pas présent dans la rc1

bg62 · mars 2017

lut;)
Le fameux problème d'encodage des mots du style " d'é " ou " l'é ", etc est-il vraiment corrigé dans cette version ...
( je sais c'est vieux et connu, mais, tant qu'à faire ...

)

Stéphane · mars 2017

Release Candidate 2 (03/03/2017)
https://github.com/pluxml/PluXml/releases/tag/5.6rc2

Liste des évolutions et des changements:
https://github.com/pluxml/PluXml/blob/5.6rc2/readme/CHANGELOG

Yannic · mars 2017

Stéphane a écrit:

Release Candidate 2 (03/03/2017)
https://github.com/pluxml/PluXml/releases/tag/5.6rc2

Liste des évolutions et des changements:
https://github.com/pluxml/PluXml/blob/5.6rc2/readme/CHANGELOG

Salut, après avoir vu ( http://forum.pluxml.org/viewtopic.php?id=5663 )

Je suis parti donc tester en russe multilingue et.. c'est la cata :P

En fait d'une façon générale les caractères russes en sont pas pris en charge dans les urls que ce soit articles, tags, catégories, pages alors que normalement en UTF-8 il ne devrais pas y avoir de souci à les avoir dans les urls exemple: [url=https://ru.wikipedia.org/wiki/Биткойн]https://ru.wikipedia.org/wiki/Биткойн[/url] et dans les noms de fichiers. D'ailleurs je n'ai même pas réussi à mettre en page d'acceuil, ni même à afficher une page statique dont le titre était en russe.
Une catégorie en russe renvera vers le numero de catégorie, un tag en russe renverra vers une page 404, une article titre en russe ne passe pas (en lien) et se rabat sur "nouvel article" en francais, une page statique avec un titre en russe ne s'affichera pas.

(mais peut-être que c'est un trop gros chantier pour cette version vu l'avancement ? je ne sais pas, je n'ai pas encore regardé tout le core de pluxml mais j'ai vu que juste corriger les fonctions de title2url($str) et de title2filename($str) du core class.plx.utils pour accepter les caractères russes en remplacant tous les [:alnum:] par des :alnum: ne suffisait pas (le fichier est bien enregistré avec son titre en russe et le format du nom de fichier à l'air respecté mais cela bug après lors de l'affichage dans l'administration car il n'arrive pas à comprendre la date de l'article, donc c'est à creuser un peu plus quelque part et surtout à tester) et je ne sais pas si tous les caractères russes fonctionnent dans les noms de fichiers même si d’après mon test oui: [url]http://cryptocoins.exposed/rc2/АаБбВвГгДдЕеЁёЖжЗзИиЙйКкЛлМмНнОоПпРрСсТтУуФфХхЦцЧчШшЩщЪъЫыЬьЭэЮюЯя.md[/url]

bg62 · mars 2017

lut;)
premiers retours :
1 - depuis l'admin, je clique sur un article existant et :

2 - je ne parviens pas à afficher "MySocialButtons - Version 1.4.1 (06/11/2014)" ni dans les articles ni dans les pages statiques ...
@+

Stéphane · mars 2017

@bg62: vérifie si php5 est activé sur ton serveur

Yannic · mars 2017

Yannic a écrit:

En fait d'une façon générale les caractères russes en sont pas pris en charge dans les urls que ce soit articles, tags, catégories, pages alors que normalement en UTF-8 il ne devrais pas y avoir de souci à les avoir dans les urls ... et dans les noms de fichiers ...

Une solution de facilité que j'aurais trouvé c'est la translittération des caractères russes en ne changeant que la fonction removeAccents de plx.utils
( ici à la facon de http://www.translityandex.ru/ qui diffère un peu des différentes normes https://fr.wikipedia.org/wiki/Translitt%C3%A9ration_des_caract%C3%A8res_cyrilliques_russes mais qui selon translityandex.ru est meilleur pour le SEO )

public static function removeAccents($str,$charset='utf-8') {

		$str = htmlentities($str, ENT_NOQUOTES, $charset);
		
		$a = array('а', 'б', 'в', 'г', 'д', 'е', 'ё', 'ж', 'з', 'и', 'й', 'к', 'л', 'м', 'н', 'о', 'п', 'р', 'с', 'т', 'у', 'ф', 'х', 'ц', 'ч', 'ш', 'щ', 'ъ', 'ы', 'ь', 'э', 'ю', 'я', 'А', 'Б', 'В', 'Г', 'Д', 'Е', 'Ё', 'Ж', 'З', 'И', 'Й', 'К', 'Л', 'М', 'Н', 'О', 'П', 'Р', 'С', 'Т', 'У', 'Ф', 'Х', 'Ц', 'Ч', 'Ш', 'Щ', 'Ъ', 'ы', 'Ь', 'Э', 'Ю', 'Я');
		$b = array('a', 'b', 'v', 'g', 'd', 'e', 'yo', 'zh', 'z', 'i', 'y', 'k', 'l', 'm', 'n', 'o', 'p', 'r', 's', 't', 'u', 'f', 'h', 'c', 'ch', 'sh', 'shch', '', 'y', '', 'e', 'yu', 'ya', 'a', 'b', 'v', 'g', 'd', 'e', 'yo', 'zh', 'z', 'i', 'y', 'k', 'l', 'm', 'n', 'o', 'p', 'r', 's', 't', 'u', 'f', 'h', 'c', 'ch', 'sh', 'shch', '', 'y', '', 'e', 'yu', 'ya');
		$str = str_replace($a, $b, $str);
		
		$a = array('À', 'Á', 'Â', 'Ã', 'Ä', 'Å', 'Æ', 'Ç', 'È', 'É', 'Ê', 'Ë', 'Ì', 'Í', 'Î', 'Ï', 'Ð', 'Ñ', 'Ò', 'Ó', 'Ô', 'Õ', 'Ö', 'Ø', 'Ù', 'Ú', 'Û', 'Ü', 'Ý', 'ß', 'à', 'á', 'â', 'ã', 'ä', 'å', 'æ', 'ç', 'è', 'é', 'ê', 'ë', 'ì', 'í', 'î', 'ï', 'ñ', 'ò', 'ó', 'ô', 'õ', 'ö', 'ø', 'ù', 'ú', 'û', 'ü', 'ý', 'ÿ', 'Ā', 'ā', 'Ă', 'ă', 'Ą', 'ą', 'Ć', 'ć', 'Ĉ', 'ĉ', 'Ċ', 'ċ', 'Č', 'č', 'Ď', 'ď', 'Đ', 'đ', 'Ē', 'ē', 'Ĕ', 'ĕ', 'Ė', 'ė', 'Ę', 'ę', 'Ě', 'ě', 'Ĝ', 'ĝ', 'Ğ', 'ğ', 'Ġ', 'ġ', 'Ģ', 'ģ', 'Ĥ', 'ĥ', 'Ħ', 'ħ', 'Ĩ', 'ĩ', 'Ī', 'ī', 'Ĭ', 'ĭ', 'Į', 'į', 'İ', 'ı', 'Ĳ', 'ĳ', 'Ĵ', 'ĵ', 'Ķ', 'ķ', 'Ĺ', 'ĺ', 'Ļ', 'ļ', 'Ľ', 'ľ', 'Ŀ', 'ŀ', 'Ł', 'ł', 'Ń', 'ń', 'Ņ', 'ņ', 'Ň', 'ň', 'ŉ', 'Ō', 'ō', 'Ŏ', 'ŏ', 'Ő', 'ő', 'Œ', 'œ', 'Ŕ', 'ŕ', 'Ŗ', 'ŗ', 'Ř', 'ř', 'Ś', 'ś', 'Ŝ', 'ŝ', 'Ş', 'ş', 'Š', 'š', 'Ţ', 'ţ', 'Ť', 'ť', 'Ŧ', 'ŧ', 'Ũ', 'ũ', 'Ū', 'ū', 'Ŭ', 'ŭ', 'Ů', 'ů', 'Ű', 'ű', 'Ų', 'ų', 'Ŵ', 'ŵ', 'Ŷ', 'ŷ', 'Ÿ', 'Ź', 'ź', 'Ż', 'ż', 'Ž', 'ž', 'ſ', 'ƒ', 'Ơ', 'ơ', 'Ư', 'ư', 'Ǎ', 'ǎ', 'Ǐ', 'ǐ', 'Ǒ', 'ǒ', 'Ǔ', 'ǔ', 'Ǖ', 'ǖ', 'Ǘ', 'ǘ', 'Ǚ', 'ǚ', 'Ǜ', 'ǜ', 'Ǻ', 'ǻ', 'Ǽ', 'ǽ', 'Ǿ', 'ǿ');
		$b = array('A', 'A', 'A', 'A', 'A', 'A', 'AE', 'C', 'E', 'E', 'E', 'E', 'I', 'I', 'I', 'I', 'D', 'N', 'O', 'O', 'O', 'O', 'O', 'O', 'U', 'U', 'U', 'U', 'Y', 's', 'a', 'a', 'a', 'a', 'a', 'a', 'ae', 'c', 'e', 'e', 'e', 'e', 'i', 'i', 'i', 'i', 'n', 'o', 'o', 'o', 'o', 'o', 'o', 'u', 'u', 'u', 'u', 'y', 'y', 'A', 'a', 'A', 'a', 'A', 'a', 'C', 'c', 'C', 'c', 'C', 'c', 'C', 'c', 'D', 'd', 'D', 'd', 'E', 'e', 'E', 'e', 'E', 'e', 'E', 'e', 'E', 'e', 'G', 'g', 'G', 'g', 'G', 'g', 'G', 'g', 'H', 'h', 'H', 'h', 'I', 'i', 'I', 'i', 'I', 'i', 'I', 'i', 'I', 'i', 'IJ', 'ij', 'J', 'j', 'K', 'k', 'L', 'l', 'L', 'l', 'L', 'l', 'L', 'l', 'l', 'l', 'N', 'n', 'N', 'n', 'N', 'n', 'n', 'O', 'o', 'O', 'o', 'O', 'o', 'OE', 'oe', 'R', 'r', 'R', 'r', 'R', 'r', 'S', 's', 'S', 's', 'S', 's', 'S', 's', 'T', 't', 'T', 't', 'T', 't', 'U', 'u', 'U', 'u', 'U', 'u', 'U', 'u', 'U', 'u', 'U', 'u', 'W', 'w', 'Y', 'y', 'Y', 'Z', 'z', 'Z', 'z', 'Z', 'z', 's', 'f', 'O', 'o', 'U', 'u', 'A', 'a', 'I', 'i', 'O', 'o', 'U', 'u', 'U', 'u', 'U', 'u', 'U', 'u', 'U', 'u', 'A', 'a', 'AE', 'ae', 'O', 'o');
		$str = str_replace($a, $b, $str);		
		
		$str = preg_replace('#\&([A-za-z])(?:acute|cedil|circ|grave|ring|tilde|uml|uro)\;#', '\1', $str);
		$str = preg_replace('#\&([A-za-z]{2})(?:lig)\;#', '\1', $str); # pour les ligatures e.g. '&oelig;'
		$str = preg_replace('#\&[^;]+\;#', '', $str); # supprime les autres caractères
		return $str;
	}

C'est une solution de facilité, qui est simple à mettre en place et ne génère pas de bug.
Mais c'est vraiment la solution simple (car pas d'url en russe) et si plus tard une autre langue de ce style était ajoutée il faudrait encore modifier la fonction ( donc pas idéale à moins si cela est possible d'un hook qui permette des plugins de transliteration )

Toutefois, en faisant cela, maintenant tout fonctionne (page statique en accueil, tags et catégories) sans aller modifier quoi que ce soit ailleurs sur http://cryptocoins.exposed/rc2/ru/

La meilleure solution serais de changer le alnum comme décrit plus haut mais cela risque de nécessité d'autres changements ailleurs aussi bien dans le core que dans certains plugins, a tester plus profondement donc

bg62 · mars 2017

Stéphane a écrit:

@bg62: vérifie si php5 est activé sur ton serveur

pas de soucis au niveau de la version de 'php' ...

donc ... ???

Jerry Wham · mars 2017

@Yannic : quid des autres langues ? Existe-t-il des méthodes équivalentes pour le mandarin, le japonais, le sanskri... ?
Il faudrait peut-être envisager un nouveau fichier optionnel dans le dossier langue, par langue incriminée, qui serait chargé dans la fonction removeAccents (du style if is_file ... require ...), en fonction de la langue utilisée et qui permettrait de faire la conversion ?
Qu'en pense Stéphane ?

Yannic · mars 2017

Jerry Wham a écrit:

@Yannic : quid des autres languesu ? Existe-t-il des méthodes équivalentes pour le mandarin, le japonais, le sanskri... ?

Oui cela existe mais pour moi, cest plus une solution de dépannage ou un patch sur le bobo en attendant un vrai support des caractères un jour dans une autre version, à moins que cela ne soit facile a faire dans celle-la.

A voir suivant ce Stéphane en pensera.

Jerry Wham · mars 2017

Il y a un bug sur l'import de médias depuis le formulaire d'un nouvel article. Si on importe une image depuis un nouvel article, on a systématiquement un "Security error : invalid or expired token"

Stéphane · mars 2017

Jerry Wham a écrit:

Il y a un bug sur l'import de médias depuis le formulaire d'un nouvel article. Si on importe une image depuis un nouvel article, on a systématiquement un "Security error : invalid or expired token"

tu parles de l'image d'accroche ?

Jerry Wham · mars 2017

@Stephane : Oui.
Mais pas que. Ça le fait aussi directement depuis la page core/admin/medias.php. A priori, la variable $_POST est vide quand le formulaire est envoyé.

Jerry Wham · mars 2017

Je viens de tester avec une archive fraîche, sans plugin, thème par défaut. Le problème persiste.

Jerry Wham · mars 2017

En fait, ça fonctionne. C'est dû à la taille de l'image qui est trop importante a priori. Pourtant, elle pèse 10.9 Mo alors que la taille maxi indiquée est de 64 Mo.
Dans le log php, j'ai le warning suivant :

PHP Warning: POST Content-Length of 11515046 bytes exceeds the limit of 3145728 bytes in Unknown on line 0

Stéphane · mars 2017

@Jerry Wham: tu peux regarder stp si c'est pas la fonction qui créer la miniature qui plante. si l'image est trop grosse, les fonctions php imagexxxx fonctionnent pas (plxUtils::makeThumb)

bazooka07 · mars 2017

PHP impose des limites pour envoyer des fichiers sur le serveur. C'est paramétré dans le fichier php.ini.
Pour avoir une idée des limites imposées, on peut créer un fichier php sur le serveur avec le code suivant:

[== PHP ==]
<?php
header('Content-type: text/plain');
foreach(explode(' ', 'max_file_uploads upload_max_filesize post_max_size') as $field) {
	echo "$field: ".ini_get($field)."\n";
}
echo "\n".phpversion()."\n";
?>

En ouvrant ce fichier dans Firefox par exemple, on a ce résultat :

En clair:
[list=*]
[*]On ne peut pas téléverser plus de 20 fichiers à la fois,[/*]
[*]aucun fichier ne peut avoir une taille supérieure à 2Mo[/*]
[*]la taille du lot de fichiers ne peut dépasser 8Mo[/*]
[/list]

PHP version 5.6 derrière Apache sur une Ubuntu 16.04
Cela serait intéressant d'afficher ces limites dans "core/admin/parametres_infos.php".
J'avais été confronté à ces limites quand j'avais écrit le plugin html5uploader

A++

zetrader · mars 2017

bazooka07 a écrit:

En clair:
[list=*]
[*]On ne peut pas téléverser plus de 20 fichiers à la fois,[/*]
[*]aucun fichier ne peut avoir une taille supérieure à 2Mo[/*]
[*]la taille du lot de fichiers ne peut dépasser 8Mo[/*]
[/list]

PHP version 5.6 derrière Apache sur une Ubuntu 16.04
Cela serait intéressant d'afficher ces limites dans "core/admin/parametres_infos.php".
J'avais été confronté à ces limites quand j'avais écrit le plugin html5uploader

A++

Les limites ont un rapport avec la version de php ou le serveur ?
Quand je fais le même test :
"max_file_uploads: 20
upload_max_filesize: 64M
post_max_size: 64M

7.1.2"

Le fait que les limites soient plus élevées est lié à la version de php ou à mon hébergeur (1and1) ?

5.6 rc4

Réponses