paniers et commandes

Notez que le bouton «  commander  » n’est visible que si le visiteur est devenu un auteur .
Un clic sur ce bouton provoque donc la transformation du panier en commande (c’est là qu’interviennent les bouts de code de Commandes de paniers). A cet instant, le panier est vidé, une commande est créée, commande que l’on aura le plaisir de trouver dans l’espace privé (Édition > Commandes).

Si vous avez installé Notifications avancées, la création de la commande (et les changements de statuts que vous opérerez dans le back-office) déclencheront l’envoi d’un email (tout cela est à configurer dans le plugin Commandes).

Ce code provoque la transformation du panier en commande (c’est là qu’interviennent les bouts de code de Commandes de paniers). A cet instant, le panier est vidé, une commande est créée.
Commande que l’on trouve dans l’espace privé (Édition > Commandes).

Étape 6
Page de remerciement

-* - Ma dernière page commande_terminée comporte un message de remerciement et la liste des commandes associées à l’auteur connecté :

      <B_traitement>
     <h2 class="gris"><:commande_merci:></h2>
      <p><:explication_fin_commande:></p>
      <h2 align="center"><:commande_recapitulatif:>
        
      #ANCRE_PAGINATION
      <BOUCLE_traitement(COMMANDES){id_auteur=#SESSION{id_auteur}}{statut?}{tout}{par date} {inverse}{pagination 5}>


<p><:commande_numero:>#REFERENCE</p>
      <p><:commande_date:> : #DATE</p>
      <p><:modifier_commande_statut:> [<span class="bleu">(#STATUT|commandes_lister_statuts)</span>]</p>
      
      <p><:details_commande:></p>
      <INCLURE{fond=inclure/commande,id_commande=#ID_COMMANDE,statut=#STATUT}>


</BOUCLE_traitement>
      [<p class="pagination">(#PAGINATION)</p>]
      </B_traitement>
      
      <p>message d'erreur</p>
            
      <//B_traitement>

La boucle interroge désormais la table spip_commandes Commandes et la table auxiliaire spip_commandes_details récapitule les articles qui s’y trouvent .

Mon expérience s’arrête là, pas de paiement donc, mais cette étape serait sans doute à intercaler entre la page de validation et la page de remerciement.

--------------

(de Tcharlss, le 6 mai 2014)

Depuis peu, Commandes prend en charge ces types « facturation » et « livraison ». Enfin, prendre en charge est un grand mot : il complète la liste des types proposés par la saisie #SAISIE{type_adresse}, qui est utilisée dans le formulaire d’édition d’une adresse, voilà tout.

Alors pour cette histoire de #TYPE sur les coordonnées, je crois que tu voulais des clarifications dans ton message précédent.
Le type sert à qualifier le lien entre une adresse un objet, et non pas l’adresse elle même. Là est la subtilité, il ne sert pas à dire : ceci est une adresse de type « livraison », mais : cette adresse est liée à cet objet en tant qu’adresse de type « livraison ». Autrement dit, le champ ’type’ n’est pas dans la table ’spip_adresses’, mais dans ’spip_adresses_liens’.
Tout l’intérêt, c’est qu’une même adresse peut être liée plusieurs fois à un objet grâce à ce champ ’type’. Par défaut, les tables de liens sont dépourvues de ce champ, ce qui fait qu’un objet ne peut-être lié à un autre objet qu’une seule fois : on ne peut par exemple associer un auteur à un article qu’une seule fois, tandis qu’on peut associer une adresse à un article plusieurs fois avec des types différents. (note : c’est aussi l’enjeu du plugin « rôles » de M.Marcillaud. Sauf qu’il parle de « rôle » au lieu de « type ».)

Si par exemple tu as un formulaire d’inscription perso, dans lequel tu veux proposer la saisie d’une adresse de livraison, tu peux faire comme ça :

-  Dans le squelette du formulaire, les champs de l’adresse doivent être nommés comme ceux du formulaire d’édition normal d’une adresse : ’voie’, ’complement’ etc.
Tu peux ne mettre que ceux qui t’intéressent d’ailleurs, c’est l’intérêt.

-  Dans les fonctions charger, verifier et traiter du formulaire, ’charger_fonction’ permet de réutiliser les fonctions de n’importe quel autre formulaire.
Par exemple, dans la fonction traiter, si tu rajoutes ceci en plus de tes traitements persos :

$associer_objet = "auteur|$id_auteur";
set_request('type','livraison');
// traitements du formulaire classique des adresses
$traiter_adresses_dist = charger_fonction('traiter', 'formulaires/editer_adresse');
$res = $traiter_adresses_dist('new',$retour,$associer_objet);

Hop, l’adresse va être créée et associée à l’auteur x, avec le type ’livraison’. Pour récupérer l’identifiant : $id_adresse = $res['id_adresse'];

Autrement, pour lier ponctuellement une adresse existante avec une commande par exemple :

include_spip('action/editer_liens');
objet_associer(array('adresse'=>$id_adresse), array('commande'=>$id_commande), array('type'=>'livraison'));

Mais attention ! Si jamais tu as besoin de lier 2 fois une même adresse à une commande, l’API a une limitation : elle est actuellement conçue pour faire un unique lien d’objet à objet. Donc en faisant comme suit, le 2^e lien va écraser le premier (à moins d’avoir le plugin ’rôle’ installé) :

objet_associer(array('adresse'=>$id_adresse), array('commande'=>$id_commande), array('type'=>'livraison'));
objet_associer(array('adresse'=>$id_adresse), array('commande'=>$id_commande), array('type'=>'facturation'));

Dans ce cas là, il faut faire les liens « à la main » :

sql_insertq( 'spip_adresses_liens', array(
                'id_adresse' => $id_adresse,
                'objet' => 'commande',
                'id_objet' => $id_commande,
                'type' => 'livraison'
                )
            );
// idem pour facturation