Bonjour à tous,

Je me permets de ce petit message car je suis débutant en PHP Symfony et j'ai déjà des buggs concernant le favicon sur Symfony 6.

J'ai dans mon dossier public/images/.... mon image en 16x16 du favicon 

et sur base.html.twig le code suivant : 

Cependant, le favicon ne se visualise toujours pas Avez-vous une solution ?

Je vous remercie.

Conrad

Bonjour,

As tu regardé avec les outils de développement du navigateur si tu avais des messages dans la console.

En général, le problème vient du chemin indiqué.

A+

Bonjour Conrad,

La fonction asset() fait déjà référence au dossier "public/". Donc en réalité ton chemin d'accès ressemble à: "public/public/images/favicon.jpg".

N'oublie pas que si tu utilises Webpack Encore et que dans ta config de Webpack tu utilises ".copyFiles()"

*(par exemple: .copyFiles({from:'assets/images',to:images/[path][name].[ext]})

tu auras un nouveau répertoire nommé "build/" dans ton dossier "public/" dans lequel il y aura toutes les copies des répertoires de "assets/" qui auront été indiqué via copyFiles().

*Dans le cas de l'exemple montré ci-dessus (.copyFiles(...)), ta fonction asset() devra ressembler à: " {{asset(build/images/favicon.jpg)}} "

source :https://symfony.com/doc/current/frontend/encore/copy-files.html

ps: le "/>" pour fermer les balises orphelines est fortement déconseillé par le W3C maintenant, même s'il fonctionne la plus part du temps.

-
Edité par Mathieu Constantin 28 septembre 2022 à 11:37:09

MathieuConstantin1 a écrit:

ps: le "/>" pour fermer les balises orphelines est fortement déconseillé par le W3C maintenant, même s'il fonctionne la plus part du temps.

AbcAbc6 a écrit:

MathieuConstantin1 a écrit:

ps: le "/>" pour fermer les balises orphelines est fortement déconseillé par le W3C maintenant, même s'il fonctionne la plus part du temps.

Bonjour, Ha bon?? Jamais entendu cela, source??

J'ai récemment utilisé le validateur html fourni par le W3C et j'ai reçus un message d'erreur avec mes balises orphelines (ex: <br/>, <link rel="" href="" />).

C'est expliqué à cette adresse: https://google.github.io/styleguide/htmlcssguide.html#Document_Type

Moué. De ce que je vois de l'exemple sur https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=10809 qui est proposé sur le validateur W3C, le problème n'est pas le / pour auto-fermer, mais l'absence d'espace entre la fin de l'attribut "class" et le /. Et l'absence de guillemets - certes optionnels. Je trouve un peu gonflé (pas de votre part, hein) de déprécier la manière auto-fermante sous prétexte que certains outils les comprendraient mal : c'est blâmer la faute sur l'ouvrier alors que ce sont les outils le problème, à mon sens. (et j'avoue être pas mal refroidie par le lien du validateur vers un styleguide de Google… c'est pas le taff de Google de décider des standards)

-
Edité par Lamecarlate 30 septembre 2022 à 8:52:40