[SI-LINDER-PARTNER-2][OSC] - Refonte du site Internet pour supporter le Responsive Design /* ATTENTION - le design du site ne peut pas être passé en doctype html (html 5) dans la révision 1 du design. bien qu'une révision 2 sera instanciée plus tard (l'année prochaine), il faudra se contenter de nombreux workaround en restant en HTML TRANSITIONAL 4.01 Du fait du nombre massif des éléments DE CETTE PAGE (et de ce qui en découlerait) qui seront à revoir pour transformer le design en design responsive.. .. il est alors plus judicieux de globaliser un TAG unique pour cette tâche pour ne pas alourdir de commentaires le code déjà suffisemment alourdi comme cela! En gros, ici, pour cette méga-tâche, je vais utiliser un format maison de commentaires pour cette tâche précise: --> pour en comprendre les méandres, voir le fichier /[!] - Saphyra-Interactive-TaskList-Explanations/[SI-LINDER-PARTNER-2][OSC]--semantic.php */ // <- [SI-LINDER-PARTNER-2][OSC] - Refonte du site Internet pour supporter le Responsive Design ?> [VTAB-TEAM-LINDER-PARTNER-1][OSC][SimpleTaskDescription]:{" on ferme la div dans laquelle on insère une classe afin de permettre au corps de la page, situé en dessous du header, d'être toujours visible à la suite du header et non en caché car ce dernier est en position "fixed" "} ?> [SI-LINDER-PARTNER-2][OSC][MultiTaskDescriptions]:{ - 1/ dans la nouvelle version du design, on va ajouter en bas de page une zone qui proposera différents liens rapides sous formes d'ancres HTML () pour ce faire, ici UI Kit ne nous servira pas à construire cette zone, mais au contraire, on va utiliser un concept simple, une table! UI Kit nous servira juste pour styliser les textes - 2/ cette bidouille visuelle permet de créér un effet de bloc "LEGO" englobant les différentes sous-zones cela permet aussi de fixer visuellement par illusion d'optique les éléments plus hauts "En Savoir Plus" afin de faire un remplissage de l'espace de manière intelligente l'idée est simple: provoquer un effet d'émotions au design en deux classes: --footerMenuBand et --footerMenuBand--Container pour ce faire on modifie les marges de -5% (donc en réduction) cela toutefois necessite en [3] de fixer la marge extérieure basse afin de l'élargir pour décaler la ligne dessous - 3/ et on fait cela en utilisant un élément
qui ne sert qu'à définir une marge basse afin de fixer l'overlap (le recouvrement) de la zone boire par la ligne ci-dessous, donc éviter que la zone de copyright et bannière OSCommerce overlap on fait cela à l'aide de la classe --footerMenuBand--MarginMaker on a juste à remettre par défaut la marge basse en augmentant la-dite marge de +5% (donc en augmentation) - 4/ ici on établi la structure de boite de liens "Produits", il s'agit d'une petite colonne de tableau - 5/ ici on établi la structure de boite de liens "Notre société", il s'agit d'une petite colonne de tableau NOTE - depuis 2021, suite à une demande du client, on précède l'appel à la fenêtre modale d'une fonction Javascript qui est développée justement (depuis 2021) dans le fichier contenant la structure de la modale la fonction se nomme: quelTexteAfficherPourModale_boxCardboxMethodesPaiement() et ici on lui fourni l'argument 'Voir tous' afin que si par le passé (sans rafraichir la page) on serait passé par le cardbox listant les moyens de paiements (/includes/boxes/si_newdesign2019_methodes_paiement_cardbox.php) situé dans la colonne de gauche (/includes/column_left.php) on aurait peut-être eu que partiellement les moyens de paiements affichés pour comprendre tout cela, allez lire le fichier qui contient le nouveau système d'affichage DE CETTE modale en particulier (VOIR CODETAG[NEW_FEATURE_FOR_CARDBOXMETHODESPAIEMENT_TASKS_FUNCTIONS_MECHANISM]) - 6/ ici on établi la structure de boite de liens "Mon compte", il s'agit d'une petite colonne de tableau - 7/ ici on établi la structure de boite de liens "Contact", il s'agit d'une petite colonne de tableau - 8/ ici on décale la section d'un range au-dessus pour permettre d'agrandir la section tout en gardant les marges, ce qui permettra de remplir la couleur. L'actuel section se retrouve en-dessous et consitue une div. } */ ?> [SI-LINDER-PARTNER-2][OSC][SubTaskDescription]::BEGIN ?> [SI-LINDER-PARTNER-2][OSC][SubTaskDescription]::BEGIN ?> [SI-LINDER-PARTNER-2][OSC][SubTaskDescription]::BEGIN ?> [SI-LINDER-PARTNER-2][OSC][SubTaskDescription]::END ?> [SI-LINDER-PARTNER-2][OSC][MultiTaskDescriptions] ************************************************************************/ ?>
*/ ?> [SI-LINDER-PARTNER-2][OSC][MultiTaskDescriptions]:{ - 1/ dans la nouvelle version du design, tout le bloc qui affichait la bannière OSCommerce ancienne, doit être déplacée, car, elle n'a plus lieue d'exister ici désormais, elle sera placée ailleurs (cherchez le CODETAG: [OSCOMMERCE_ENGINE_BANNER_IS_NOW_HERE]) ici, tout le bloc est commenté, sauf la vérification de l'existence de la bannière } */ ?> [SI-LINDER-PARTNER-2][OSC][SubTaskDescription]::BEGIN ?>
*/ ?> [SI-LINDER-PARTNER-2][OSC][SubTaskDescription]::END ?> [SI-LINDER-PARTNER-2][OSC][MultiTaskDescriptions] ************************************************************************/ ?> [SI-LINDER-PARTNER-2][OSC][MultiTaskDescriptions]:{ - 1/ dans la nouvelle version du design, on va remodeler la structure de la bande de copyright (touts droits réservés) le fichier de langage: /includes/languages/french.php a été modifié, pour faire en sorte que le texte soit plus adapté à notre époque, et où Saphyra Interactive a été rajouté je n'ai pas retiré Accrosys, car il s'agit de l'un des anciens prestataires de qualité d'ancienneté du site, et d'un grand ami - 2/ la bannière OSCommerce ancienne, doit être déplacée, car, elle n'a plus lieue d'exister à l'endroit où elle était initialement (cherchez le CODETAG: [OSCOMMERCE_ENGINE_BANNER_WAS_HERE]) désormais, elle sera placée ici on créé un tableau associatif à index nommés qui seront calqués sur la structure de la variable que OSCommerce initialise de lui-même: $banner variable dont on gardera les index: banners_id, banners_title, banners_image, banners_html_text mais on laissera banners_image tel quel (afin que la fonction tep_display_banner() trouve bien l'image initiale et que cela ne nous demande pas de modifier la fonction) en revanche.. on va modifier le chemin de la véritable image dans banners_html_text car on va se servir d'une autre image, trouvée sur le site de OSCommerce, on supprimera quelques attributs HTML dont on aura pas besoin comme alt et title, on lui ajoutera aussi un attribut class, car on va jouer sur l'inversement des couleurs de l'image (grâce à un filtre) au survol (en CSS) on entoure l'image d'un lien HTML, mais, au lieu d'utiliser l'attribut href.. on va se servir de l'évènement Javascript onclick, cela permettra d'éviter d'avoir l'infobulle hyper-moche des navigateurs qui rajouteraient un survol de recouvrement par leur infobulle sur l'image.. ce faisant, toutefois, on perd la faculté d'ouvrir le lien dans une nouvelle page, mais bon.. tant pis, c'est un petit mal pour un grand bien } */ ?> [SI-LINDER-PARTNER-2][OSC][SubTaskDescription]::BEGIN ?>
[SI-LINDER-PARTNER-2][OSC][SubTaskDescription]::END ?> [SI-LINDER-PARTNER-2][OSC][MultiTaskDescriptions] ************************************************************************/ ?> [SI-LINDER-PARTNER-2][OSC][MultiTaskDescriptions]:{ - 1/ on créé le
magique que Facebook requière pour charger son Widget Like/Page etc.. car oui, pour la nouvelle version du design en 2019, on va utiliser la toute nouvelle version du Widget Like, en api 4.0, nommé Page ainsi, pour que ça fonctionne, on a besoin d'une balise HTML
ayant un attribut d'ID (fb-root) la balise ne doit rien contenir, mais elle doit être refermée à peine ouverte, comme indiqué sur le site de Facebook Developers ici: https://developers.facebook.com/docs/plugins/ à noter que dans le fichier /includes/boxes/si_newdesign2019_socialisation_buttonbox.php on a une structure HTML qui est ciblée par l'API Facebook, ici, l'on construit l'appel à l'API (cherchez le CODETAG: [FACEBOOK_DISPLAYER_IS_STRUCTURED_HERE]) et enfin, on charge l'API Facebook depuis le domaine connect.facebook.net, qui est le serveur où Facebook propose ses APIs gratuitement au public } */ ?> [SI-LINDER-PARTNER-2][OSC][SubTaskDescription]::BEGIN // [FACEBOOK_API_IS_INITIALIZED_HERE] ?>
[SI-LINDER-PARTNER-2][OSC][SubTaskDescription]::END ?> [SI-LINDER-PARTNER-2][OSC][MultiTaskDescriptions] ************************************************************************ */ ?> [SI-LINDER-PARTNER-2][OSC][MultiTaskDescriptions]:{ - 1/ il s'agit d'une réparation d'une énorme bêtise de Google Translate Element gadget.. suite à ce problème: https://github.com/google/material-design-lite/issues/1721 "Goggle translate destroying material-icons tags" en effet: ça bousille entièrement les icones Material Design Icons pourtant, Google Translate Element gadget et Google Material Design Icons sont tout deux des produits.. Google.. : mais ils ne sont pas d'accord voici une explication plus concise du problème (en anglais), par l'auteur du post-initial du problème: * Sorry if I'm not doing this correctly, but I just joined GitHub to submit this issue! * * I'm using MDL for the first time on a new site and discovered some major problems when users use google translate to translate the page. * Google translate replaces any text with it's translated version and surrounds it with double tags. * * First I thought the font tags where the problem, * then I realized it's translating the icon label withing the tag, * so MDL now has no idea which icon you want and it seems like the tags additionally mess with the layout. * * I'm working around the problem by adding the class "notranslate" to the tags which does seem to work, * but it doesn't fix the problem for the "hamburger" drawer icon since that is injected by the JS. * Is there a way to work around this so it's fixed out of the box for MDL? * * Seems like a big issue and unfortunate if the answer is that everyone has to had class="notranslate" to every tag. * * Also, any ideas on how to fix the hamburger icon? un collaborateur de Google Material Design Icons est au courant de ce souci, voici sa réponse: cf: https://github.com/google/material-design-lite/issues/1721#issuecomment-167230926 * Commit 04beffa solves the menu icon being translated by using the codepoint. * * Either using notranslate with ligatures or the codepoints solves the problem, at least with icons. * * For other Translate issues... Probably best to wait for 2.x when we refactor loads of stuff including layout. * * We can clearly see layout and possibly grid are completely screwed in translate, but for no *apparent reason. * * Rather than spend time debugging this now we should do testing ahead of releasing 2.x to make sure it works better in these cases. * * Marking this as a 2.x milestone thing as a reminder. sauf que.. ça n'a jamais été fixé.. depuis 2015... 5 ans pu--.. et toujours pas de patch de Google pour ce souci complètement idiot où Google Translate Element gadget s'entête à traduire les noms de codes des icones Material Design Icons... bref, j'ai donc mis au point mon propre patch.. c'est très simple: j'associe une fois la page chargée à chaque élément du DOM qui possèdent une classe material-icons une seconde classe: notranslate, et cela, à l'aide d'un code Javascript et d'une boucle! (car utiliser les Code Points, aurait été une plaie, dans le sens où j'aurait du reprendre chacun des fichiers 1 par 1 et donner un nom différent à l'icone en correspondance avec son Code Point code-points material design icons: https://github.com/google/material-design-icons/blob/master/iconfont/codepoints) l'effet est réussi: toutes les icone Material Design Icons sont alors préservées, car chaque élément qui possède une classe material-icons sont en réalité des icones Material Design Icons contre-coup: ça peut faire ramer la page si il y a plus de 10000 icones, mais.. on en est à milles lieues! } */ ?> [VTAB-TEAM-LINDER-PARTNER-1][OSC][SimpleTaskDescription]:{" on inclut les fonctions javascript vtab pour toutes les pages "} require(DIR_WS_FUNCTIONS . 'vtab.js.php'); ?> [SI-LINDER-PARTNER-2][OSC][SubTaskDescription]::BEGIN // [GOOGLE_TRANSLATE_ELEMENT_GADGET_ON_MATERIAL_DESIGN_ICONS_BUGFIX_HERE] ?> [SI-LINDER-PARTNER-2][OSC][SubTaskDescription]::END ?> [SI-LINDER-PARTNER-2][OSC][MultiTaskDescriptions] ************************************************************************ */ ?> [SI-LINDER-PARTNER-2][OSC][MultiTaskDescriptions]:{ - 1/ - 2/ ATTENTION // [EXPORT_CATEGORIES_MENU_INTO_AN_EXTERNAL_OVERLAY_WITH_UI_KIT__THE_OVERLAY_LOCATION] - avant octobre 2020, le client, aimait l'affichage de cet élément - depuis octobre 2020, le client, finalement préfère un autre affichage (plus d'informations dessous) suite à la modification effectuée sur le menu des catégories (encore lui, oui!) (voir CODETAG[EXPORT_CATEGORIES_MENU_INTO_AN_EXTERNAL_OVERLAY_WITH_UI_KIT__THE_OVERLAY] dans /includes/boxes/categories.php) on doit ici afficher le menu responsive (deuxième version : l'overlay responsive) car l'afficher dans (voir CODETAG[EXPORT_CATEGORIES_MENU_INTO_AN_EXTERNAL_OVERLAY_WITH_UI_KIT__THE_OVERLAY] dans /includes/boxes/categories.php) serait idiot dans le sens où certaines classes en responsive modifie l'apparence visuelle de l'élément --siteColumnLeft de certaines pages (fichiers du site!) ainsi, parfois, --siteColumnLeft se trouve masqué parfois, et donc, ben.. on peut pas y afficher le vrai menu, donc, si on garde le menu responsive overlay dans --siteColumnLeft on sera dans l'incapacité d'ouvrir le menu car masqué globalement dans --siteColumnLeft ! l'afficher ici est donc primordial! } */ ?> [SI-LINDER-PARTNER-2][OSC][SubTaskDescription]::BEGIN ?> [SI-LINDER-PARTNER-2][OSC][SubTaskDescription]::END ?> [SI-LINDER-PARTNER-2][OSC][MultiTaskDescriptions] ************************************************************************ */