La version 2.1.1 est maintenant en cours de developement, et certaine restructuration von avoir lieu.
osCSS 2.1.0 avait pour but la mise en oeuvre avec une refonte fondamentale du code, et la conservation d’un reto-compatibilité avec les version anterieur. (Lire la suite…)
L’utiliLors de la mise en oeuvre d’une boutique, j’ai eu besoin d’ajouter des contenus non prévus (de base produits, categories, client, et page cms) , mais dont certaine devait elle même permettre d’être modulaire avec des extensions specifiques. (Lire la suite…)
Les modules de page tendent à évoluer, et une nouvelle forme de module voit le jour ;
Ces modules de pages, sont les plus complexes (vis à vis des autre type de modules, account, products, ..), compte tenu que ceux sont des page centralisatrice, contenant listing, tri action multiple, export, et j’en passe.
Aussi , afin de simplifier leur mise en forme, une nouvelle class et un nouvel viennent compléter ces modules.
Un petit mot, sur les élement ,ecessaire au bon foncitonnement des modules dans leur prise en charge dans le processus de commande, et au texte affiché dans les différente etape et sur les pdf produit.
Chaque module , lors du choix de la methode de livraison fournis un tableau deomposé comme suit:
array(
id => $this->code
module=> nom affiché du module
methode=>array(
tax=> valeur de taxe
title=> text qui sera affiché , dans le choix de la livraison, et aussi utilisé dans les tottaux de commande, dans les pdf, etc.. (eviter les caratére speciaux comme l'€ )
detail=> text complemetaire uniquement affiché lors du choix de la methode
cost=> le cout a ajouter au total commande
cost_ht=> le cout HT a affiché
)
)
La section detail de la, ou des methode est optionnel
On peut dire, que celui ci m’a fait perdre du temps, quelque chose de bien !
Tous ca pour faire une installation plus propre, et en centralisant l’ensemble des fichier du module au même endroit.
Mais, pas possible, el module ne trouvais pas certain élément de configuration , pourtant installé et definis comme il ce doit ;
Et pas moyen de le faire fonctionner….
En fait, j’avais deporté l’ensemble des elements d’atos dans le repertoire du module de la boutique, mais le chemin vers les element de configuration de la partie sherlocks ne passait plus .
Et j’ai fini pas trouver , grace à ce memo http://www.filluzeau.com/333-solution-pour-lerreur-de-paiement-avec-sips-atos.html, la solution !
Donc , merci à Alexandre 
Si le chemin est trop long, ben , ca marche pas.
Donc, avec tout à la racine , pas de soucis !
Les templates du backoffice supporte maintenant la possibilité d’inclure un fichier de langue, en .txt .
cette evolution autorise donc a ajouter des contenu texte localisé dans le theme du backoffice.
d’autre part, ce fichier, comme les autre fichier de langues est mis en cache si celui est activé.
Pour ajouter un fichier de langue, utilisé la nomenclature habituelle.
Les fichiers de langue doivent être placé dans un repertoire languages/ , a la racine du template.
L’appel des contenu localisé utilise donc la fonction __()
Just link, for me
Fro protected website
Inject sql
http://niklosweb.free.fr/Tutoriaux/Hacking/Injections%20SQL%20et%20fichiers.html
global protected
http://php.developpez.com/faq/?page=securite
add htaccess
http://blog.galerie-cesar.com/proteger-son-site-avec-fichier-htaccess/
et voila, afin de rendre plus souple le fonctionnement sans avoir à intervenir sur le core, 2 nouvelles methodes sont apparu dans le driver.
Ces 2 methodes sont static et appelé directement a tarvers la class product.
Soit :
product::get_adjust_price()
et
product::get_option_data()
La methode get_adjust_price est utilisé dans le panier, pour prendre en charge la modification des prix d’un produit par les module de type Aca (type product)
il est absoluement necessaire de definir une var nommé price pour que cette methode soit active
ex:
//! flag price
$this->price = true;
Elle prend en arguement un tableau qui lui fournis le pris de base, l’id produit et la quantité
La methode get_option_data n’ a vocation à étre appelé , elle est gerer directement dans la function stament_query, qui permet la mise en forme de l’object produit retourné.
Les module utilisant cette methode permettent donc de recuperer dans l’object premier leur propre element.
Apercu de la definition d’un module ACA utilisant ces methodes
/**
Add data in driver.product
*/
public function get_option_data($product_array){
$product_array['price_break']=$this->load_db_values($product_array['products_id']);
return $product_array;
}/**
fonction ajustement price en fonction quantité
*/
public function adjust_price($product_array){
$pid = tep_get_prid($product_array['products_id']);
$res=product::get_item($pid);if(count($res->price_break)>0){
foreach($res->price_break as $qt=>$pr)
if($product_array['products_quantity']>=$qt)$result=$pr;
}return (isset($result)?$result : $product_array['products_price']);
}
la gestion des paiements, avec leur lots de différence entre les mode bancaire, et le fait de quitter la shop, pour y revenir ensuite, posent quelques question, quant à la transmission des information, et l’enregistrement des commandes.
L’osCSS 2 contient sur ce sujet 2 series de tables jummelle , les orders et les holding_orders.
Les holding order servaient a présent uniquement a recupérer les commande « perdu » ou non validés.
L’evolution qui devrait apparaitre, va changer quelques peu la procedure des enregistrement des orders.
La table orders, reste donc la table des comment dûment validé et confirmé, et les tables holding_orders, passe donc, de leur usage de commande perdues à un usage de pre-commande.
Cette transition permettra donc, de pre-enregsitré toutes les commandes, avant affichage et ainsi generé un numero unique de reference pour cette commande.
Ce numero pourra donc facielment être transmis au different module bancaire, comme Id unique, et utilisé lors des retour bancaire comme reference.
Dans le cas d’une confimation bancaire, arrivant sur la shop, avant le retour du client sur la page checkout, la page response du module prendra donc en charge la convertion des table holding_orders, vers order; et aussi la prise en charge de l’update du status en fonction de la reponse.
Dans le cas ou le client revient sur la boutique via la page process, c’est cette derbière qui prendra en charge la bascule de holding vers orders.
La page response dans ce cas ne prendra en charge que l’update du status.
Concretement, ces modification vont ce traduire par:
…
il n’y a pus qu’a.