Reprise du message précédent :

 
r'fo C'était la blague

Je suis un peu dans le cas de rufo, single dev d'une appli php/mysql construite il y a fort longtemps, et je suis toujours surpris de la facilité avec laquelle ça passe le test du temps. Passée en PHP 8.3 cette semaine justement, et c'est une librairie associée qui a couiné, sinon zéro souci.
PHP 8.2 c'était un peu plus galère avec pas mal de fonctions qui n'acceptent plus les valeurs nulles en entrée, mais pas trop compliqué à gérer une fois que tu as compris le problème.
Et côté code, j'ai du procédural et de l'objet, un pseudo MVC maison, des objets juste pour les trucs vraiment réutilisés partout / procédural pour ce qui ne servira de toute évidence qu'à un seul endroit.
Surtout j'évite autant que possible les trucs tordus de code sur-optimisé ou trop conceptuels : le délire des objets "véhicule" avec ensuite la classe "voiture" dont la méthode get_roues() surcharge celle de véhicule je trouve ça joli dans les bouquins, mais souvent en pratique c'est aussi le bon moyen de se paumer et s'arracher les cheveux pendant des heures quand tu débugges et que tu ne cherches pas au bon endroit.
En terme de ressources justement, quand tu as une case avec une variable GET et que tu n’exécutes que la partie qui va bien (tests, update bdd, select qui va bien...) c'est juste ultra efficace. A l'opposé quand le moindre appel à la moindre page te charge la moitié de ta bdd en ram via l'appel à 500 fichiers imbriqués (ok j’exagère, mais c'est un peu l'impression que Wordpress me laisse par exemple) forcément c'est plus la même chose. Sur un serveur type kimsufi premier prix, tu peux faire tourner plein de trucs en PHP... mais un site Wordpress est totalement à la ramasse pour le moindre affichage de page qui n'est pas en cache.
 
A côté de ça j'ai dev une app mobile pour Android, vu que je suis une bille sur le sujet j'étais passé par un truc permettant la cross compatibilité ios/Android + coder principalement en JS... ben ça a été une merde sans nom à maintenir, et désormais c'est tombé en désuétude.
J'ai tout refait dans un autre langage équivalent (react-native) car c'est vraiment une app riquiqui, et quel bordel, pour faire la moindre chose tu es "obligé" d'importer des composants tiers, genre pour faire un bouton, un side-panel, ... tout dépend très vite de trucs extérieurs. J'imagine qu'on pourrait tout faire soi-même, mais comme évoqué plus haut, on évite en général de réinventer la roue s'il y a quelqu'un qui a déjà fait ça très bien, qui est probablement nettement plus compétent que moi et qui a fait face à la majorité des bugs et problèmes.
Bref, au bout de 6 mois ça ne compilait plus à cause de dépendances, de librairies abandonnées, de trucs remplacés, ... j'en ai chié... pour une app de 3 écrans / 2 boutons.
 
Donc pour revenir au développement web, j'ai tendance à limiter moi aussi autant que possible l'utilisation de frameworks et librairies tierces... mais pour les trucs vraiment relous (mails, gestion de calendriers avec évènements récursifs, génération de pdf...) difficile de faire sans.
Mais même en prenant les libs les plus populaires du moment, ça arrive quand même régulièrement que le projet soit abandonné.
J'utilisais WAmailer à une époque, et de souvenir ça a merdé et j'ai du passer sur PHPMailer, je crois que c'était justement l'absence de suivi suite à une mise à jour majeure de PHP.
Il y a aussi le moteur de template smarty, avec lequel j'ai commencé directement (en 2004 ou 2005 je crois ?) parce que c'était la base pour séparer code de présentation, ça ne s'est pas toujours bien passé, mais c'est difficile de faire autrement désormais sans tout recoder l'appli. Étrangement après une période difficile (versions de PHP encore, probablement le passage à PHP 7) ça a l'air totalement ok aujourd'hui, et les versions actuelles passent sans souci en PHP 8.3 sans avoir à tout recoder... même si cette couche est totalement dispensable et qu'avec le recul j'aurai dû faire sans.
 
En fait le pire c'est pas forcément la lib dont le suivi s'est arrêté mais plutôt les nouvelles versions non rétrocompatibles. Genre le dev à totalement revu la manière d'intéragir avec sa lib, et là c'est très chiant. Genre tu as besoin de la nouvelle version sinon tu as whatmille erreurs dans ton nouveau PHP X.Y, mais si tu mets la nouvelle version de la lib il n'y a plus rien qui fonctionne et il faut tout refaire l’interaction avec elle.
 
Bordel, j'ai encore fait un pavé, désolé

Un peu pareil que Rufo et Depart, mes classes ne sont souvent que des boites à outils dans lequel je vais piocher des fonctions dont j'ai besoin un peu partout (DB.obj.php, File.obj.php, I18n.obj.php, etc.).
Sinon je fais le plus souvent du procédural.
Pour le problème des mises à jour des libs tierce je passe toujours par un objet intermédiaire "à moi" pour centraliser les appels et donc limiter la casse en cas d'abandon ou de changement.
Par exemple j'ai un singleton Mail:: qui est une surcouche à phpMailer avec toutes les configs spécifiques au client chargé lors de l'initialisation de l'objet.
 
Un jour faudrait faire payer le vrai cout écologique aux services web, entre un site "onepage"de 10Mo avec on ne sait combien de requête à la base de donnée d'un Wordpress "vitrine" (sans actualités ni réel besoinde dynamisme, des fois y'a un formulaire de contact ^^) et l'équivalent 100% html statique avec js et ccs minifié le rapport de ressource gaspillé doit être de 10 ou 100...

Ah ben pareil, pour PHPMailer, j'ai fait une petite surcouche qui m'a permis de pas trop galérer quand j'ai changé de lib pour envoyer des mails

mechkurt : bonne idée l'objet intermédiaire. Je l'avais fait pour smarty, mais en pratique si je voulais passer sur autre chose je suis quasi sûr que ça deviendrait une usine à gaz parce que quand on construit l'intermédiaire on se base sur les besoins de la lib qu'on utilise et si ça se trouve la nouvelle aura besoin d'autre chose et faire un parfait match 1:1 va nécessiter la mise en place d'une usine à gaz.
 
Pour le mail par contre c'est pas bête. J'aurai dû le faire. A la place je me suis fait un truc genre smtp_prepare() qui prend l'objet phpmailer en entrée et le retourne configuré avec tout ce qu'il faut, mais ta solution aurait été meilleure.
 
Le site statique, j'y pense de plus en plus pour les prestas que je fais pour des petites boîtes.
Vu le bordel de Wordpress, les mises à jour, les extensions qui pètent le site lors d'une mise à jour... et en face le client qui ne touche en pratique à strictement rien et qui t'appelle pour faire une modif, c'est tentant de regarder du côté de Hugo par exemple.
Mais en même temps on peut désormais honnêtement facturer une presta de maintenance/sauvegarde mensuelle
 
Et du côté de Hugo (et équivalents), pour l'instant je n'ai pas trouvé beaucoup de contenus sympa (justement des thèmes et plugins qui font la richesse de Wordpress).
Ca manque aussi de GUI (enfin la dernière fois que j'avais testé). Se taper l'ajout de pages ou la compilation via des lignes de shell c'est un peu 90's. C'est bien que ça existe, mais ça serait sympa d'avoir un Hugo éditor avec la lourdeur d'un Wordpress si on veut, et ensuite que ça génère le joli HTML tout seul et le publie en prod à chaque fois qu'on clique sur un bouton "publier".

Ben non l'interet de l'objet c'est la boite noire qui ne te fait qu'exprimer un besoin au niveau de ton code, besoin qui légitimement ne changera jamais.
Affiché une image optimisé & recadré, envoyer un mail, afficher un pdf, etc.
Si tu dois changer de lib il faudra que le job continue à être fait, donc trouver une autre manière de faire.
A un moment donné le plus grosse refactor que j'ai eu à faire sur un changement de lib ca a été de passer de tcpdf à html2pdf (pacque le client avait besoin de bcps de latitude sur la mise en forme de son contenu administrable et il y'a fallut bien verrouiller son tinymce).

La plupart du temps le client se fout un peu de la technologie, et a partir du moment ou il paye il préfère sous traiter la modif a son prestataire.
Je penses que bien amené (sécurité, écologie, économie), le site statique pourrait encore bien se vendre.
Quand je dit statique, je penses surtout au coté léger au niveau du serveur, ça n’empêche pas une certaine richesse (graphisme, animation) au niveau du client...
J'en suis un peu revenu du "ça vas plus vite de poser un WP", ce n'est pas si rapide au final, ça implique des couts de maintenance supérieur et le bilan écologique est vraiment mauvais.

Tout dépend du besoin du client, s'il veut un backoffice facile à prendre en main, ou qu'il a l'habitude de Gutenberg sur WP, alors perso, ça va plus vite de poser un WP, de faire rapidos un template sur mesure, et si fonctions personnalisées très précises, alors j'ajoute un plugin MVC maison via un adapter WP que j'ai également fait de toutes pièces.
Ce qui me permet de rester dans le même environnement de développement (MVC) tout en restant compatible avec un WP.
Et si jamais le client veut virer WP pour passer sur Drupal, j'ai rien à redévelopper puisque j'ai fait l'adapter Drupal aussi.
Même chose si Synfony ou autre...
C'est pas le plus "écologique", mais ça répond à la demande et c'est compatible en temps et en budget pour le client, enfin ça me permet de pas passer trop de temps et de réinventer la roue partout.

This ×1000.
 
J'ai aussi un micro-framework MVC. Je viens de faire un module pour WordPress, le cœur de l'app est complètement agnostique. Tout est planqué derrière des interfaces, ce qui me permet de changer ce qu'il y a en-dessous, voire de l'adapter pour autre chose. Seule la partie admin est 100% spécifique (y'a du WooCommerce aussi, ça va être difficile de s'en abstraire), sinon tout le frontend ne sais même pas qu'il est sous WP.
 
Et comme mechkurt, je planque systématiquement les libs sous-jacentes. Je dois faire de l'export PDF, j'ai donc une couche intermédiaire entre l'app & MPDF. Ainsi je peux changer l'implémentation sans modifier au-dessus. Pareil pour les mails, la DB, etc.

Évidemment je parlais de se passer de WP au profit de site statique dans les cas (relativement nombreux dans mon cas ^^) ou y'a pas de mise à jour coté client (et encore moins de vente en ligne ^^).
Et encore, on pourrait envisager un bout de backoffice qui modifie une page html, mais bon c'est un autre problème.
 
On peut aussi faire un site dynamique sans charger 1Go de fichier php en mémoire et 10 requêtes à la base de donnée, c'était le propos à la base...

Début des années 2000, en stage chez un traiteur, je lui avais codé en Delphi un logiciel de gestion de ses prestations (du devis jusqu'à la facturation, avec la gestion de son catalogue produits). Il avait un site web (statique), bien tout pourri que je lui ai refait. Ben j'ai ajouté une fonction dans mon soft qui regénère les pages concernant les produits de son catalogue quand il faisait des MAJ.

On dirait du moi  

Salut,    
 
J'ai une question référencement par le google bot.
 
Quand on a une page avec un bouton "Chargez plus", comme par exemple ici :
https://www.conseil-etat.fr/actualites
 

 
Qui déclenche le chargement de plus d'items avec un JS.
 
Est ce que le google bot :
1) peut cliquer sur le bouton, et voir la suite ? Et ainsi référencer les pages suivantes ?
2) Ou alors, il ne fait aucune action sur la page, et référence seulement les liens affichés au chargement de la page ?    
 
Si réponse 2), comment faire pour que le bot puisse référencer aussi ces pages, en gardant le principe de "Chargez plus".

je réponds un peu à côté car je ne suis pas dev (mais en tant UX/UI designer je bosse pas mal avec les devs), je trouve que ce n'est pas une bonne conception. Le truc le + simple dans ce cas c'est une pagination, déjà l'utilisateur sait en 1 coup d'oeil le volume d'actualité qu'il y a sur le site, t'as une URL pour chaque page, les pages sont référençables, t'as même pas besoin de tracker un quelconque bouton pour savoir qui clique dessus puisque t'as des vrais pages derrière. Simple et zéro risque de bugs. Tu peux évidemment faire de l'ajax avec un bouton "voir plus" qui va te modifier l'URL à la volée, t'ajouter une entrée dans l'historique navigateur pour faire précédent/suivant, voire même un scrollTo. C'est overkill pour une faible valeur ajoutée Même google est revenu à la pagination classique. A mon agence on a testé toute sorte de trucs depuis 10 ans. Chaque fois c'est complexe, on est revenu à la base.
 
Bref dans ton cas, c'est ni l'un ni l'autre parcequ'il n'y a même pas de requête ajax, c'est juste un bouton qui va afficher des news masquées dans ta page... Donc pour répondre à ta question, je dirai que non Google ne peut pas cliquer sur le bouton mais qu'importe car toutes les news sont déjà dans le code source de ta page (200 actus). Ce qui est pas cool en terme d'éco-conception

Je rajouterais un point trop souvent négligé : ce système d'affichage avec la même url via des requêtes ajax est une catastrophe pour les personnes mal voyantes qui utilisent un lecteur d'écran.En effet, en général, ce type de lecteur ne "voit" pas le nouveau contenu issu de ces requêtes car l'url est restée la même. Or, les personnes malvoyantes, en France, c'est environ 10%. Pas négligeable. Donc, un gros +1 pour revenir sur une conception à base d'une page = 1 url
En plus, un bot de moteur d'indexation se comporte à peu près comme une personne malvoyante. Donc, si tu optimise pour ces bots, de facto, ça va rendre ton site web accessible aux personnes handicapées visuellement

 
Les lecteurs d'écran ont bcp évolué. C'est fini les blocages liés au JS et la nécessité d'avoir un site qui marche sans JS. Même la page de google search ne marche plus sans JS. Et pareil pour les bots (malheureusement, car du coup, pas moyen de les by-passer... )

Attention, j'ai pas dit que les lecteurs d'écran ne savaient pas gérer un site avec du JS. Je dis que les lecteurs d'écran ont beaucoup de mal à détecter une zone d'une page qui avait un contenu et qui en a changé suite à un clic sur un élément qui a déclenché une requête ajax.
J'ai été chez une ami qui est aveugle à 85% environ et qui m'a montré son lecteur NVDA. Ce type de site avec une seule url pour tout le site avec une navigation à base de boutons et non de liens hypertextes étaient un enfer pour elle
En effet, NVDA fait en début de page un menu contenant toutes les urls avec les éventuels raccourcis clavier que les dév auront dénié mettre (accesskey). Si tu as que des boutons avec du javascript, ben ce menu de navigation n'est pas créé. D'où l'intérêt aussi du lien caché avec une ancre qui permet de sauter direct au contenu de la page sans que le lecteur d'écran te relise tout le menu principal et contextuel à chaque changement de page

Merci pour vos réponses.
 
Et si je fais un faux "chargez plus".
 
C'est à dire que je charge tous les contenus dans la pages, et je les masques en CSS. Le bouton servira seulement à les afficher en JS.  
 
Ca va fonctionner non ?

Oui, mais pour le temps de chargement, c'est pas top Et ça va faire surconsommer de la bande-passante pour rien si l'utilisateur regarde que peu d'articles. C'est pas écologique.

je comprends pas, c'est pas déjà le cas actuellement ?

Si les articles sont paginés, tu ne charges que les articles de la page affichée.

Non, mais avec un correct sitemap, on s'en fout un peu du loading pour la SEO.

Oui, il y en aura un.
 
Mais après ça doit améliorer le référencement d'avoir un bon maillage des pages.

 
Bof, non. De plus, les bots maintenant utilise aussi la page search. Franchement, on ne compte plus les sites avec un "load more" JS. C'est plus du tout un frein au référencement. Tout ça, c'est du passé.

Mais c'est un frein aux personnes handicapées visuellement

Ca dépend, tu peux toujours rajouter le balisage aria qui va bien pour faire comprendre aux lecteurs d'écrans que la page a bougé.. mais bon il faut savoir/vouloir le faire

Qu'appelles tu la page search ? Le sitemaps.xml ?

 
Généralement, les sites wordpress proposent une page de recherche et cette page est utilisée aussi par les moteurs de recherche.

Ou n’importe quel site qui a mis les bonnes balises json/schema

C'est pas du wordpress.

 
Le référencement est un robot hiérachique sur les balise <a></a>

Putain Jovalise, vire ton bot de merde si c'est pour répondre ce genre de connerie inutiles

 
https://developers.google.com/searc [...] rter-guide
 
Google supports web components. When Google renders a page, it flattens the shadow DOM and light DOM content. This means Google can only see content that's visible in the rendered HTML. To make sure that Google can still see your content after it's rendered, use the Rich Results Test or the URL Inspection Tool and look at the rendered HTML.
 
Donc j'en comprends que si le contenu est chargé mais pas visible ça doit aller, mais si il est pas chargé le crawler va passer à coté.
 
 

Ça dépend de comment on comprend "visible" et "rendered" dans "Google can only see content that's visible in the rendered HTML."

Je comprends ça comme “le truc que tu veux afficher existe dans le DOM”. Si le chargement du contenu dépend d’une action humaine (click, scroll) le crawler ne va pas la faire

De toutes façons si on pense au SEO avec les éléments cachés ou non, si bouton « charger plus », c’est qu’on a pas bien compris en quoi consistait le SEO…

 
Tu semble vouloir contribuer à la désinrformation sur un forum publique pour promouvoir le bon sens des chose alors je te félicite d'avoir réussi non seulement à construire une phrase en langage de France ; De me faire sauté le plomb de la pertinence ; Ansi que de me faire esquisser un petit rictus de bon matin.

Salut,
 
J'ai une question d'affichage sur les mobiles.  
Je ne comprends pas pourquoi les images s'affichent différemment de leur résolution.
 
Par exemple un iphone 12 pro, fait 2532 x 1170 pixels.
 
Pourtant, une image en 390 px de large, prend toute la largeur.
 
Exemple avec https://www.lemonde.fr/

 
Pourquoi ?
Comment savoir la taille que prendra une image sur les smartphones ?

Parce que 1 px != 1px.
En gros pour compenser la très forte densité des écrans retina (pareil sur Android hein) on sépare la résolution réelle de l'écran de celle de la zone d'affichage (viewport).

Cherche viewport et responsive dans ton moteur de recherche préférée pour apprendre la distinction.

ton iPhone a une densité de pixel (DPR) de 3 donc une largeur de 1170px te donne en réalité une zone d'affichage de 390px

Merci, j'ai compris.
 
Il faut regarder le Viewport Size  
https://yesviz.com/viewport/
 
J'ai un site où on affiche des images en 320 px de large sur smartphone.  
Mais ça ne parait plus du tout adapté aux tailles actuelles. J'ai donc des affichages bien crados.
 
Il faudrait le passer à 440px, vu que ça semble le max d'aujourd'hui.