Reprise du message précédent :
Donc de votre côté vous passez directement les var du type $_POST['nom'], $_POST['adresse'], $_POST['commentaire'], ... aux "prepared statements" d'une requête SQL ?

Yes, avec éventuellement un trim histoire de vérifier les espaces superflus.

Je t'invite à te renseigner sur le concept d'injection de dépendance.

 
Je ne vois pas le rapport.
 
Là typiquement j'ai un formulaire compliqué mais qui ne sert qu'une fois dans l'appli (genre de panneau de config on va dire), avec une centaine de champs de tout type (case à cocher, dates, noms, texte libre, même un champ avec un ckeditor donc du html...), je cherche juste le moyen 'minimum' le plus propre et efficace pour faire un bête update de tout ça en bdd, j'ai pas d'objet, juste du bon vieux procédural.
 
Après je veux bien comprendre que si on passe par des objets, on ne balance pas les variables $_POST[] à l'intérieur de l'objet...
 
Bon donc en gros là ça me donne qqch du genre :
 
HTML :

PHP

éventuellement pour certains champs je rajoute des is_numeric() ou !='' dans le if selon les attentes. Je suis en train de me construire une petite fonction de tests genre verif($chaine,"H:i" ) ou verif($chaine,"numerique_ou_vide" ) ou ce genre de chose, qui retourne 0/1 en fonction de tests du type est-ce que la chaine ressemble à "17:32" ou pas, histoire de ne pas stocker "toto" dans un champ où je suis censé avoir une heure... et ne pas réécrire 10 000 fois les mêmes tests ou regex.
 
et après ma requête :

 
Ca vous parait ok ?
J'aimerai bien simplifier au max le code de "test" pour chaque champ, genre encapsulter la gestion d'erreur, vous avez des suggestions ? Il y a quand même un paquet de cas en dehors des simples "emails,numérique..."
genre  
- n'autoriser qu'une valeur parmi une liste (par ex, une var qui peut contenir 0 1 2 ou 3 mais rien d'autre)
- un seuil mini et maxi (ou un seul des 2)
- toutes une tripotée de formats de dates/heures
- de champs vides ou non
- une longueur de chaîne stricte
...
 
Ca serait bien également de pouvoir "préparer le travail" pour les $stmt->bindParam() par la suite histoire de ne pas avoir à se les retaper tous manuellement.

Bon je poursuis, mode gros cracra mais ça marche...
 
Quelques fonctions  

 
Du coup dans mes formulaires ça donne des trucs comme :
 

Ces champs précis ne servent qu'une fois dans l'appli. Mais dans l'appli j'ai pas mal de formulaires avec des saisies utilisateur (c'est une appli de gestion d'un type d'activité pro, ou le professionnel saisit des infos sur ses clients, ses rendez-vous avec eux, ...). Donc dans l'ensemble de l'appli je dois avoir une vingtaine de formulaires portant sur probablement 200 ou 300 champs d'où ma recherche de quelque chose avec le minimum de répétition de code.
 
 
Sympa GUMP, un peu verbeux mais j'aime bien l'approche.
En effet l'idée de passer plusieurs champs d'un coup + des paramètres plus ou moins présents via une seule chaîne c'est pratique.
C'est ce que je n'aime pas trop sinon quand on commence à faire des fonctions un peu fourre-tout qui peuvent prendre ou non tout un tas de paramètres, à la fin on risque une confusion maxi. Genre :
$valide = teste("prénom","chaine",0,1,255) ;
alors 0 c'est pour "required" ou "longueur mini" ? et on passe quoi à ces paramètres quand on veut tester un entier ?
 
Bon par contre parser ce genre de chaine ça sent bien la galère... quand je vois le code de GUMP... autant en effet réutiliser cette lib
 
Ce qui me surprend c'est que j'ai l'impression de défricher un domaine ou poser des questions compliquées alors que c'est la base même de toute appli ou même site web depuis des décennies...

 
Cela dit, je trouve que c'est utile de réinventer la roue quand tu débutes, pour mieux comprendre les choses.
Combien de personnes utilisent des framework sans même comprendre comment tout est imbriqué, les middleware, etc ?

 
ouais c'est ce queje disais (ou voulais dire maladroitement) : c'est ça que j'aime bien car sinon pour faire évoluer la fonction et la conserver lisible c'est la misère.
Genre là je me rends compte que mes "chaine_ou_vide" j'aurai mieux fait d'avoir un paramètre (facultatif) de longueur mini (et si c'est 0 c'est que le vide est accepté), mais pour modifier la fonction je suis un peu mal barré
J'apprends tous les jours...

Ça ressemble beaucoup au système de validation du framework laravel, c'est super lisible et bien fonctionnel

 

 
...mais plus personne ne lit ce topic en fait?
 
Si tu veux passer tes critères de validation dans un seul paramètre tu fais un tableau, pas une immonde chaine de caractères à explode ensuite pour en faire quelquechose...
 

$options = [
 'required'=>true,
 'type'=>'string',
 'minLength'=>1,
 'maxLength'=>255
];
$valide=teste("prenom", $options);

Tu définies des patterns de base pour les données redondantes, sinon tu passes directement ton pattern à la fonction pour les données uniques.
Dans la fonction tu fais un preg_match sur ton pattern pour les datatype string, pour les nombres tu split un pattern avec min et max et ça devrait rouler.

Complètement à coté de la plaque...ma réponse concerne la pratique de passer des données structurées dans une chaine de caractères, pas spécifiquement la solution adaptée à la question d'origine.
Les données dont tu as besoin SONT un tableau associatif. Ton langage propose cette structure de données nativement.
La compacité d'écriture du code n'excuse en aucun cas l'utilisation d'une structure de données inadaptée...j'ose même pas imaginer ta réaction si j'avais proposé une  solution avec un objet dédié plutôt qu'un simple tableau...
Je ne vais pas batailler plus loin, je perdrais manifestement mon temps...mais ce n'est même pas du PHP, là, c'est de la simple conception logicielle de base niveau 1ère année...

Alors pour ma part je dis juste merci C'est d'une telle évidence que j'avais zappé.
C'est souvent le problème quand on développe, on est tellement la tête dans le guidon qu'on passe à côté des choses les plus basiques.
J'ai souvenir par exemple d'avoir moitié réinventé une méthode de chiffrement pour stocker des données de manière sécurisée en bdd... avant de retrouver que mysql proposait des méthodes aes_encrypt et decrypt !

Pour revenir à ma fonction, entre temps j'ai juste amélioré en définissant type + longueur mini + longueur maxi et avec ces 3 paramètres je m'en sors (pour l'instant) a tous les coups. Mais avec un tableau d'options ça aurait été plus évolutif.

Au passage : https://www.php.net/manual/fr/function.extract.php

 
Pourquoi passer 2 paramètres, quand on peut en passer qu'un ?  

 
Pourquoi pas réécrire tout php comme ca d'ailleurs tellement c'est une idée qu'elle est bonne :

deviendrait :  

 
Bref c'est pas parce que ta lib github préférée du moment pense avoir eu une bonne idée qu'elle l'est

Nouvelle question...
 
J'ai une application web, qu'on va dire dédiée pour des électriciens. Il y a une partie promotionnelle (site web) et une partie d'accès restreint.
 
Aujourd'hui je veux décliner cette application pour (on va dire aussi) les plombiers. On peut imaginer que 90% du code va être le même, les différences vont être dans le css, le blabla marketing pour le site et la suppression de pas mal de champs et morceaux de l'appli non pertinents pour les plombiers et ajout pour eux de champs dédiés à leur profession.
 
Vous feriez comment ?
 
Actuellement j'ai tout dans 1 dépot git, ça prendrait 15 secondes à cloner et de partir du code de l'appli 1 à un instant donné pour développer l'appli2... mais du coup ça dédouble une grosse partie de code qui pourrait être commune... ça me semble être une très mauvaise idée pour la maintenance à long terme (correction de bug en double, développement de features en double...)
 
Du coup le plus logique reste de mutualiser le code autant que possible et de partir dans des fichiers de config différents, des switchs dans le code, éventuellement des objets (mais j'en ai très peu) "électricien extends professionnel" et plombier extends professionnel", des includes de fichiers dont le nom est basé sur une variable qui contient électricien ou plombier...
 
Vous avez des conseils pour ce genre de chose ? Genre actuellement mon fichier de config est inclus dans le git, donc quand je fais un pull pour mettre à jour mon serveur de prod, ça inclue le fichier de config aussi (et dedans il y a un test pour "détecter" si on est en dev ou en prod (chemin des fichiers, ip...). Ca va un peu se compliquer si le fichier de config intègre électricien et plombier.
 
Même chose en terme de bdd... je peux faire une bdd électricien et une bdd plombier, mais dedans 90% des tables et colonnes seraient communes... c'est probablement plus pertinent de conserver une seule bdd...  
 
Bref je suis preneur de tout conseil et retour d'expérience sur le sujet...

Difficile de répondre précisément sur une question si vaste, mais oui, typiquement ça ressemble à une appli unique dont tu actives/désactives simplement des fonctionnalités en fonction des besoins du client au déploiement.

Pour moi dans ce style de cas c'est une seule appli, un seul dépot git, et pas de fichier de conf "réel" dans le dépot, seulement un squelette. Ca implique de revoir pas mal ton process de déploiement par contre, j'imagine.

Ensuite concrètement coté modélisation il faut voir comment tu définis les fonctionnalités à activer/désactiver en fonction des clients (classification de tes clients par types et association d'un set de fonctionnalités à chaque type? Gestion individuelle par client, fonctionnalité par fonctionnalité? Il n'y a que toi qui peux vraiment répondre sur ce qui est adapté à ta situation...), et où tu stockes ça (fichier(s) de conf, paramétrage coté base de données? Typiquement chez nous c'est une/des table(s) de paramétrage dans la base pour les gros trucs, directement dans un fichier de conf pour les petits devs rapides).

 
Éventuellement pour la config, je peux faire un truc basique du genre un test de "dans quel dossier se trouve le fichier de conf" :  

ou un switch sur une partie du document_root pour anticiper le jour où j'intègrerai les maçons ou autre
 
Et ensuite baser mes tests sur le contenu de $app...
 
Ca suppose de faire un pull par "site", donc en gros j'aurai le même code dans /home/electricien et /home/plombier ... peut-être un peu idiot ? Sinon tout dans le même mais avec un test sur l'hôte (www.electricien.com vs www.plombier.com)
 
 
Après oui ça va être des fonctions à activer ou non. Dans un premier temps c'est surtout en désactiver un paquet qui ne sont pas pertinentes pour la seconde profession par rapport à ce qu'il y a déjà. Il y aura aussi probablement pas mal de textes à adapter.
Le truc dont j'ai un peu peur c'est de créer un monstre d'imbrications de if(profession1) then... else... mais des fois c'est commun, mais des fois pas... et aussi d'avoir des requêtes sql un peu étranges.
Typiquement un formulaire de saisie qui peut avoir 10 champs pour la profession 1, 4 pour la profession 2, mais seulement 3 de commun... donc les vérifications d'existence de valeur puis d'insertion/maj en bdd ça risque un peut d'être le bazar.

 
Tu déploies tout sur le même serveur derrière?
Jadis j'avais un truc du genre - une install unique avec la conf commune, et le nom de domaine servait à déterminer dans quels dossiers aller chercher la conf et les templates spécifiques. Ca évitait de dupliquer le code et de multiplier les opérations à chaque MAJ, l'inconvénient c'est que si tu as besoin un jour de désynchroniser les instances c'est le merdier.
 

 
Si tu découpes proprement le code tu peux limiter pas mal tes besoins de if(professiontruc)...Un exemple simpliste : avoir simplement des templates par profession pour chaque page. Tu pourrais ainsi par exemple avoir pour tes formulaires une version complète comprenant tous les champs pour celle qui a besoin de tout, et des champs hidden avec des valeurs par défaut sur le template pour la deuxième profession qui veut pas tout voir. Ca te permet de conserver toute la logique commune derrière et de personnaliser à peu de frais...

Bonjour, une idée du pourquoi j'ai ²² qui apparait sur mage page? pas sur que ça soit un soucis de php mais bon  
 

C'est ce qu'on appelle un site fait en deux deux.

Ou alors du langage ternaire !

tage page on peut la voir quelque part (en message privé si tu veux pas la voir sur un forum public) pacque la sans   ça va être difficile de t'aider...
 
...ca peut être dans ton code, un problème d'encodage ou même du css ou du js.
 
Quand tu fait un clic droit dessus => inspecter l’élément; est que ça te donne une indice ?

C'est pas directement ma page, en faite c'est un serveur tuleap
 
donc c'est la même que celle la https://tuleap.net/
 
mais avec mon bug  

 
 
Après j'ai encore 2/3 autres bug php, donc c'est peut etre lié

Est ce que tu vois ces caractères dans le code source dans les environs de la fermeture de la balise </header> et l'ouverture du <div id="main-container"> ?
Tu as regardé sur les logs d'erreur de ton serveur, tu as vérifié quelle conditions minimal était requise pour l'installation ?
Tu suis ce tutoriel : https://docs.tuleap.org/install.html ?

 
J'ai suivi le tuto de maj, vu qu'il était déjà installé
 
Mais je pense que c'est la maj php 5.x vers 7.3 qui fout la merde

Dites, question de semi débutant ici. Je suis un cours du soir en dev web, langage php évidement. Pour un exercice le prof nous a demandé de faire une api REST. Jusque là ça va, je code mon api et en fonction de la méthode utilisée (POST, GET, etc), les fonctions appelées sont différentes, je teste tout ça avec un petit site qui appelle l’api avec $.ajax, fin de l’exercice.  
Cependant je me suis posé la question : comment faire pour sécuriser les donnés de l’api, si elle contient des donnés confidentielles ou si je ne veux pas que n’importe qui fasse un delete ou un post sur les données ? J’ai posé la question à mon prof, qui a répondu « faut utiliser hmac » sans plus de détails. Alors je suis partit en recherche sur internet, et je suis tombé sur plusieurs notions : hmac donc, mais aussi OAuth 2.0, basic auth, token bearer. Mais jamais un tuto complet sur comment créer une api sécurisée ni comment l’utiliser après dans mon site web...
 
Aussi ma question est : auriez vous un site anglais ou français qui pourrait m’aider à répondre à cette question? Je veux pour la pratique créer une api sécurisée from scratch, on verra après pour utiliser els frameworks.  
 
Merci

Bonjour tout le monde,
 
Je viens vers vous avec une petite question de débutant. J'aimerais savoir s'il est possible d'écrire ce genre de test en php :
 
if( $a = 5) { ... }
 
J'ai l'impression que ça ressemble à une transposition mathématique mais que ça ne marcherait pas. Je me trompe ?
 

Si tu fais ça ton if va toujours être validé car $a = 5 c'est une affectation de variable.
D'où cette écriture https://en.wikipedia.org/wiki/Yoda_conditions pour éviter ce type d'erreur.
Ou alors j'ai pas compris la question

 
Ah oui, en effet ! C'est totalement logique ! Merci pour ton retour !

 
+1
Bah dis donc, on a pas le cul sorti des ronces.. courage aux survivants qui essayent de montrer les bonnes pratiques !

Salut Départ,  
 
Je sais pas si c'est toujours d'actualité, mais j'ai aussi un site de plombier Luxembourg https://24h.lu, et j'aurai aimé avoir plus de détails sur ce que tu réalises comme application =)  
 

J'ai pris plombier et électricien comme exemple pour conserver une certaine discrétion sur la réalité de l'application. Désolé.

Bonsoir    
 
Petite question de débutant qui pourrait vous sembler évident.  
J’ai de nombreux scripts en bash qui exécute généralement une demande de saisie clavier puis lance des commandes dans un prompt ssh distant. Bref rien de compliqué.  
 
Je chercher à transmettre ces scripts à des non informaticien via une page web en utilisant du PHP.
Question : Est il possible d’intégrer un .sh dans une page web en faisant saisir en PHP/HTML une variable ?  
L’idée est de ne pas avoir à refaire tout le script en dev web mais juste la saisie clavier/cosmétique.
 
Merci

 
possible via exec()/shell_exec(). Après il faudrait éventuellement reprendre ton bash pour qu'il prenne les paramètres dans ses arguments au lieu de via des prompts.

Et attention sur les paramètres autorisés !
Parce que
exec("script.sh".$_POST['input1']) ;
Ça peut faire mal si quelqu'un met "toto ; rm / -R" ou quelque chose du genre dans input1

Je suis tombé sur (un bout de) la PR suivante :

protected function findPhoneFromListOfStores(array $stores, string $code): ?string
{
    foreach ($stores as $store) {
        $normalizedStore = [
            'code' => $store['poiId'] ?? '',
            'phone' => null,
        ];
 
        if (isset($store['contacts']) && !empty($store['contacts'])) {
            foreach ($store['contacts'] as $contact) {
                if (isset($contact['type'])) {
                    if ('PHONE' === $contact['type']) {
                        $normalizedStore['phone'] = $contact['value'];
                    }
                }
            }
        }
        $normalizedStore;
 
        if ($normalizedStore['code'] == $code) {
            return $normalizedStore['phone'];
        }
    }
 
    return null;
}

A partir de ça j'imagine la structure de donnée suivante :

$stores = [
    [
        'poiId' => 'id1',
        'contacts' => [
            ['type' => 'PHONE', 'value' => 'phoneNumber'],
            ['type' => 'EMAIL', 'value' => 'email'],
        ]
    ],
    [
        'poiId' => 'id2',
        'contacts' => [
            ['type' => 'PHONE', 'value' => 'phoneNumber2'],
            ['type' => 'EMAIL', 'value' => 'email2'],
        ]
    ]
];

Je voulais la réécrire de manière plus propre et plus lisible mais je ne trouve pas ça beaucoup mieux :

protected function findPhoneFromListOfStores(array $stores, string $code): ?string
{
    $store = array_filter($stores, function($store) {
        return $store['poiId'] == $code
    });
    
    $store = array_pop($store);
 
    if (!isset($store['contacts']) || empty($store['contacts'])) {
        return null;
    }
 
    $phone = array_filter($store['contacts'], function($contact) {
        return $contact['type'] == 'PHONE'
    });
    
    return array_pop($phone)['value'];
}

Vous avez mieux à proposer

2 foreach imbriqués me semblerait plus lisible
EDIT : ha bah c'est la première soluce, j'étais sur phone j'ai lu en travers

EDIT2 : genre

protected function findPhoneFromListOfStores(array $stores, string $code): ?string
{
    foreach ($stores as $store) {
        if ($store['poiId'] === $code) {
            if (isset($store['contacts']) && is_array($store['contacts'])) {
                foreach ($store['contacts'] as $contact) {
                    if (isset($contact['type'], $contact['value']) && $contact['type'] === 'PHONE') {
                        return $contact['value'];
                    }
                }
            }
            break; // Si pas de doublon 'poiId' possible
        }
    }
    return null;
}

Réécrire la structure de données.

A première vue je dirai pareil : ajouter poiId dans la structure de données. Si dans l'absolu le numéro de poiID n'a pas grande importance, ça peut aussi directement être la position dans un tableau (0,1,2...)
 
La notion de "type" est aussi discutable
tu peux simplifier en faisant directement un tableau associatif :  
"poiId" => "1", "phone" => "123456890", "email" => "toto@toto.com" ...
l'accès sera nettement plus pratique.