[nouvelle fonctionnalité] fondre plxMySearch dans la version de base
Pierre
Member
Vous me voyez venir, un copié collé de la requête à propos de la requête en faveur du plxMyContact fait il y a quelques minutes.
Pour un peu les mêmes raisons, un site qui se respecte de nos jours a presque toujours un moyen ou un autre d'effectuer une recherche plein texte dans ses cartons.
Le plugin construit par notre maestro fait un excellent travail, j'ose toutefois demander de séparer complètement le formulaire de requête pour permettre d'en avoir plus d'un. L'exemple classique est une gigantesque fonction de recherche à la Goo... (j'ai failli) avec une pleine page de résultats et un gros champ d'entrée du "prochain essai" en haut de page. Mais ailleurs, un petit champ discret avec une loupe est disponible, souvent en entête, en sidebar ou parfois en bas de page.
Mais tout ça est sujet à discussion, j'y allait simplement par statistiques. J'installe presque toujours ce plugin à l'arrivée, c'est le meilleur symptôme qu'un plugin devrait traverser du bon côté de la Force...
Pour un peu les mêmes raisons, un site qui se respecte de nos jours a presque toujours un moyen ou un autre d'effectuer une recherche plein texte dans ses cartons.
Le plugin construit par notre maestro fait un excellent travail, j'ose toutefois demander de séparer complètement le formulaire de requête pour permettre d'en avoir plus d'un. L'exemple classique est une gigantesque fonction de recherche à la Goo... (j'ai failli) avec une pleine page de résultats et un gros champ d'entrée du "prochain essai" en haut de page. Mais ailleurs, un petit champ discret avec une loupe est disponible, souvent en entête, en sidebar ou parfois en bas de page.
Mais tout ça est sujet à discussion, j'y allait simplement par statistiques. J'installe presque toujours ce plugin à l'arrivée, c'est le meilleur symptôme qu'un plugin devrait traverser du bon côté de la Force...
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Je plussoie Pierre dans sa proposition (... même si je n'ai pas tout compris de la partie non copiée du quod erat demonstrandum)
C'est une demande récurrente depuis au moins la version 4 de PluXml... ça finira bien par aboutir.
Bref, je plussoie les deux demandes.
à plus,
Gzyg
Personnellement, j'ai maintenant beaucoup de facilité à manipuler les fonctions de ces plugins mais quelqu'un qui télécharge un de mes thèmes se voit obligé de télécharger ces deux plugins et de les configurer. Jai beau parfois fournir les fichier déjà prêts à installer, les nouveaux ne sont pas à l'aise.
Bon. En soi, ça ne m'a posé aucun problème car je maîtrise le code mais pour les newbies j'imagine que ça doit être coton et peut-être que ça peut les repousser à utiliser ce merveilleux PluXml.
Donc je plussoie aussi.
Nous adorons presque tous patauger dans le code, c'est notre hobby ou notre métier. Nous applaudissons aussi les nouveaux qui se lancent et font leurs premiers essais avec ce produit qui leur permet cette "introduction à la programmation" sans trop les intimider. Mais pour plusieurs, ils préfèrent se limiter aux formulaires de l'admin et l'idée d'ouvrir un fichier pour faire une modification les bloque. Pour moi, c'est une question de marketing, pour rendre le produit invitant pour tout le monde et les empêcher d'aller chez Wix.
Par contre, l'activation de la réécriture qui est déjà là fait un excellent travail pour l'esthétique et la clarté d'un URL donné en référence en plein texte. J'arrête ici, j'ai déjà du sable dans mes souliers...
Après quelques semaines, j'en suis à une bonne douzaines de thèmes convertis sous la version 5.5 et mes problèmes sont maintenant presque exclusivement causés par nos deux larrons plxMySearch et plxMyContact qui ne peuvent pas être inclus au thème parce qu'ils chambardent du code ailleurs dans leur propre répertoire de plugin. C'est pas que c'est compliqué à convertir quand on s'habitue aux bouts de code à insérer mais on ne peut toujours pas offrir un thème clé en main à cause de ça.
Le troisième cas (du logo générique) est plus facile à faire avaler à un nouveau qui installe son site, sa modification peut ensuite demeurer dans son répertoire de thème mais les deux cas mentionnés ici à nouveau sont un véritable frein à l'avancement de PluXml, ça devient très évident quand on fait plusieurs thèmes de suite.
Je sais qu'il est trop tard pour implorer Stéphane de les inclure dans la version 5.5 mais, de grâce, il faut considérer les monter dans la version de base au plus vite. Ma prochaine victime sera le fil d'Ariane, aussi bien en parler tout de suite...
HS: En parlant de thème, est-ce qu'il serait envisageable de remonter un site de démo avec un sélecteur de thème, histoire de tester avant de télécharger ?
Chaque chose en son temps, quand la version 5.5 sera officielle et bien nettoyée de tous ses petits bugs de plus en plus petits, ce ne sera qu'ue question de quelques jours avant de voir arriver des thèmes qui en tirent avantage. Je dépasse maintenant la trentaine de thèmes fonctionnant sous cette version alors pas de soucis sur la sélection sur nos étalages. Si vous roulez sous 5.5, si tous vos articles ont une image accrochée, tout est prêt, tenez bon.
Pour les impatients, visitez les sites de thèmes gratuits comme designscrazed.org ou html5xcss3.com pour faire votre choix, pointez du doigt votre préféré et je vous opère la conversion en quelques jours. Mon horaire varie beaucoup, c'est pourquoi je parle de jours, ça prend en fait seulement quelques heures.
Par contre je pensais éventuellement à un autre site de demo accessible depuis la page de chaque thème.
Il existe un plugin sélecteur de thème qui permet ensuite de switcher via un menu déroulant.
Ce sera beaucoup plus pratique à tester pour quelqu'un qui hésite à passer sur pluxml.
Tu conviendra sans doute que d'installer pluxml et de télécharger les thèmes un à un pour les tester à un petit côté rébarbatif.
Les démonstrations des vertus de PluXml sont faites par le site par défaut. Le nouvel arrivant se retrouve dans un environnement sobre et clair, il peut voir les fonctions de base dans leur plus simple élément et, souhaitons-le, être séduit par leur simplicité d'exécution. Le marketing et le développement de marché est donc la responsabilité du site racine qui fait ce qu'il a à faire. Il y a toujours place à l'amélioration, c'est sans doute dans la liste des choses à faire.
Les nouveaux qui visitent peuvent passer par la rubrique Ressources, jeter un coup d'oeil aux thèmes et voir que leur page d'accueil peut avoir un look bien différent de la version par défaut, c'est bien assez pour un nouveau qui n'a pas encore daigné installer PluXml sur son propre serveur, s'il sait comme s'y prendre. On n'achète pas un CMS pour ses thèmes, on l'achète parce qu'on aime ce qu'il fait et qu'on s'imagine assez bien s'en servir.
Pour un impatient qui veut voir un thème en action, je donne le lien vers le forum qui pointe sur la discussion dudit thème, le premier post contient toujours un lien valide vers la démo de son designer. Si notre impatient veut savoir de quoi aura l'air son site, ça ne lui aura demandé que 2 clics de plus.
Le sélecteur de thèmes, c'est bien beau, mais il doit rouler sur un serveur, sur une installation complète de PluXml à jour, 15 à 20 articles avec leurs images, des catégories et autant de thèmes que tu voudras. Moi, je ne veux pas installer un autre site ailleurs comme la douzaine (au moins) qui existent déjà pour diluer encore plus le trafic de PluXml, je veux que les visiteurs viennent ici et y restent le plus longtemps possible.
Les nouveaux venus veulent souvent sauter les étapes mais doivent vivre le passage obligé de l'installation de base dans l'environnement par défaut. S'ils passent tout de suite à un thème élaboré, ils risquent plus de frustration qu'autre chose. Ça nous fait plaisir d'assister un peu pour intégrer les fonctions complexes mais leur éducation est leur responsabilité. Il leur en faut un peu, on est pas chez Wix.
je reste toujours convaincu que plxMySearch et plxMyContact (et la plupart des autres extensions) n'ont pas leur place dans le cœur donc peut-être qu'en essayant d'améliorer le point qui te pose problème, on arrivera à simplifier la vie aux débutants qui veulent installer ces extensions.
une autre idée que j'ai déjà vu dans des thèmes WordPress (ce qui ne veut pas dire que c'est obligatoirement une bonne idée) est de faire des tests "si cette extension est installée, alors fait quelque chose de différent".
Le thème devrait se limiter à l'affichage et non pas se soucier des extensions installées mais ce genre de tests pourrait augmenter le nombre de personnes intéressée par tes thèmes dans un premier temps.
Pourquoi ne voyons-nous pas ces difficultés avec les fonctions de listes comme catList, artCat, artTags ou la grande championne lastArtList? Parce que tout ce qui est gestion des variables se fait dans le core et que la partie formatage visuel est dans la variable $format, bien installée dans une page dans le répertoire du thème. Ce ne sont pas des extensions, on a réalisé leur importance et on a prévu que la sortie va dépendre du designer.
Je répète que des fonctions du genre plxMySearchForm($format='') et plxMySeachResults($format='') ne casseraient absolument rien déjà installé et les gens qui n'y voient aucun intérêt n'auront qu'à ne pas les inclure.
Les plugins c'est très pratique pour les choses exceptionnelles, qui répondent à un besoin précis que pas tout le monde rencontre. Un champ de recherche, une page contact, ce sont des choses très communes, presque tous les sites en ont. Leur fonctionnement est assez standard, leur look dramatiquement différent d'un site à l'autre.
et donc chaque thème peut présenter le formulaire différemment.
1- installer le plugin
2- modifier le formulaire dans plxMySearch.php
3- modifier la page de résultats dans form.search.php
Ce n'est pas les feuilles de CSS qu'on change, ce sont les DIV qui les utilisent: le champ qui reçoit le mot-clé, le bouton que l'on presse pour lancer la recherche, la présentation graphique des résultats de recherche, etc. Tout ça est tiré d'un design propre qui utilise des fichiers CSS du thème, et des DIV tirées du code original du thème.
Les feuilles de CSS de PluXml et du plugin ne sont jamais utilisées dans aucun de mes thèmes, souvent je les efface puisqu'elles ne seront jamais appelées de toutes façons. Le designer du thème a créé un look, un comportement, chacun des designs a sa philosophie, sa présentation, ça va bien au-delà de la feuille de style.
Les pages contact vivent exactement la même situation. On installe un plugin, on écrit dans son répertoire des choses propres au thème. Si on change de thème, on recommence le rendu visuel pour les idées géniales de ce nouveau design. Si on retourne au premier, plus rien n'est à la bonne place ou même fonctionne.
Partons de quelque chose qui fonctionne, la section commentaires. Le design des conversations et du formulaire de rédaction d'un commentaire sont à la merci du design eux aussi. Mais, quel bonheur, le fichier commentaires.php fait partie du thème. Tien donc, on peut en faire un différent pour chacun des thèmes (j'en ai près de 50) et passer d'un à l'autre sans rien toucher du voisin.
D'accord à 200% avec mathieu
Et nombreux problèmes viennent souvent parce que les règles css sont mal écrites ou le thème mal structuré par les concepteurs.
Je vois des fois des personnes demander de rajouter des classes ou des ids pour gérer le comportement de certaines balises html, alors qu'il n'y en absolument pas besoin. Faut juste comprendre et savoir comment accéder aux éléments html par hiérarchie.
Vu le nombre de thème, il est impossible d'avoir des comportements des plugins compatibles à 100% au niveau de l'affichage. Il y aura toujours des réglages à faire. Ce n'est pas parce qu'on ne sait pas faire, que sait infaisable et/ou qu'il faut tout revoir. En gros vous créez des problèmes là où il ne devrait pas en avor
Et pour les plugins il y a les menus Code CSS au niveau de l'écran de gestion des plugins pour gérer leur css sans intervenir dans le thème.
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Reprenez l'exemple des commentaires, la mécanique est dans le core, la page est dans le thème. Les variantes de présentation sont innombrables mais cette différence se trouve isolée dans le répertoire du thème. Je peux te faire 300 thèmes, ils vont tous être 100% compatibles avec la mécanique de commentaires, la conversation, le formulaire, etc.
Pour te prouver que la méthode que je suggère fonctionnerait, je prévois modifier et inclure les fichiers plxMySearch.php et form.search.php dans mes futurs thèmes. Les seuls endroits que je touche sont la partie du formulaire et celle de la page de résultats. Je ne fais qu'appliquer les classes du CSS exotique pour présenter le formulaire de recherche et les résultats comme les a imaginés visuellement leur créateur. Tout le code de traitement reste intacte. Alors, si mon plaidoyer n'est pas entendu, je vais encore inscrire dans ma description qu'il faut installer un plugin et recopier deux fichiers dans le répertoire dudit plugin. Le résultat sera que les étourdis ou les imprudents vont détruire le formulaire par défaut et devront réinstaller le plugin s'ils reviennent à un autre thème. C'est un moindre mal pour moi parce que mes thèmes exigent un niveau de connaissance moyen, mais la destruction des fichiers du plugin à chaque changement de thème, ça fait pas très professionnel.