Qu'il soit plus SEO Friendly:
- Possibilité d'avoir des balises title différentes du nom du lien du menu pour les pages statiques
- Gestion sitemap des médias
Plus Ergonomique:
- Possibilté de gerer un média (ou un fichier) depuis la page de l'article et le rattacher facilement à cet article
- Pouvoir récupérer facilement (sans trop de compétences) l'affichage des miniatures des articles.
Que le plugin de contact soit de base sur PluXml avec la possibilité de rajouter des champs.
Que le wysiwyg soit également de base (gestion html possible depuis le wysiwyg).
Ce que j'aimerais c'est que l'on puisse imbriquer les commentaires (avec des liens pour répondre). Je l'ai fait par l'intermédiaire d'un plugin mais ça serait bien d'avoir cette possibilité en natif.
Également, comme le disait jofdesign, pouvoir avoir une arborescence dans le menu principal sans passer par un plugin.
J'oubliais aussi dans la page d'édition des thèmes (panneau admin) pouvoir éditer les pages situées dans des sous-dossiers (style /css, /js ou autre).
J'ai découvert pluXml il y a un maintenant presque 2 ans grâce à Alsacréations.
J'ai toujours considéré pluXml comme une alternative intéressante pour certains de mes futurs projets, grâce notamment à la sa légèreté. Je ne l'ai pas encore utilisé jusqu'à maintenant, mais je l'ai testé en local.
À mon sens, 3 choses devraient être envisagées en tant que fonctionnalités natives :
- permettre l'arborescence des catégories et des pages (pages>souspages>soussouspages, etc.)
Car par expérience, qu'il s'agisse d'un blog ou d'un CMS, un seul niveau d'arborescence est trop souvent insuffisant.
- permettre le rewriting dans l'admin (Cf. le module permalink de Wordpress).
- permettre de dissocier images/documents du contenu et images/documents joints à l'article/page. (Cf. Il s'agirait donc d'ajouter un module «fichiers joints» en plus des champs traditionnels des articles et pages)
Voilà, je trouve pluXml très intéressant (encore Bravo !) et j'ai songé de nombreuses fois l'utiliser pour des projets. Mais à 3-4 reprises, les éléments cités ci-dessus ne m'ont pas permis de le faire.
- permettre de dissocier images/documents du contenu et images/documents joints à l'article/page. (Cf. Il s'agirait donc d'ajouter un module «fichiers joints» en plus des champs traditionnels des articles et pages)
- permettre l'arborescence des catégories et des pages (pages>souspages>soussouspages, etc.)
Car par expérience, qu'il s'agisse d'un blog ou d'un CMS, un seul niveau d'arborescence est trop souvent insuffisant.
PluXml ne gerera les sous catégories. c'est fonctionnellement et techniquement trop rigide pour une bonne gestion documentaire. Les tags ont été "inventés" pour pallier à ce probleme de hiérarchisation, car ils permettant de classer et accéder à l'information suivant plus axes d'analyses en même temps (mots clés) et de façon plus rapide.
- permettre le rewriting dans l'admin (Cf. le module permalink de Wordpress).
Le rewriting dans l'admin est à mon sens inutile. si c'est juste pour avoir des belles urls...
Il est sensé servir (surtout) au référencement, donc coté visiteurs.
- permettre de dissocier images/documents du contenu et images/documents joints à l'article/page. (Cf. Il s'agirait donc d'ajouter un module «fichiers joints» en plus des champs traditionnels des articles et pages)
Le plugin de DanielSan "champArt" permet de faire ça.
Cela ne sera pas gérer en natif. Cela ne fait pas partie des objectifs de PluXml.
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Stéphane, je reviens sur la question de l'arborescence, car il semble que tu m'as répondu pour les catégories mais pas pour les pages. Peux-tu me préciser si la gestion des pages > souspages > soussouspages est envisageable en natif ? Si ce n'est pas le cas, j'aimerai savoir ce qui motive ce choix par rapport au projet pluXml.
Sinon, concernant le rewriting, je crois que je me suis mal expliqué. ;-)
Je ne parlais pas d'url réécrite pour l'admin, mais bien pour le front visiteur.
Je demandais en fait s'il était possible d'avoir un module de paramétrage des urls réécrites similaire à celui de wordpress. C'est-à-dire que dans l'admin, un module permettrait de choisir la forme des urls et notamment de remplacer les termes utilisés par défaut dans les urls (les identifiants de catégories, de pages).
Idem pour les pages. Il n'y aura pas d'arborescence. Cela ne fait pas partie des objectifs de PluXml qui au départ est fait pour le blogging. Il n'est pas orienté full CMS et ne se destine pas à ça.
Sinon pour la réécriture d'url il y a le plugin plxPermalinks (voir rubrique plugin du forum) qui permet de faire ça (avec ses limitations).
Et j'en profite pour te souhaiter la bienvenue sur pluxml
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Je te remercie et je comprends tout à fait vos choix concernant de fait de ne pas implémenter trop de fonctionnalités. Les principales qualités de pluXml repose justement sur ces choix.
À bientôt !
Il est possible d'avoir un système de sous-pages avec un bout de code PHP disponible quelque part sur le forum (je ne sais plus de qui et où) et les groupes de pages statiques. Il pourrait être intéressant d'en faire un plugin à part entière.
Concernant l'arborescence, je vous propose une modification de la méthode catList de la classe $plxShow, via le hook plxShowLastCatList.
/**
* Méthode qui affiche la liste des catégories actives, avec la liste des articles associés.
* Si la variable $extra est renseignée, un lien vers la
* page d'accueil (nommé $extra) sera mis en place en première
* position.
*
* @param $extra string nom du lien vers la page d'accueil
* @param $format string format du texte pour chaque catégorie (variable : #cat_id, #cat_status, #cat_url, #cat_name, #art_nb)
* ou
* $format array(
* $format[0] string format du texte pour chaque catégorie (variable : #cat_id, #cat_status, #cat_url, #cat_name, #cat_img, #art_nb)
* $format[1] integer nombre d'articles maximum à afficher dans les sous-menu
* $format[2] array('src'=> 'val', 'dim'=>'val') tableau contenant l'url et les dimensions d'une image de remplacement de
* l'intitulé de l'index
* )
* @param include string liste des catégories à afficher séparées par le caractère | (exemple: 001|003)
* @param exclude string liste des catégories à ne pas afficher séparées par le caractère | (exemple: 002|003)
* @return stdout
* @scope global
* @author Anthony GUÉRIN, Florent MONTHEL, Stephane F, Cyril MAGUIRE
*/
public function plxShowLastCatList(){
$string =<<<END
if (is_array(\$format)) {
\$f = \$format[0];
\$nbSousMenu = intval(\$format[1]);
if (isset(\$format[2]) && is_array(\$format[2])) {
if (isset(\$format[2]['src'])) {
\$src = \$format[2]['src'];
}
if (isset(\$format[2]['dim'])) {
\$dim = \$format[2]['dim'];
} else {
\$dim = '32';
}
}
\$format = \$f;
unset(\$f);
} else {
\$nbSousMenu = 0;
}
# Si on a la variable extra, on affiche un lien vers la page d'accueil (avec \$extra comme nom)
if(\$extra != '') {
\$name = str_replace('#cat_id','cat-home',\$format);
\$name = str_replace('#cat_url',\$this->plxMotor->urlRewrite(),\$name);
\$name = str_replace('#cat_name',plxUtils::strCheck(\$extra),\$name);
if (isset(\$src)) {
\$name = str_replace('#cat_img','<img src="'.\$src.'" width="'.\$dim.'" height="'.\$dim.'" title="'.plxUtils::strCheck(\$extra).'" alt="'.plxUtils::strCheck(\$extra).'" />',\$name);
}
\$name = str_replace('#cat_status',((\$this->catId()=='home' && \$this->mode() == 'home')?'active':'noactive'), \$name);
\$name = str_replace('#art_nb','',\$name);
echo \$name."\n\t\t\t";
}
if(\$this->plxMotor->aCats) {
\$format = str_replace('#cat_img', '#cat_name', \$format);
foreach(\$this->plxMotor->aCats as \$k=>\$v) {
\$in = (empty(\$include) OR preg_match('/('.\$include.')/', \$k));
\$ex = (!empty(\$exclude) AND preg_match('/('.\$exclude.')/', \$k));
if(\$in AND !\$ex) {
if((\$v['articles']>0 OR \$this->plxMotor->aConf['display_empty_cat']) AND (\$v['menu']=='oui') AND \$v['active']) { # On a des articles
\$k = intval(\$k);
if (\$nbSousMenu != 0) :
ob_start();
\$this->lastArtList('<li class="#art_status"><a href="#art_url"><span>#art_title</span></a></li>',\$nbSousMenu,\$k);
\$sousmenu = ob_get_clean();
if (strlen(\$sousmenu) != 0):
\$sousmenu = '
<ul>
'.str_replace('</li><li', '</li>'."\n\t\t\t\t\t".'<li', \$sousmenu).'
</ul>
</li>';
endif;
else :
\$sousmenu = '</li>';
endif;
# On modifie nos motifs
\$name = str_replace('#cat_id','menu_cat-'.\$k,\$format);
\$name = str_replace('#cat_url',\$this->plxMotor->urlRewrite('?categorie'.\$k.'/'.\$v['url']),\$name);
\$name = str_replace('#cat_name',plxUtils::strCheck(\$v['name']),\$name);
if (\$this->mode() == 'article' && in_array(\$k,explode(',',\$this->plxMotor->plxRecord_arts->f('categorie')))) {
\$name = str_replace('#cat_status','active', \$name);
}else {
\$name = str_replace('#cat_status',(\$this->catId()==\$k?'active':'noactive'), \$name);
}
\$name = str_replace('#art_nb',\$v['articles'],\$name);
\$name = str_replace('</li>',\$sousmenu,\$name);
echo \$name;
}
}
}
}
return true;
END;
echo '<?php '.$string.'?>';
}
L'appel de la méthode est le même sauf que les paramètres sont un peu différents. On peut toujours l'appeler comme la manière par défaut mais on peut aussi le faire ainsi :
Idem pour les pages. Il n'y aura pas d'arborescence. Cela ne fait pas partie des objectifs de PluXml qui au départ est fait pour le blogging. Il n'est pas orienté full CMS et ne se destine pas à ça.
L'arborescence n'est pas uniquement limitée au CMS. Elle peut également être utilisée dans un blog.
La proposition ci-dessus te semble-t-elle vraiment trop lourde ? Peux-tu me dire quels défauts tu y vois ?
On est pas en train de tout mélanger là...
il y a:
- pages statiques + sous pages (arborescence donc dépendance dans les pages)
- catégories + sous catégories (arborescence donc dépendance dans les catégories)
Jerry ce que tu proposes dans plxShowLastCatList est un autre sujet non ?
Dans la description ça dit "affiche la liste des catégories actives, avec la liste des articles associés"
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
On n'a pas forcément besoin d'une arborescence des pages statiques à l'intérieur de PluXml.
Le problème se pose surtout pour un menu déroulant par exemple, et ça un plugin de menu pourrait très bien le faire.
J'ai ça en tête (mais il y a pas mal de XML à parser, plus quelques autres amusements...) avec la structure suivante dans la config du plugin :
Pour chaque menu, un numéro ou nom
suivi d'autant de lignes qu'il y a de liens dans le menu, avec pour chaque ligne :
- Titre du lien (qui apparaîtra dans le menu)
- Type : article ou statique (liste déroulante)
- Id et titre de l'article ou de la page statique (dans une liste déroulante, affichage des id et des titres associés)
- N° d'ordre dans le menu, ou flèches Monter/Descendre, ou les deux
- Menu parent ("---" pour "Haut", ou titre d'un menu), pour les listes déroulantes
Dans le thème, il suffirait d'appeler ce plugin, avec le nom du menu ou son identifiant. Les sous-menus se créeraient automatiquement, en fonction de l'arborescence choisie.
Bon, voilà... il ne reste "plus qu'à le faire", facile à dire...!
Autre chose :
Pour les groupes des pages statiques, ce serait bien d'avoir une liste déroulante, pour éviter les erreurs de saisie de la part des utilisateurs, et aussi la possibilité de filtrer par groupe, comme par catégorie pour les articles.
Mais cela suppose un menu de gestion de ces groupes, dans un menu à part ou dans une fenêtre popup. Bon, là encore, facile à dire...!
Je pense que PluXML doit rester simple et sobre. Il constitue un socle qui satisfait à bien des besoins et des espérances professionnelles en restant portable, compréhensible, accessible, élégant : merci à ses auteurs et contributeurs.
Certaines fonctions souhaitées me semblent dépasser les contours de cette philosophie en souhaitant du Joomla sans le dire, autrement dit, de l'usine à gaz sans base données... Car PluXML pourra toujours s'étendre par différents plugins de publication de formats de fichiers externes. Ce que je souhaiterais :
1/ Un lecteur de flux RSS (avec MagpieRSS en page statique, ça marche, mais bon, c'est brutal)
2/ Un parseur de fichiers vcard (carnet d'adresses)
3/ un parseur de fichiers ics (agenda)
4/ un parseur de fichiers csv (tableaux divers)
5/ ...
L'idée étant d'ouvrir PluXML aux données formatées tout en restant dans l'esprit flat file, sans base de données.
Ce que j'imagine est plus général, c'est un plugin de menu qui permet pour chaque lien de choisir une page précise, pouvant être un article ou une page statique.
Mais je suis sur autre chose pour l'instant, c'est une idée en attente dans ma liste.
Réponses
Pareil!
Également, comme le disait jofdesign, pouvoir avoir une arborescence dans le menu principal sans passer par un plugin.
J'oubliais aussi dans la page d'édition des thèmes (panneau admin) pouvoir éditer les pages situées dans des sous-dossiers (style /css, /js ou autre).
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
J'ai découvert pluXml il y a un maintenant presque 2 ans grâce à Alsacréations.
J'ai toujours considéré pluXml comme une alternative intéressante pour certains de mes futurs projets, grâce notamment à la sa légèreté. Je ne l'ai pas encore utilisé jusqu'à maintenant, mais je l'ai testé en local.
À mon sens, 3 choses devraient être envisagées en tant que fonctionnalités natives :
- permettre l'arborescence des catégories et des pages (pages>souspages>soussouspages, etc.)
Car par expérience, qu'il s'agisse d'un blog ou d'un CMS, un seul niveau d'arborescence est trop souvent insuffisant.
- permettre le rewriting dans l'admin (Cf. le module permalink de Wordpress).
- permettre de dissocier images/documents du contenu et images/documents joints à l'article/page. (Cf. Il s'agirait donc d'ajouter un module «fichiers joints» en plus des champs traditionnels des articles et pages)
Voilà, je trouve pluXml très intéressant (encore Bravo !) et j'ai songé de nombreuses fois l'utiliser pour des projets. Mais à 3-4 reprises, les éléments cités ci-dessus ne m'ont pas permis de le faire.
Merci
cf le plugin ChampArt
PluXml ne gerera les sous catégories. c'est fonctionnellement et techniquement trop rigide pour une bonne gestion documentaire. Les tags ont été "inventés" pour pallier à ce probleme de hiérarchisation, car ils permettant de classer et accéder à l'information suivant plus axes d'analyses en même temps (mots clés) et de façon plus rapide.
Le rewriting dans l'admin est à mon sens inutile. si c'est juste pour avoir des belles urls...
Il est sensé servir (surtout) au référencement, donc coté visiteurs.
Le plugin de DanielSan "champArt" permet de faire ça.
Cela ne sera pas gérer en natif. Cela ne fait pas partie des objectifs de PluXml.
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Daniel, je vais jeter un oeil au plugin.
Stéphane, je reviens sur la question de l'arborescence, car il semble que tu m'as répondu pour les catégories mais pas pour les pages. Peux-tu me préciser si la gestion des pages > souspages > soussouspages est envisageable en natif ? Si ce n'est pas le cas, j'aimerai savoir ce qui motive ce choix par rapport au projet pluXml.
Sinon, concernant le rewriting, je crois que je me suis mal expliqué. ;-)
Je ne parlais pas d'url réécrite pour l'admin, mais bien pour le front visiteur.
Je demandais en fait s'il était possible d'avoir un module de paramétrage des urls réécrites similaire à celui de wordpress. C'est-à-dire que dans l'admin, un module permettrait de choisir la forme des urls et notamment de remplacer les termes utilisés par défaut dans les urls (les identifiants de catégories, de pages).
Voilà, merci.
Sinon pour la réécriture d'url il y a le plugin plxPermalinks (voir rubrique plugin du forum) qui permet de faire ça (avec ses limitations).
Et j'en profite pour te souhaiter la bienvenue sur pluxml
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
À bientôt !
L'appel de la méthode est le même sauf que les paramètres sont un peu différents. On peut toujours l'appeler comme la manière par défaut mais on peut aussi le faire ainsi :
La proposition ci-dessus te semble-t-elle vraiment trop lourde ? Peux-tu me dire quels défauts tu y vois ?
Bien sur, mais ce n'est pas le choix de PluXml
Je n'ai pas encore regardé en détail. il faut que j'épluche le code et que je teste
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
il y a:
- pages statiques + sous pages (arborescence donc dépendance dans les pages)
- catégories + sous catégories (arborescence donc dépendance dans les catégories)
Jerry ce que tu proposes dans plxShowLastCatList est un autre sujet non ?
Dans la description ça dit "affiche la liste des catégories actives, avec la liste des articles associés"
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Le problème se pose surtout pour un menu déroulant par exemple, et ça un plugin de menu pourrait très bien le faire.
J'ai ça en tête (mais il y a pas mal de XML à parser, plus quelques autres amusements...) avec la structure suivante dans la config du plugin :
Pour chaque menu, un numéro ou nom
suivi d'autant de lignes qu'il y a de liens dans le menu, avec pour chaque ligne :
- Titre du lien (qui apparaîtra dans le menu)
- Type : article ou statique (liste déroulante)
- Id et titre de l'article ou de la page statique (dans une liste déroulante, affichage des id et des titres associés)
- N° d'ordre dans le menu, ou flèches Monter/Descendre, ou les deux
- Menu parent ("---" pour "Haut", ou titre d'un menu), pour les listes déroulantes
Dans le thème, il suffirait d'appeler ce plugin, avec le nom du menu ou son identifiant. Les sous-menus se créeraient automatiquement, en fonction de l'arborescence choisie.
Bon, voilà... il ne reste "plus qu'à le faire", facile à dire...!
Autre chose :
Pour les groupes des pages statiques, ce serait bien d'avoir une liste déroulante, pour éviter les erreurs de saisie de la part des utilisateurs, et aussi la possibilité de filtrer par groupe, comme par catégorie pour les articles.
Mais cela suppose un menu de gestion de ces groupes, dans un menu à part ou dans une fenêtre popup. Bon, là encore, facile à dire...!
Je pense que PluXML doit rester simple et sobre. Il constitue un socle qui satisfait à bien des besoins et des espérances professionnelles en restant portable, compréhensible, accessible, élégant : merci à ses auteurs et contributeurs.
Certaines fonctions souhaitées me semblent dépasser les contours de cette philosophie en souhaitant du Joomla sans le dire, autrement dit, de l'usine à gaz sans base données... Car PluXML pourra toujours s'étendre par différents plugins de publication de formats de fichiers externes. Ce que je souhaiterais :
1/ Un lecteur de flux RSS (avec MagpieRSS en page statique, ça marche, mais bon, c'est brutal)
2/ Un parseur de fichiers vcard (carnet d'adresses)
3/ un parseur de fichiers ics (agenda)
4/ un parseur de fichiers csv (tableaux divers)
5/ ...
L'idée étant d'ouvrir PluXML aux données formatées tout en restant dans l'esprit flat file, sans base de données.
Bien à vous.
@brica: ça ressemble plus à des plugins qu'à des intégrations en natives ...
Ce que j'imagine est plus général, c'est un plugin de menu qui permet pour chaque lien de choisir une page précise, pouvant être un article ou une page statique.
Mais je suis sur autre chose pour l'instant, c'est une idée en attente dans ma liste.