Reprise du message précédent :
Bon courage pour la refactorisation

C'est du wordpress, je ne suis pas trop étonné

C'est bô

Doom Scroll
https://codepen.io/cobra_winfrey/pen/oNOMRav
(marche pas sur FF mais marche sur Chrome)

 
1/ tu pars du principe que la personne a été formée, j'en serais pas aussi certain
2/ je suis presque déçu, j'aurais aimé un petit if boolean == True

Demande de webmastering pour un site : comme d'hab, je dis OK sous réserves :
 
Fourniture des accès, je commence à regarder un peu le truc :
 
index.php déjà :
 

 
 
 
MAIS. POURQUOI.
 

 
 
Bah quoi ?
 
C'est un site fait par le cousin du neuveu de la voisine, celui kissiconnait.   On voit qu'il a bien suivi les tutoriaux pour débutant d'il y a 10 20 ans.    

ça rappelle du (mauvais) code du début des années 2000

mais j'avais pas vu : l'injection js qui est built in

Le pire c'est les deux extract

J'ai compris !
En fait c'est le site que le visiteur peut également administrer et modifier le contenu de la page :

Suis trop con !

Je. Vais. Hurler.

Bonjour a tous,
 
J'espère ne pas me tromper de fil ou de forum, je sais pas ou poster, c'est ce que je trouvais de mieux
 
Pour faire simple, je suis passé de fonctionnaire à indépendant... Et j'ai donc besoin d'un site web pour mon activité. Il est en ligne. Evidemment, je l'ai fait moi même et l'amateurisme est total, mais c'est relativement fonctionnel et je pense que ça conviendra pour un début.
 
Je m'intéresse ceci dit au référencement, et actuellement il n'est pas très bon comparé à mes confrères. Bon, il faut être patient, mais un autre détail m'interroge :
 
C'est un wordpresss, hébergé sur Wordpress.com . Parce que j'aime pas faire les choses simplement, j'ai acheté un nom de domaine chez gandi.net et j'ai fait une redirection.
 
Gandi me propose trois types de redirection et actuellement j'ai choisi celle-ci.
 

 
Bon vous voyez le problème : "caché" est le seul moyen de cacher l'url monsite.wordpress.com par une URL normale.
 
Néanmoins, j'ai cette punition : mauvais référencement.
 
Quelqu'un peut peut me dire si c'est effectivement une variable importante, du pipeau, ou s'il y a moyen de contourner cela?  
 
Merci !  
 
(J'aimerais ne pas avoir à donner l'adresse de mon site web sur cette page si possible )
 

Pourquoi ne pas faire un enregistrement DNS ? C'est le plus propre. En 2s de google la procédure pour wordpress : https://wordpress.com/fr/support/do [...] sonnalise/

 
J'imagine que c'est du WP ou un truc du genre. C'est quand même vraiment horrible ce mélange.

Alors je pense l'avoir fait. Du coup c'est bon, plus de soucis ?  
A noter que je trouve le site avec une bonne URL dans Google, mais est ce que le mode "caché" reste handicapant ?

je pense que tu cherches ceci : https://wordpress.com/support/domai [...] ve-method/

Non même pas, c'est un truc maison, encore pire...

On m'a demandé un chiffrage pour reprendre le site (ci-dessus, posts de mai) : comme c'est vraiment le bazar dans le code, je me suis fendu d'un mail expliquant qu'il fallait tout brûler et repartir de 0 (à peu de choses près ), que le mélange de la logique, du SQL, du PHP, de l'HTML et du CSS en même temps, c'était pas vraiment une bonne idée, surtout en 2024.
Et que surtout, le site est une vraie passoire, n'importe qui peut être administrateur
Bref, j'ai demandé un point Team cet après-midi, mais visiblement le webmaster (et créateur actuel) est vexé de mes remarques :

Je crois rêver mais non, on a bien affaire à Jean-Michel, boomer apparent

Je pense voir à peut près le profil technique du mec. Je dois avouer qu'en ce qui concerne le dév d'applis web, j'aurais tendance à le rejoindre sur le gaspillage des ressources informatiques. Il y a qq années, j'avais confié le dév de petites évols sur une appli web que j'ai créée en 2003 (c'est pas tout jeune ) à une stagiaire (bac+5). Parmi les évols, améliorer l'IHM et notamment ajouter des icônes/images, gérer des listes à sélection multiple comportant beaucoup beaucoup de valeurs... Ma logique était d'être le moins dépendant possible de framework et autres libs. Bien m'en a pris car entre 2003 et aujourd'hui, beaucoup de libs et framework de l'époque n'existent plus.  
Pourtant, j'ai eu aucun pb à faire évoluer cette appli et passer de PHP4 et MySQL3 (qui gérait même pas les sous-requêtes!) à du PHP8 et du MySQL7. Poids de l'appli : environ 15 Mo.
2j après le début du stage, la stagiaire m'avait rajouté tout un tas de libs en CDN, le tout représentant plusieurs Mo, pour faire des trucs qui se font facilement avec les fonctions de base du JS : boostrap, JQuery, Font Awesome... Donc, plusieurs Mo ajouté pour coder des trucs qui se faisaient en quelques Ko de code JS. En plus, ça rendait l'appli plus utilisable sans être connectée à Internet. Or, pour certaines clients, mon applis devrait pouvoir s'utiliser en LAN, sans internet.
 
Voir un tel gaspillage m'a navré. Du coup, je comprends la réaction de ton gars. Et des applis web bien "grasses", pas optimisées pour 2 sous, qui pourraient largement consommer moins de bande-passante, de HDD, de mémoire... sans que ça soit très compliquer à faire, je trouve ça bien dommage.
 
Au passage, la notion de développement écologique est en train d'émerger. Il existe même des outils pour mesurer ça. Tu ne devrais donc pas balayer d'un revers de main ses propos. Je pense que certains sont justifiés. C'est pas parce qu'aujourd'hui la ressource informatique coûte pas chère (je pense à la mémoire et stockage) qu'il faut coder comme un goret et gaspiller.

 
Oh putain...      
 
 

Magnifique  

Imagine tu passes le tout en Rust et tu descends a 10mo en ram pour 10k connections    
 

 
C'est pour éviter de gaspiller des lignes de code pour le bilan carbone de Jancovici et permettre a Deep Blue de dominer le secteur bancaire en jouant aux échecs.

J'aurais pas pensé à Rust pour faire une appli web mais une recherche sur le web montre que c'est possible. Après, est-ce que c'est optimisé, je ne sais pas. On pouvait bien faire des applis web en C ou C++, alors en Rust, pourquoi pas...

Et du coup, ça fait 30 ans que tu es ingénieux ?

Le message est moche, mais il ne soulève pas que des mauvais points. Le dev web (le ML est dans la meme situation), c'est pas toujours le truc le plus efficace (on a mis le curseur tellement loin sur le fait d'"aller vite" que faut pas trop regarder comment ça tient dessous).
 
DHH (je j'affectionne pas plus que ça) a un point intéressant dans une de ses interviews, il demande si on développe un site, combien de temps avant que tu ne puisses plus le recontruire depuis son code, parce que le tooling est monté de 3 versions qui sont plus du tout compatible, ou les libs principales ont trop évolué, ou son morte, où ont été tuées par des dépendances critiques qui ne sont plus maintenues... et c'est pas idiot comme question

Ingénieux, je ne sais pas   Mais en tout cas, avant d'inclure une lib dans un projet, je m'interroge sur sa pertinence et si j'aurais pas meilleur compte de coder moi-même la partie de la lib dont j'ai besoin (souvent, on a besoin que d'une petite partie d'une lib qui fait pleins de choses). 20 ans après, je ne regrette pas cette ligne de conduite. Y'a d'autres trucs que j'aurais fait différemment, mais ça, ça m'a bien aidé dans la maintenance. Aujourd'hui, on est en PHP8 et mon appli fonctionne toujours sans pb 20 ans après Récemment, j'ai même réussi à me séparer de 2 libs JS très anciennes et plus maintenues (l'une étant un ancêtre de JQuery).
On parle quand même d'une appli qui, à ses débuts, devait fonctionner avec Netscape 4.8 et IE 5.5  
 
Après, on est d'accord que le gars s'exprime d'une manière maladroite dans son message et que les arguments qu'il avancent ne justifient pas le codage d'une site avec tout mélangé. Mais comme je le faisais remarquer, tout n'est pas à balancer, l'aspect gaspillage des ressources informatiques est un sujet à vraiment prendre en compte par les dév d'aujourd'hui. De vieux dév de démo maker des années 80-90 pourraient donner qq leçons de codage et d'optimisation aux dévs actuels

Mouais. J'ai autant (voire moins) rencontré de gens qui "gaspillent" les ressources (libs inutiles, qui deviennent effectivement des pb de maintenance) que de gens qui pensent faire mieux que des libs existantes, et se retrouvent avec des sous-performances + bugs.
 
En écoutant certains, il faudrait rester avec du vanillaJS. Sauf que perso faire des applis à plusieurs personnes sur des sites modernes (= designés par graphiste + UX), à plusieurs personnes avec des timings serrés, je ne m'engage pas sans un framework moderne (vue / react + lib de composants pour le tout venant). D'autant que la taille est rarement un souci avec un cache navigateur bien géré, passée la première visite / update tu n'as globalement que du json compressé qui circule.
 
A mon sens si tu veux vraiment optimiser de manière significative, c'est côté backend que ça se joue, et même là c'est limité : avec les systèmes d'async, mes serveurs se touchent suffisamment la nouille pour qu'un seul vCPU gère > 1000 requêtes. Je suis en pratique quasi systématiquement limité par la DB.

 
Il faut de nos jours avoir un sacré melon pour penser que les libs qu'on va coder seront meilleures que des lib existantes utilisées et testées par des milliers, et parfois bien plus, d'utilisateurs. Je pense que tu confonds deux trucs totalement différents.
Faire des demo sur des proco en assembleur pour faire un concours de bite artistique, ce que je respecte profondément par ailleurs, n'a rien à voir avec le fait de délivrer au client un site vraiment sécurisé, performant et facile à maintenir.
 
Les solutions complètes pour des end users sur le web que tu codes de A à Z, y compris les librairies, le seul intérêt, c'est dans le cadre d'un apprentissage... Et encore... Sinon, c'est quasi toujours une erreur.

Après ça dépend le besoin non ? Si le site est principalement statique et qu'il faut juste faire un toggle visible / non visible sur 2 éléments du site, c'est peut être pas la peine d'embarquer du Vue/React et toute la chaîne de build a base de Webpack (ou son n-ieme successeur) qui va avec ?
 
Après s'il s'agit de dev une appli métier qui sera utilisée dans un contexte avec de l'i18n, gestion des fuseaux horaires et sync offline/online, je ne pense pas que re-inventer la roue soit la bonne solution ici...

FWIW Vue je sais pas mais React je pense que tu peux toujours l'utiliser sans outillage en ajoutant juste la lib et en faisant du JS "pur". Après si t'es à une échelle où ça a du sens tu voudras probablement utiliser un truc plus léger pour faire ça (et clairement ça a pas de sens pour un simple details).

C'est marrant j'ai un peu la vue inverse, le métier est souvent là où les libs "standard" pêchent parce-que ton use case ou tes contraintes diffèrent juste assez pour que ça foute la merde, ou bien c'est fait par des ricains qui oublient la moitié du problème

Il y a encore des clients pour du site statique ?

De memoire tu peux aussi juste loader le .js de Vue directement en effet, mais bon, encore une fois si c'est juste pour faire un "display:none" sur deux div ca me parait un peu overkill

Oui en fait je parlais spécifiquement des libs pour gérer l'i18n/les timezones ou calendrier par exemple qui sont quand même des trucs pas si simple a faire proprement (pour l'i18n la méthode "simple" a coup juste de remplacement de string basique montre vite ses limites ). Après pour les trucs vraiment métier spécifique au domaine la vaut probablement mieux faire son truc (sans compter que bon, si ton truc metier est deja dispo via une lib plus and play, c'est quoi la plus value de ton propre produit ? )

Me suis mal exprime, je voulais parler de site générés principalement cote backend avec du templating cote serveur. C’était statique au sens "pas ou très peu d'interaction cote navigateur".
Et bon, des sites en mode SPA qui gagneraient aujourd'hui a revenir a ce type de tech, je pense que y en a pas mal

Les timezones sont justement des endroits qui m'ont pas bien impressionnée, surtout en JS. Après ça fait longtemps que j'y ai pas touché donc ça s'est peut être amélioré.

Ah oui peut être, ça fait aussi longtemps que j'ai pas fait de front
Mais bon, j'aurai pu trouver d'autres exemples, genre si je devais faire un truc avec de la visualisation complexe cote front, je ne pense pas que ce soit super efficient de se dev son d3js in house... (ou en tous cas de la mémoire du truc que j'ai, ie un truc avec des primitives assez bas niveau, pas un full moteur de graphiques ou un moteur 3D plug-n-play par exemple).

J'ai jamais dit que la lib sera meilleure Je parle du cas où tu utilises une toute petite partie de la lib, du genre $('id') alors que tu peux faire un document.getElementById('id'). Où juste faire une autocompletion.
On est bien d'accord que si le site a besoin d'utiliser plusieurs composants ou fonctions évoluées, une lib OK. Surtout si tu es exposé sur le web (vs les outils métier web qui sont juste sur un LAN).

Pour la 3d y'a ThreeJS qui est pas mal
https://threejs.org/
Un site par exemple https://www.igloo.inc/

Bof. Avec le tree shaking (dans vite par exemple), si tu n'importes pas comme un goret seule la portion en question sera rajoutée à ton build.

 
vu de loin l'écosystème web a l'air de changer tous les 3 mois, et le point de DHH et SekYo plus haut sur le fait qu'une app batie sur ces écosystèmes "modernes" ne tournera jamais dans 5 ans parce que la moitié de ce dont tu as besoin n'existera plus, mérite considération.
On peut aussi parler des chaines de CI en truc qui gachent des ressources à foison (je juge pas, je bosse dans le ML est on est pareil, on recalcule des features ce qui force les modèles à reclassifier notre contenu régulièrement, et vu la taille du bordel,, on y passe des datacenters entiers )
 
le truc que je vois surtout c'est que plus ton truc est complexe (au sens nombre distinct de "blocs de constructions" ) moins il y a de personnes capables de "raisonner" sur l'ensemble du système, parce que tu ne peux vraiment être spécialiste que d'une sous-partie. Et ça c'est terrifiant parce que des trucs qui sont logiques vus "bloc par bloc" peuvent s'avérer très cons une fois que tu as la vue d'ensemble. J'ai eu le cas récemment dans mon équipe, on analyse un problème...on analyse...tout est bon de notre coté et les résultats sont dégueulasses. on comprend pas pourquoi... Finalement quelqu'un regarde la configuration de l'autre équipe : ils n'utilisaient pas notre label . Et ça faisait des mois que c'était le cas et personne ne l'avait vu parce qu'on peut pas avoir de monitoring pour savoir si une règle "devrait exister mais n'existe pas".
Bref, il y a une valeur à la simplicité.

 
A part si ton site sort 3 pages, le besoin pour du vue/react est quand meme franchement la. Perso j'essaye avec mes équipes de forcer a rester au maximum sur la base, je ne veux pas voir des pelles de frameworks se pointer.
 
Mais le fait est, que le temps de dev la moindre feature un peu sympa visuellement fait que le package.json fini toujours en lampadaire qui brille dans la nuit. C'est ca, ou alors ca coute au projet des mois si ce n'est plus de dev. Apres j'ai l'impression que les projets que tu dev restent assez peu gros, nous on a une base de plus de 100 pages, avec jquery je suis meme pas sur que le projet est une chance d'exister en fait sans etre un ramassi de n'importe quoi.
 
Et c'est aussi a toi, de parfois dire "c'est fini, ca marche, mais je refuse, car t'a 4 libs et tu pourrais te passer de 2, ou alors etre un peu moins bete et reutiliser celle la qu'on a deja dans le projet".
 
 
Apres, toutes mes equipes sont convaincues du one-page, et perso j'ai toujours trouvé ca passable. Ca introduit plein de problemes évitables sans rien faire, le fait de mixer des fonctionnalités dynamiques avec des pages qui refreshent donnent globalement le meme résultat au client. Et au moins t'a une séparation faite par le navigateur qui clean quand meme bcp de trucs pour toi.
 
 

 
Completement d'accord, le backend a bcp moins ce soucis de sans arret tout changer. Les technos sont plus stables dans l'ensemble...

Je ne peux pas prédire l'avenir mais quand j'ai commencé à dév mon appli métier (environ 200 000 lignes de code avec les plugins) en 2003, si j'étais parti sur les framework de l'époque, j'aurais été bien dans le caca aujourd'hui, plus aucun existant Pareil pour les libs JS. Du coup, dans 10 ans, est-ce qu'on aura toujours les framework actuels ? Des trucs comme Angular, React ou Vue ou autre, j'en ai vu passer en 20 ans. C'est régulièrement remplacé par une nouvelle lib à la mode. Etant seul à développer et le portage d'une appli d'un framework à un autre étant lourd, je peux peut pas m'amuser à suivre le framework à la mode tous les 5 ans Tu as raison, je développe des applis dans un cadre bien spécifique : peu d'utilisateurs (au max 100), applis sur un LAN ou réseau WAN d'entreprise, un nb faible de pages différentes (environ 100 écrans différents).
 
Par contre, je fait attention à l'accessibilité de mes applis en particulier aux personnes déficientes visuels. La tendance actuelle au one-page est une catastrophe pour ce type de personne, leur lecteur d'écran ne détectant en général pas les zones où le contenu a été mis à jour. Raison pour laquelle je suis resté sur un écran = une url. Ca permet aussi de rendre l'appli web beaucoup plus facilement scriptable
 
Bref, j'essaye de trouver l'archi technique la plus simple et la plus facilement maintenable dans le temps vu que mes clients veulent bien payer pour de nouvelles fonctions mais pas trop pour juste faire un changement de lib/framework. Avec ma façon de faire, j'ai pas trop mal réussi ces 20 premières années en traversant 4 versions majeurs de PHP sans avoir à reprendre trop de code (moins de 100 lignes sur 200 000 pour passer de PHP5 à PHP8)