[nouvelle fonctionnalité] fondre plxMySearch dans la version de base

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

Réponses

  • Moi aussi j'aime le copier/coller :)

    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) :)
  • Il faut fusionner les deux sujets pour leur donner plus de poids ! :)

    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
  • J'ai préféré les scinder pour ouvrir le débat sur les deux sujets séparément. On sait jamais, l'un aura peut-être plus de disciples que l'autre. Je suis seulement ici depuis la version 5.3.1, tant mieux pour vous!

    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.
  • Je suis un petit nouveau. J'ai fait six ou sept tests avec des configurations différentes mais à chaque fois j'ai du ajouter les 2 plugins plxMySearch et plxMyContact et "bidouiller" dans le header pour coller mon logo à la place du titre du site.
    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.
  • C'est bien ça mon argument, le fait que ces trois modifications sont extrêmement communes à l'installation d'un thème. C'est donc une des premières opérations que doit faire un nouveau-venu (qui vient parfois de Wordpress).

    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.
  • C'est aussi un peu valable pour My better url non ?
  • Les écoles de pensée sur le SEO vont s'affronter sur ce point, je ne sauterai pas dans l'arène.

    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...
  • PierrePierre Member
    @Stéphane:

    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...
  • Pierre a écrit:
    j'en suis à une bonne douzaines de thèmes convertis sous la version 5.5

    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 ?
  • Le site de démo de PluXml met en valeur sa simplicité, le thème par défaut est un excellent ambassadeur de cette sobriété. Les articles de la démo sont très sommaires et ne comportent pas (pas encore) d'images accrochées.

    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.
  • Merci pour ces adaptations de masse (le terme peut être employé au vu du chiffre).

    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. :)
  • J'ai répondu souvent mais ça me fait plaisir de recommencer, l'argument est pertinent.

    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.
  • En passant, PPmarcel, le contenu de ton site semble un candidat idéal pour n'importe lequel de mes thèmes. S'il n'est pas bourré de plugins, ça ne devrait normalement être qu'une question de quelques minutes. Pour les versions 5.4, c'est moins facile, je convertirai un thème s'il y a une demande.
  • Pierre a écrit:
    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
    est ce que tu peux nous expliquer à quel moment il y a un problème pour faire ça ?

    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.
  • Pas de problème, ça s'explique facilement. Si vous avez plxMySearch d'installé et fonctionnel sous un thème quelconque (même celui par défaut) et que vous installez un thème "visuellement élaboré", ce deuxième thème recevra dorénavant le formatage CSS et foutra la merde si on repasse au thème précédent ou si on en installe un troisième. Les DIV avec leurs classes et leurs id sont inscrits en dur dans le répertoire du plugin, ils devraient être dans le répertoire du thème, c'est aussi simple que ça.

    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.
  • Je ne suis pas sur de comprendre le problème. Dans les fichiers de l'extension qui affichent le formulaire de contact, il y a déjà les classes CSS qui permettent de mettre en page le formulaire sans toucher au reste.
  • Oui mais le fichier est dans le répertoire du plugin. Si on y touche, c'est pour accomoder un thème. Si on change de thème, il faut retourner dans le répertoire du plugin pour recommencer.
  • toucher à quel fichier ? le code CSS qui modifie l'affichage du formulaire peut se trouver dans un fichier du thème.
    et donc chaque thème peut présenter le formulaire différemment.
  • Si tu prends un de mes thèmes, n'importe lequel qui a un outil de recherche, aucun ne peut faire fonctionner cet outil parce qu'il faut:

    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.
  • StéphaneStéphane Member, Former PluXml Project Manager
    mathieu a écrit:
    Pierre a écrit:
    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
    est ce que tu peux nous expliquer à quel moment il y a un problème pour faire ça ?

    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.

    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 du projet (2010 à 2018)

  • PierrePierre Member
    avril 2016 modifié
    Vous confondez les feuilles de style et leur utilisation. La mécanique d'une recherche reste la même et se rejoint quelque part, on inscrit un mot clé, on appuie quelque part et ça génère une liste de résultats qui sont des liens vers l'article. Ça c'est la mécanique que je voudrais voir incluse dans le système. La feuille de style et son utilisation plus ou moins intelligente par des DIV et autres, c'est une autre histoire.

    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.
Connectez-vous ou Inscrivez-vous pour répondre.