Pluxml 5.5 fonctionne parfaitement dans mon cas, et avec la nouvelle gestion des miniatures (tropbon) -> http://cfdev.fr/blog.
C'est un sacré LEVELUP pour le CMS Pluxml bravo à Stéphane et tous les contributeurs
@Stéphane je suis content de voir que la nouvelle gestion/présentation des thèmes fasse l’unanimité
D'après ma compréhension, arrivé au level 6 un commentaire recevra la classe level-max et son indentation sera bridée par theme.css.
Néanmoins Stéphane a précisé que virtuellement on peut continuer à indenter les réponses.
Cela sous-entend que l'on peut toujours continuer à intercaler des réponses entre des commentaires d'un niveau <= level-5, ce qui peut entraîner une mécompréhension à la lecture des messages au final (je l'ai testé de mon côté, et effectivement cela devient compliqué si on n'ajoute pas des niveaux d'indentation).
Et là pour démêler quel message répondait à qui, bon courage.
Sans ajouter d'autres niveaux d'indentation dans le CSS, je vois deux solutions :
[list=*]
[*]que passé le level-5 (par exemple), toutes les réponses soient chaînées les unes après les autres sans pouvoir s'intercaler entre deux (ce serait le plus propre et fonctionnel)[/*]
[*]qu'on fasse disparaître le bouton "répondre" soit par design dans le code, soit en le rendant invisible par CSS (défaut: les visiteurs ne comprendront peut-être pas comment répondre si le bouton est 3km au dessus)[/*]
[/list]
Quand le paramètre est de type numeric, on le stocke dans le plugin comme une chaine de caractères.
Et fatalement plxPlugin::getParam(..) retourne toujours une chaine de caractères même si on attend une valeur numérique type integer ou float.
Frustrant !
Autre point gênant à un niveau moindre :
le constructeur __construct stocke des valeurs dans le tableau plug.
le nom de certaines clés de ca tableau prête à confusion par parametres.xml laisse supposer qu'on pointe vers un fichier parametres.xml alors qu'en réalité on pointe vers monplugin.xml.
Une clé plus pertinente serait tout simplement parametres. De la même façon infos.xml pourrait être remplacé par infos tout simplement.
Il serait bien de rajouter un clé supplémentaire, nommée par exemple "repo" pour stocker l'url où on peut télécharger le plugin ou sa mise à jour. Sujet évoqué vers octobre dans un autre fil de discussion.
Je souhaite avoir plusieurs dossiers de données (data/ par défaut) pour tester différents sites avec la version en cours de développement de Pluxml, avec un thème différent pour chaque site. J'ai bien avancé sur un plugin qui fait le job, c'est à dire renommer le dossier datas avec déjà plein d'articles et de pages statiques et basculer entre différents dossiers de données.
D'où l'idée de lancer l'installation de Pluxml avec install.php et sans dossier data fichier config.php.
Et là c'est la catastrophe comme le montre la copie d'écran ci-dessous:
Si le dossier data/medias se crée bien, les dossiers data/articles, data/statiques, data/commentaires et plus grave data/configuration sont aux abonnés absents. Et les fichiers de config se retrouvent à la racine du site.
Pas cool !
Autre souci, j'aimerais bien pouvoir choisir le nom du dossier de données à l'installation
Du coup j'ai révisé le fichier install.php qui crée un dossier de données complet avec le nom que je veux et le fichier config.php ad'hoc
Je fais un pull request (branche install). Vu la simplicité de la modification, on pourra l'intégrer facilement dans la version en cours de dév.
Remarque l'ajout des dossiers data, plugins et du fichier config.php dans l'archive zip de Pluxml devient inutile. A spécifier aussi dans .gitignore
Je vais aller y jeter un coup d'oeil.
Cela m'interesse doublement car j'avais travaillé sur une installation personnalisé pour:
- ne pas avoir à réinstaller à chaque fois les 5-6 plugins que j'installe toujours
- avoir un dossier médias avec ses sous-dossiers
- avoir un dossier data "vide" prêt à l'emploi ou un dossier data-testing avec des données exemples
Mais pour cela je n'étais pas parti sur un plugin, mais des modifications manuelles dans install.php et un choix à definir dans le config.php
Permettez-moi de m'immiscer dans la cour des grands pour signaler un bug dans la version 5.5 Beta 3, thème Defaut.
Lorsqu'on clique sur le lien Nb de commentaires sur la page d'accueil, celui-ci nous emmène bien sur le premier commentaire de l'article.
En revanche, une fois dans l'article, lorsqu'on clique sur le lien Nb de commentaires (artNbCom()), alors qu'on devrait être dirigés en bas de page (#comments), on est dirigés sur la page d'accueil car le lien produit est : racine du site/#comments à la place de racine du site/article.html#c0005-1
Bien sûr, j'ai essayé de remplacer l'url par
[== PHP ==]
<?php $plxShow->comUrl() ?>
mais ça ne fonctionne pas.
J'ai activé la réécriture d'url. C'est peut-être la raison ?
Mais pour cela je n'étais pas parti sur un plugin, mais des modifications manuelles dans install.php et un choix à definir dans le config.php
Tout le monde n'a pas l'habitude de tripatouiller du code PHP.
Le plugin s'appelera moveMyDatas. Ses fonctionalités seront :
[list=*]
[*]renommer un dossier de données existant avec correction des liens dans le dossier[/*]
[*]créer un dossier de données vide avec les fichiers utiles et le nom que l'on veut[/*]
[*]sélectionner un dossier dans une liste déroulante de tous les dossiers contenant un fichier parametres.xml[/*]
[/list]
Le taf est bien avancé.
J'espère publier une version en début de semaine.
Permettez-moi de m'immiscer dans la cour des grands pour signaler un bug dans la version 5.5 Beta 3, thème Defaut.
Lorsqu'on clique sur le lien Nb de commentaires sur la page d'accueil, celui-ci nous emmène bien sur le premier commentaire de l'article.
En revanche, une fois dans l'article, lorsqu'on clique sur le lien Nb de commentaires (artNbCom()), alors qu'on devrait être dirigés en bas de page (#comments), on est dirigés sur la page d'accueil car le lien produit est : racine du site/#comments à la place de racine du site/article.html#c0005-1
Bien sûr, j'ai essayé de remplacer l'url par
[== PHP ==]
<?php $plxShow->comUrl() ?>
mais ça ne fonctionne pas.
J'ai activé la réécriture d'url. C'est peut-être la raison ?
@bazooka07: merci pour les dernières modifs que tu proposes sur le dossier data. c'est une bonne idée, mais ça ne sera pas pris en compte pour la 5.5 car on est trop près de la sortie. Je ne prends plus en compte pour cette version les nouvelles evols, mais que de la correction de bug. ça sera étudié sur la suivante.
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Hello,
je ne sais pas si c'est le bon moment du développement pour en parler mais il y a un comportement que je souhaitais vous soumettre.
Si l'on a l'interface de PluXml dans une langue L et qu'une extension ne possède pas le fichier de lange pour la langue L,
l'affichage des textes ne se fait pas du tout.
Il faudrait faire une vérification de l'existence du fichier langue et à défaut utiliser un des fichiers présents.
Peut-être inviter l'utilisateur à l'aide d'un message du style "Attention votre langue n'est pas prise en compte par cette extension, choisissez dans la liste la langue que vous souhaitez utiliser avec celle-ci"
Du coup il faudrait créer une variable "langue utilisée pour Tel extension".
Mais au moins vérifier l'existence et utiliser un fichier présent, ça fait bizarre de se retrouver avec des noms de variables partout.
Merci de votre attention !
On essaie d'abord la langue par défaut, puis l'anglais en, ensuite le français fr, puis ensuite toutes les langues présentes dans le dossier core/lang.
En cas d'échec, on reste sur la langue par défaut.
C'est une première solution.
Dans l'idéal, il faudrait un ordre de préférence dans le panneau de config avancé. Par exemple, sur les Ramblas, on préférera l'espagnol à defaut du catalan, plutôt que l'anglais.
Oublie mon post précèdent. Voici une solution plus élégante.
Préambule: Contrairement à la page 12 du manuel du développeur pour Pluxml, on suppose que la déclaration du constructeur de la classe du plugin déclare une langue par défaut comme ceci:
[== PHP ==]
class monPlugin extends plxPlugin {
public function __construct($default_lang='fr') {
parent::__construct($default_lang);
# etc, etc, ...
}
}
Il faut modifier les 2 méthodes suivantes dans le fichier core/lib/class.plx.plugins.php comme suit et dans cet ordre :
pour la class plxPlugin vers la ligne n°289
[== PHP ==]
public function __construct($lang=false) {
$plugName= get_class($this);
$this->plug = array(
'dir' => PLX_PLUGINS,
'name' => $plugName,
'filename' => PLX_PLUGINS.$plugName.'/'.$plugName.'.php',
'parameters.xml'=> PLX_ROOT.PLX_CONFIG_PATH.'plugins/'.$plugName.'.xml',
'infos.xml' => PLX_PLUGINS.$plugName.'/infos.xml'
);
$folder = PLX_PLUGINS.$plugName.'/lang/';
if (empty($lang) or !is_readable($folder.$lang.'.php')) {
$prefered_langs = explode(' ', 'en fr nl es oc pt de it pl ro ru');
$lang = false;
foreach($prefered_langs as $pr) {
if (is_readable($folder.$pr.'.php')) {
$lang = $pr;
break;
}
}
}
$this->default_lang = $lang;
if (!empty($lang)) {
$this->aLang = $this->loadLang($folder.$lang.'.php');
}
$this->loadParams();
if(defined('PLX_ADMIN'))
$this->getInfos();
}
pour la class plxPlugins vers la ligne n°33
[== PHP ==]
public function getInstance($plugName) {
$filename = PLX_PLUGINS.$plugName.'/'.$plugName.'.php';
if(is_file($filename)) {
include_once($filename);
if (class_exists($plugName)) {
$lang = $this->default_lang;
if (is_readable(PLX_PLUGINS.'$plugName.'/lang/'.$lang.'.php')) {
return new $plugName($lang);
} else {
return new $plugName();
}
}
}
return false;
}
Le classement des langues dans $prefered_lang est un peu arbitraire. J'ai tenté de faire au mieux selon les sensibilités linguistiques de chaque région
(en en tête, nl après fr pour la Belgique, pt après es pour l'Espagne, ...).
Je suis surpris de ne pas voir le catalan, langue couramment pratiquée au bord de la Méditerrannée de part et d'autre des Pyrénées
Pour finir 2 recommandations
penser à déclarer une langue par défaut dans le __construct du plugin
Corriger la page 12 du manuel du développeur
En fait jusqu'il y a une trentaine d'année l'occitan et le catalan étaient considérés comme une même langue, il faut dire qu'on partage 95% de notre vocabulaire. À titre d'exemple, c'est comme si un français de France parle avec un francophone du Québec, ce sont les mêmes mots, une prononciation différente et quelques mots d'anglais, d'espagnol dans le cas du catalan.
Occitan : Soi de Tolosa e m'agrada Pluxml ! Mercé/Gràcia de (la) vòstra contribucion al projècte !
Catalan : Sòc de Tolosa i m'agrada Pluxml ! Gràcia/Mercè de la vostre contribució al projecte !
Merci pour ta contribution bazooka07 ! J'espère que ça sera pris en compte
Je trouve assez frustant d'avoir comme réponse allow_url_fopent est désactivé lorsqu'on vérifie la dernière version en ligne de Pluxml dans le script core/admin/parametres_infos.php du back-office.
Pourtant, l'usage de curl dans PHP permet de contourner aisément cette limitation.
Et en cas de succès, il serait plus élégant de nous confirmer la version en ligne plutôt que de nous rappeler la version actuellement utilisée et qui est déjà indiquée dans la sidebar.
Voici comment modifier la méthode checkMaj dans core/lib/plx.class.admin.php et le fichier core/lang/fr.php:
[== PHP ==]
'L_PLUXML_UPTODATE' => 'Vous utilisez la dernière version (#VERSION#) ou une version plus récente de PluXml.',
'L_PLUXML_UPDATE_AVAILABLE' => 'La nouvelle version #VERSION# de PluXml est sortie ! Vous pouvez la télécharger sur',
Petit détail :
Sur la sidebar de l'édition d'un article, dans le fichier core/admin/article.php "catégories" s'appellent "emplacement". Et en dessous d'emplacement, on reparle de catégorie. Pas très homogène.
Autre petit bug
Dans core/admin/index.php on utilise la constante L_CATEGORY_HOME.
Dans core/admin/article.php on utilise la constante L_CATEGORY_HOME_PAGE.
Tout cela pour afficher "Page d'accueil". Si on pouvait unifier, cela faciliterait le travail des traducteurs.
Si c'est possible, il serait bon pour les 'images d'accorche' de pouvoir faire apparaître les dimensions, afin de ne pas avoir de soucis avec certains validatuers.
par exemple :
1 - insertion via CKEditor:
" <p><img alt="" src="data/medias/0016/fond-ecran-texte-1000.jpg" style="width: 1000px; height: 643px;" /></p> "
2 - insertion via ' image d'accorche":
<img class="art_thumbnail" src="http://localhost/PluXml55-master/data/medias/0016/fond-ecran-texte-1000.jpg" alt="image d'accroche alt" title="image d'accroche" />
Pour l'accroche, j'ai déjà utilisé la fonction plus d'une centaine de fois et je pense n'avoir jamais choisi la version générique qui lance un format que je trouve trop "hors de contrôle" pour mes besoins. Donc la solution à l'intérieur d'une page ressemble à
qui peut sembler un peu long mais c'est simplement un copier-coller. Mais la plupart du temps, je saute l'étape de la largeur et hauteur pour l'inclure dans mes paramètres de rognage de cImage, quelque chose comme
ce qui permet d'utiliser la même image à plusieurs endroits.
En passant, je suis surpris de voir dans l'exemple une insertion "en ligne" de CSS dans une balise IMG plutôt que de paramétrer les dimensions directement, je me questionne sur l'avantage s'il y en a un.
@Pierre : ce que j'en disais ... juste pour les différents sites de tests ( genre GTMetrix ) qui vont renvoyer les erreurs ... après niveau codage, là pour moi = ??? ( je ne me sers que de ce que j'ai dans l'admin .
Je viens également de remarquer autre chose : les images de ce genre ' images d'accroche ' ne sont pas reprises dans le flux rss des articles ... ??? normal ou bug, car dommage
Je suis souvent perplexe (et plus diverti qu'informé) devant ces petits robots qui nous balancent les bonnes pratiques. Je corrige ce qui coûte cher en ressources ou qui nuit au SEO mais il faut en prendre et en laisser, on ne satisfera jamais tous et chacun de ces sites d'auto-masochisme.
L'admin, c'est bon pour le contenu des articles, pour les créer, leur assigner des accroches et des catégories, etc. Mais pour monter le format d'une page (utiliser une image d'accroche) c'est très suggéré d'utiliser un éditeur. Même si toutes les pages sont accessibles par l'admin, c'est assez pénible de travailler dans la fenêtre monochrome qui foue en l'air les indentations pour ne plus rien y comprendre. Un éditeur est un bon outil pour apprendre aussi.
Personnellement j'aime bien mettre les tailles des images afin que le navigateur réserve l'espace à l'image et ne fasse pas "sauter" le texte en cours de chargement. Mais chacun se le voit
Oui, j'ai presque toujours des paramètres de dimensions aussi, ma question était pourquoi le faire en CSS (...style='""...) plutôt que l'écrire directement dans la balise IMG.
Il semble que la version 5.5 dePluxml soit scellée, voire sur-scellée à double tour.
Habité à la philosophie Debian "Ca sort quand c'est prêt", je ne peux me résoudre à utiliser un pluxml avec un code imparfait malgré plusieurs pull-requests sans réponse.
J'ose encore faire quelque remarque :
La méthode PlxShow::staticUrl(($type='relatif') déclare le paramètre $type et ne l'utilise pas.
Cela ne dérange personne, sauf que j'ai besoin de connaitre l'url d'une page statique à partir de son identifiant relevé dans le panneau de configuration des pages statiques.
Pour ceux qui ne peuvent se résoudre d'attendre la version d'après 5.5, voici comment faire :
[== PHP ==]
public function staticUrl($type='relatif', $staticId=false) {
# Recupération ID URL
if (empty($staticId) or !array_key_exists(str_pad($staticId,3,'0',STR_PAD_LEFT), $this->plxMotor->aStats)) {
$staticId = $this->staticId();
}
$staticIdFill = str_pad($staticId,3,'0',STR_PAD_LEFT);
if(!empty($staticId) AND isset($this->plxMotor->aStats[ $staticIdFill ]))
echo $this->plxMotor->urlRewrite('?static'.$staticId.'/'.$this->plxMotor->aStats[ $staticIdFill ]['url']);
}
Cela se situe vers la ligne n°1375 du fichier core/lib/class.plx.show.php.
Autre problème vraiment pénible :le titre de colonne "identifiant" est trop long par rapport au contenu des cellules sous-jacentes. Du coup, le contenus des autres colonnes est tronqué.
Un grand merci à toutes les personnes qui ont participé à l'élaboration et à la sortie de cette version 5.5
Toutes les idées proposées, suggestions et améliorations n'ont pas été prises en compte dans cette version. Elles seront étudiées, analysées, malmenées pour la suivante Continuez à nous faire part de vos souhaits, toutes vos contributions permettent de faire vivre PluXml.
Bonne installation ou mise à jour de votre PluXml !
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Réponses
C'est un sacré LEVELUP pour le CMS Pluxml bravo à Stéphane et tous les contributeurs
@Stéphane je suis content de voir que la nouvelle gestion/présentation des thèmes fasse l’unanimité
D'après ma compréhension, arrivé au level 6 un commentaire recevra la classe level-max et son indentation sera bridée par theme.css.
Néanmoins Stéphane a précisé que virtuellement on peut continuer à indenter les réponses.
Cela sous-entend que l'on peut toujours continuer à intercaler des réponses entre des commentaires d'un niveau <= level-5, ce qui peut entraîner une mécompréhension à la lecture des messages au final (je l'ai testé de mon côté, et effectivement cela devient compliqué si on n'ajoute pas des niveaux d'indentation).
Et là pour démêler quel message répondait à qui, bon courage.
Sans ajouter d'autres niveaux d'indentation dans le CSS, je vois deux solutions :
[list=*]
[*]que passé le level-5 (par exemple), toutes les réponses soient chaînées les unes après les autres sans pouvoir s'intercaler entre deux (ce serait le plus propre et fonctionnel)[/*]
[*]qu'on fasse disparaître le bouton "répondre" soit par design dans le code, soit en le rendant invisible par CSS (défaut: les visiteurs ne comprendront peut-être pas comment répondre si le bouton est 3km au dessus)[/*]
[/list]
Qu'en pensez-vous ?
Quand le paramètre est de type numeric, on le stocke dans le plugin comme une chaine de caractères.
Et fatalement plxPlugin::getParam(..) retourne toujours une chaine de caractères même si on attend une valeur numérique type integer ou float.
Frustrant !
Autre point gênant à un niveau moindre :
le constructeur __construct stocke des valeurs dans le tableau plug.
le nom de certaines clés de ca tableau prête à confusion par parametres.xml laisse supposer qu'on pointe vers un fichier parametres.xml alors qu'en réalité on pointe vers monplugin.xml.
Une clé plus pertinente serait tout simplement parametres. De la même façon infos.xml pourrait être remplacé par infos tout simplement.
Il serait bien de rajouter un clé supplémentaire, nommée par exemple "repo" pour stocker l'url où on peut télécharger le plugin ou sa mise à jour. Sujet évoqué vers octobre dans un autre fil de discussion.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Rajouter dans .gitignore le fichier config.php situé à la racine du site.
Cela permet de faire des tests sur differents dossiers de data
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Je souhaite avoir plusieurs dossiers de données (data/ par défaut) pour tester différents sites avec la version en cours de développement de Pluxml, avec un thème différent pour chaque site. J'ai bien avancé sur un plugin qui fait le job, c'est à dire renommer le dossier datas avec déjà plein d'articles et de pages statiques et basculer entre différents dossiers de données.
D'où l'idée de lancer l'installation de Pluxml avec install.php et sans dossier data fichier config.php.
Et là c'est la catastrophe comme le montre la copie d'écran ci-dessous:
Si le dossier data/medias se crée bien, les dossiers data/articles, data/statiques, data/commentaires et plus grave data/configuration sont aux abonnés absents. Et les fichiers de config se retrouvent à la racine du site.
Pas cool !
Autre souci, j'aimerais bien pouvoir choisir le nom du dossier de données à l'installation
Du coup j'ai révisé le fichier install.php qui crée un dossier de données complet avec le nom que je veux et le fichier config.php ad'hoc
Je fais un pull request (branche install). Vu la simplicité de la modification, on pourra l'intégrer facilement dans la version en cours de dév.
Remarque l'ajout des dossiers data, plugins et du fichier config.php dans l'archive zip de Pluxml devient inutile. A spécifier aussi dans .gitignore
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Cela m'interesse doublement car j'avais travaillé sur une installation personnalisé pour:
- ne pas avoir à réinstaller à chaque fois les 5-6 plugins que j'installe toujours
- avoir un dossier médias avec ses sous-dossiers
- avoir un dossier data "vide" prêt à l'emploi ou un dossier data-testing avec des données exemples
Mais pour cela je n'étais pas parti sur un plugin, mais des modifications manuelles dans install.php et un choix à definir dans le config.php
Lorsqu'on clique sur le lien Nb de commentaires sur la page d'accueil, celui-ci nous emmène bien sur le premier commentaire de l'article.
En revanche, une fois dans l'article, lorsqu'on clique sur le lien Nb de commentaires (artNbCom()), alors qu'on devrait être dirigés en bas de page (#comments), on est dirigés sur la page d'accueil car le lien produit est : racine du site/#comments à la place de racine du site/article.html#c0005-1
Bien sûr, j'ai essayé de remplacer l'url par mais ça ne fonctionne pas.
J'ai activé la réécriture d'url. C'est peut-être la raison ?
Le plugin s'appelera moveMyDatas. Ses fonctionalités seront :
[list=*]
[*]renommer un dossier de données existant avec correction des liens dans le dossier[/*]
[*]créer un dossier de données vide avec les fichiers utiles et le nom que l'on veut[/*]
[*]sélectionner un dossier dans une liste déroulante de tous les dossiers contenant un fichier parametres.xml[/*]
[/list]
Le taf est bien avancé.
J'espère publier une version en début de semaine.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Bonjour
Bien vu. Merci, c'est corrigé !
https://github.com/pluxml/PluXml/commit/56dca702ac6e5b1a20ffec8016e842f1baf43a5e
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
je ne sais pas si c'est le bon moment du développement pour en parler mais il y a un comportement que je souhaitais vous soumettre.
Si l'on a l'interface de PluXml dans une langue L et qu'une extension ne possède pas le fichier de lange pour la langue L,
l'affichage des textes ne se fait pas du tout.
Il faudrait faire une vérification de l'existence du fichier langue et à défaut utiliser un des fichiers présents.
Peut-être inviter l'utilisateur à l'aide d'un message du style "Attention votre langue n'est pas prise en compte par cette extension, choisissez dans la liste la langue que vous souhaitez utiliser avec celle-ci"
Du coup il faudrait créer une variable "langue utilisée pour Tel extension".
Mais au moins vérifier l'existence et utiliser un fichier présent, ça fait bizarre de se retrouver avec des noms de variables partout.
Merci de votre attention !
Bon amusement
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Bonne remarque.
Il faut modifier la méthode __construct de la class plxPlugin dans le fichier core/lib/class.plx.plugins.php vers la ligne n° 289
On essaie d'abord la langue par défaut, puis l'anglais en, ensuite le français fr, puis ensuite toutes les langues présentes dans le dossier core/lang.
En cas d'échec, on reste sur la langue par défaut.
C'est une première solution.
Dans l'idéal, il faudrait un ordre de préférence dans le panneau de config avancé. Par exemple, sur les Ramblas, on préférera l'espagnol à defaut du catalan, plutôt que l'anglais.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Oublie mon post précèdent. Voici une solution plus élégante.
Préambule: Contrairement à la page 12 du manuel du développeur pour Pluxml, on suppose que la déclaration du constructeur de la classe du plugin déclare une langue par défaut comme ceci:
Il faut modifier les 2 méthodes suivantes dans le fichier core/lib/class.plx.plugins.php comme suit et dans cet ordre :
pour la class plxPlugin vers la ligne n°289 pour la class plxPlugins vers la ligne n°33 Le classement des langues dans $prefered_lang est un peu arbitraire. J'ai tenté de faire au mieux selon les sensibilités linguistiques de chaque région
(en en tête, nl après fr pour la Belgique, pt après es pour l'Espagne, ...).
Je suis surpris de ne pas voir le catalan, langue couramment pratiquée au bord de la Méditerrannée de part et d'autre des Pyrénées
Pour finir 2 recommandations
penser à déclarer une langue par défaut dans le __construct du plugin
Corriger la page 12 du manuel du développeur
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Occitan : Soi de Tolosa e m'agrada Pluxml ! Mercé/Gràcia de (la) vòstra contribucion al projècte !
Catalan : Sòc de Tolosa i m'agrada Pluxml ! Gràcia/Mercè de la vostre contribució al projecte !
Merci pour ta contribution bazooka07 ! J'espère que ça sera pris en compte
Je trouve assez frustant d'avoir comme réponse allow_url_fopent est désactivé lorsqu'on vérifie la dernière version en ligne de Pluxml dans le script core/admin/parametres_infos.php du back-office.
Pourtant, l'usage de curl dans PHP permet de contourner aisément cette limitation.
Et en cas de succès, il serait plus élégant de nous confirmer la version en ligne plutôt que de nous rappeler la version actuellement utilisée et qui est déjà indiquée dans la sidebar.
Voici comment modifier la méthode checkMaj dans core/lib/plx.class.admin.php et le fichier core/lang/fr.php:
Voir le pull-request check_Maj sur github
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Sur la sidebar de l'édition d'un article, dans le fichier core/admin/article.php "catégories" s'appellent "emplacement". Et en dessous d'emplacement, on reparle de catégorie. Pas très homogène.
Autre petit bug
Dans core/admin/index.php on utilise la constante L_CATEGORY_HOME.
Dans core/admin/article.php on utilise la constante L_CATEGORY_HOME_PAGE.
Tout cela pour afficher "Page d'accueil". Si on pouvait unifier, cela faciliterait le travail des traducteurs.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
par exemple :
1 - insertion via CKEditor:
" <p><img alt="" src="data/medias/0016/fond-ecran-texte-1000.jpg" style="width: 1000px; height: 643px;" /></p> "
2 - insertion via ' image d'accorche":
<img class="art_thumbnail" src="http://localhost/PluXml55-master/data/medias/0016/fond-ecran-texte-1000.jpg" alt="image d'accroche alt" title="image d'accroche" />
mes sites principaux : fonds d'écran gratuits - longue traîne - référencer votre site - brocante en ligne -
<img src="<?php $plxShow->artThumbnail('#img_url'); ?>" width="1000" height="643" alt="<?php $plxShow->artThumbnail('#img_alt'); ?>" />
qui peut sembler un peu long mais c'est simplement un copier-coller. Mais la plupart du temps, je saute l'étape de la largeur et hauteur pour l'inclure dans mes paramètres de rognage de cImage, quelque chose comme
<img src="img.php?src=<?php $plxShow->artThumbnail('#img_url'); ?>&w=1000&h=643&crop-to-fit" />
ce qui permet d'utiliser la même image à plusieurs endroits.
En passant, je suis surpris de voir dans l'exemple une insertion "en ligne" de CSS dans une balise IMG plutôt que de paramétrer les dimensions directement, je me questionne sur l'avantage s'il y en a un.
<img src="data/medias/0016/fond-ecran-texte-1000.jpg" style="width: 1000px; height: 643px;" />
vs
<img src="data/medias/0016/fond-ecran-texte-1000.jpg" width="1000px" height="643px" />
Je viens également de remarquer autre chose :
les images de ce genre ' images d'accroche ' ne sont pas reprises dans le flux rss des articles ... ??? normal ou bug, car dommage
mes sites principaux : fonds d'écran gratuits - longue traîne - référencer votre site - brocante en ligne -
L'admin, c'est bon pour le contenu des articles, pour les créer, leur assigner des accroches et des catégories, etc. Mais pour monter le format d'une page (utiliser une image d'accroche) c'est très suggéré d'utiliser un éditeur. Même si toutes les pages sont accessibles par l'admin, c'est assez pénible de travailler dans la fenêtre monochrome qui foue en l'air les indentations pour ne plus rien y comprendre. Un éditeur est un bon outil pour apprendre aussi.
Habité à la philosophie Debian "Ca sort quand c'est prêt", je ne peux me résoudre à utiliser un pluxml avec un code imparfait malgré plusieurs pull-requests sans réponse.
J'ose encore faire quelque remarque :
La méthode PlxShow::staticUrl(($type='relatif') déclare le paramètre $type et ne l'utilise pas.
Cela ne dérange personne, sauf que j'ai besoin de connaitre l'url d'une page statique à partir de son identifiant relevé dans le panneau de configuration des pages statiques.
Pour ceux qui ne peuvent se résoudre d'attendre la version d'après 5.5, voici comment faire : Cela se situe vers la ligne n°1375 du fichier core/lib/class.plx.show.php.
Autre problème vraiment pénible :le titre de colonne "identifiant" est trop long par rapport au contenu des cellules sous-jacentes. Du coup, le contenus des autres colonnes est tronqué.
A++
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Un grand merci à toutes les personnes qui ont participé à l'élaboration et à la sortie de cette version 5.5
Toutes les idées proposées, suggestions et améliorations n'ont pas été prises en compte dans cette version. Elles seront étudiées, analysées, malmenées pour la suivante Continuez à nous faire part de vos souhaits, toutes vos contributions permettent de faire vivre PluXml.
Bonne installation ou mise à jour de votre PluXml !
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
EDIT: C'était une vraie news. Félicitation pour le travail du coup.
Pour la mise à jour depuis la beta, il faut faire comment alors, du coup ?