Vous n'êtes pas identifié(e).
bonjour,
j'ai été amené à découvrir Zite+, et corriger le module de recherche pour:
ajouter l'entité html € comme caractère de recherche
exclure de la recherche les fichiers cachés commençant par underscore
utiliser, dans les résultats, le titre personnalisé des pages si existant
moderniser le balisage, suppression de balises désuètes ou dépréciées,
utilisation nouvelle balisage html5 plus sémantiques: <mark> **
Les résultats sont "classé" (class=) pour les cibler plus facilement en css ***
par la même occasion, traduit les messages en anglais et compléter l'externalisation des messages
** <mark> nécessite l'utilisation de html5shiv, par exemple via un Cdn:
[== HTML ==]
<!--[if lte IE 9]>
<script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.6.2/html5shiv.js" type="text/javascript"></script>
<![endif]-->
*** les styles minimums pour obtenir une pésentation traditionnelle:
[== CSS ==]
/* nouveau balisage search.php */
.searchResult,
.searchValue {
text-align:left;
}
.newsearch,
.numberPages,
.searchBar,
.searchResultNumber {
text-align:center;
}
.newsearch form {
margin:auto;
}
/* balise html5 */
mark {
background:none repeat scroll 0 0 yellow;
color:inherit;
}
enfin, pour ceux que ça intéresse, et je l'espère pour intégration future :
search.php
search.ini
fichier diff commenté
si ça peut servir
Edit: comme je m'étais mélanger les pinceaux, je viens de modifier une erreur dans search.php sur github
Dernière modification par kyodev (03/05/2013 10:41:24)
Hors ligne
Bonjour kyodev,
Effectivement le module search n'a pas bougé depuis longtemps: j'ai publié aujourd'hui une remise à jour du module qui
est disponible comme d'habitude à cette adresse ou directement depuis l'interface d'administration
en utilisant la mise à jour depuis le site officiel.
Les nouveautés
- Ajout recherche caractères € œ et £
- Passage des derniers messages du source dans search.ini
- Simplification de l'affichage si pas de valeurs
- Option de configuration (champ de recherche+nombre résultat/page)
Concernant les modifications que tu proposes:
ajouter l'entité html € comme caractère de recherche
Bien vu
J'en ai profité pour ajouter aussi le support d'autres entités HTML
exclure de la recherche les fichiers cachés commençant par underscore
à voir
utiliser, dans les résultats, le titre personnalisé des pages si existant
Qu'est-ce que tu veux dire par titre personnalisé ?
moderniser le balisage, suppression de balises désuètes ou dépréciées,
utilisation nouvelle balisage html5 plus sémantiques: <mark> **
Le passage en HTML5 est pour l'instant un peu prématuré et une dépendance supplémentaire à la bibliothèque html5shiv n'est pas souhaité.
Les résultats sont "classé" (class=) pour les cibler plus facilement en css ***
Oui , cibler les résultats (et pas seulement d'ailleurs) fait partie des évolutions souhaitables de ZitePlus
par la même occasion, traduit les messages en anglais et compléter l'externalisation des messages
Oui, comme Stéphane l'avait remarqué, tous les messages n'étaient pas encore dans le fichier search.ini
C'est le cas maintenant.
Je regarderai pour intégrer ta traduction anglaise dans la version fourni avec la 0.9.3
@Stéphane: si tu m'envoyer la traduction allemande
a+
Jean-Paul
Hors ligne
bonjour
J'en ai profité pour ajouter aussi le support d'autres entités HTML
bien, j'avais pas pris le temps de le faire
kyodev a écrit :exclure de la recherche les fichiers cachés commençant par underscore
à voir
?? ça me parait normal, si on ne veut pas montrer certaines pages (accessoires) autant qu'elles ne s'affichent pas dans une recherche, non?
kyodev a écrit :utiliser, dans les résultats, le titre personnalisé des pages si existant
Qu'est-ce que tu veux dire par titre personnalisé ?
je ne suis pas encore parfaitement connaisseur de Zite+, je découvre, mais je me suis retrouvé dans les résultats avec les titres du menu, donc très simples. je préfère les types configurés (et optimisés) page par page, plus longs et plus parlants. ce que j'ai pu faire en utilisant :
empty($page[cPageNavTitle])?$page[cPageTitre]:$page[cPageNavTitle]
kyodev a écrit :moderniser le balisage, suppression de balises désuètes ou dépréciées,
utilisation nouvelle balisage html5 plus sémantiques: <mark> **une dépendance supplémentaire à la bibliothèque html5shiv n'est pas souhaité.
mouais, ça c'est pour bourrin <=ie8, qui commence à devenir rare. ce script est lége. Au pire, si non intégré, pour search, ne 'surlignera' pas les termes recherchés, ce que je considère comme une dégradation non disgracieuse.
avec les commentaires conditionnels ça ne nuit pas aux autres navigateurs modernes qui eux peuvent gérer cette balise.
et ce n'est pas pire que d'appeler jQuery dans le <head>, même si non utilisé (et configuré en automatique).
en terme de performances, ça serait mieux en fin de <body>, ce qui se gère facilement dans le template, encore faut-il le savoir.
Mais pourquoi alors une option dans la config?
cibler les résultats (et pas seulement d'ailleurs) fait partie des évolutions souhaitables de ZitePlus
+1
merci
Hors ligne
jpg a écrit :kyodev a écrit :exclure de la recherche les fichiers cachés commençant par underscore
à voir
?? ça me parait normal, si on ne veut pas montrer certaines pages (accessoires) autant qu'elles ne s'affichent pas dans une recherche, non?
à voir, car il faut déterminer si à terme on va le faire ainsi (utilisation du _)
Pour l'instant je n'en sais rien
jpg a écrit :kyodev a écrit :utiliser, dans les résultats, le titre personnalisé des pages si existant
Qu'est-ce que tu veux dire par titre personnalisé ?
je ne suis pas encore parfaitement connaisseur de Zite+, je découvre, mais je me suis retrouvé dans les résultats avec les titres du menu, donc très simples. je préfère les types configurés (et optimisés) page par page, plus longs et plus parlants. ce que j'ai pu faire en utilisant :
empty($page[cPageNavTitle])?$page[cPageTitre]:$page[cPageNavTitle]
Ok, je comprends mieux.
En terminologie "ZitePlusienne", le module de recherche utilise la zone "titre de la page", toi tu as utilisé "Contenu balise <title>" ... et on pourrait
tout aussi bien utiliser aussi sous une forme ou une autre "Bref description de la page".
Peut-être une nouvelle option de configuration pour le module de recherche
jpg a écrit :
kyodev a écrit :moderniser le balisage, suppression de balises désuètes ou dépréciées,
utilisation nouvelle balisage html5 plus sémantiques: <mark> **une dépendance supplémentaire à la bibliothèque html5shiv n'est pas souhaité.
mouais, ça c'est pour bourrin <=ie8, qui commence à devenir rare. ce script est lége. Au pire, si non intégré, pour search, ne 'surlignera' pas les termes recherchés, ce que je considère comme une dégradation non disgracieuse.
avec les commentaires conditionnels ça ne nuit pas aux autres navigateurs modernes qui eux peuvent gérer cette balise.
Le surlignage devra être fait via css, quand les bonnes classes et/ou id seront intégrées dans le code.
et ce n'est pas pire que d'appeler jQuery dans le <head>, même si non utilisé (et configuré en automatique).
en terme de performances, ça serait mieux en fin de <body>, ce qui se gère facilement dans le template, encore faut-il le savoir.
Mais pourquoi alors une option dans la config?
AMHA, l'entête du jquery est placé là ou il faut
De plus, sauf erreur, cet en-tête n'est généré (en mode automatique) que si un module ou une page le demande (si on s'en sert quoi)
En tout cas c'est l'idée
a+
Jean-Paul
Hors ligne
à voir, car il faut déterminer si à terme on va le faire ainsi (utilisation du _)
les nouvelles versions ne sortant pas à un rythme effréné, il y a aussi l'utilisation au quotidien, surtout quand ce n'est qu'une vingtaine de caractères à ajouter. les utilisateurs avancés peuvent le faire, et le développement tenir compte des pbs rencontrés par les utilisateurs.
tout aussi bien utiliser aussi sous une forme ou une autre "Bref description de la page".
c'est ce que je rajouterai à l'occasion biensur, en plus du titre de page, à la google, ça aide l'utilisateur
Peut-être une nouvelle option de configuration pour le module de recherche
+1
AMHA, l'entête du jquery est placé là ou il faut
donc la page attend que la librairie soit chargée?
ce qui est un comble pour celle ci, puisque par nature, elle requiert que le Dom soit prêt pour fonctionner.
de mémoire, c'est indiqué sur jquery.com et ici par exemple
cet en-tête n'est généré (en mode automatique) que si un module
ce n'as pas été mon cas, tout du moins avec le peu de modules que j'ai laissé actif. et je vois pas lequel pourrait avoir besoin de Js.
ce qui ne me gêne en aucun cas, je préfère peaufiner ça dans le template, mais par défaut il serait mieux de suivre les recommendations et ne ne pas l'activer car je ne pense pas qu'une version de base de Zite+ en aii besoin, non?
Hors ligne
jpg a écrit :à voir, car il faut déterminer si à terme on va le faire ainsi (utilisation du _)
les nouvelles versions ne sortant pas à un rythme effréné, il y a aussi l'utilisation au quotidien, surtout quand ce n'est qu'une vingtaine de caractères à ajouter. les utilisateurs avancés peuvent le faire, et le développement tenir compte des pbs rencontrés par les utilisateurs.
peut-être un peu nouveau sur le forum pour ce genre de remarque
Pour sortir la 0.9.3 plus vite, tu peux participer aux tests, tu es le bienvenu.
jpg a écrit :tout aussi bien utiliser aussi sous une forme ou une autre "Bref description de la page".
c'est ce que je rajouterai à l'occasion biensur, en plus du titre de page, à la google, ça aide l'utilisateur
jpg a écrit :Peut-être une nouvelle option de configuration pour le module de recherche
+1
jpg a écrit :AMHA, l'entête du jquery est placé là ou il faut
donc la page attend que la librairie soit chargée?
ce qui est un comble pour celle ci, puisque par nature, elle requiert que le Dom soit prêt pour fonctionner.
de mémoire, c'est indiqué sur jquery.com et ici par exemple
Alors les gars qui ont développé le site jquery.com n'ont pas du lire le manuel
car à la ligne 26, dans la section <head> ... </head>
on trouve la ligne suivante:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
Il va falloir leur dire de suivre ta technique
D'autre part, je te rappelle que l'appel de ce script jquery à toutes les chances de se trouver déjà en cache => temps de chargement totalement négligeable.
jpg a écrit :cet en-tête n'est généré (en mode automatique) que si un module
ce n'as pas été mon cas, tout du moins avec le peu de modules que j'ai laissé actif. et je vois pas lequel pourrait avoir besoin de Js.
ce qui ne me gêne en aucun cas, je préfère peaufiner ça dans le template, mais par défaut il serait mieux de suivre les recommendations et ne ne pas l'activer car je ne pense pas qu'une version de base de Zite+ en aii besoin, non?
Tu as le manuel concernant cette option là
Si query_load est sur automatique et que la référence à l'api est générée alors qu'auncun module ou page ne l'a demandé ... c'est tout simplement un petit bug.
qui sera corrigé dans la 0.9.3.
a+
Jean-Paul
Hors ligne