Articles avec le tag ‘oscss’

Support des langues dans les template backoffice

Mercredi 5 janvier 2011

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.

  • fr_FR.txt pour un fichier de langue française
  • en_Us pour fichier de langue anglaise.

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 __()

Blogué avec le Navigateur Flock

Ecommerce, website adn attack

Mercredi 1 décembre 2010

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/

driver.product la class de gestion des produit du front

Mercredi 27 octobre 2010

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']);
}

enregsirement des commandes / gestion des moduel de paiement

Mardi 26 octobre 2010

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:

  • Ajout d’un champs dans la table orders, qui conservera l’historique de l’id de la table holding l’ayany generé
  • Evolution de la class process pour prendre en charge les holding et les orders
  • Ajout d’un methode dans la class process pou rmigrer une pre-commande en commande, et suppression de la pre-commande


il n’y a pus qu’a. :)

plugins, cache et chemin fichier courant

Dimanche 19 septembre 2010

Il est souvent pratique, lors de l’appel de fichiers inclus d’utiliser un appel sous cette forme:

  $dir_ws_here=strchr(dirname(__FILE__),DIR_WS_TEMPLATES).’/';

Toutefois, les fichiers de plugin, sont mise en cache, de manières centralisé. aussi , le chemin du __FILE__ devient relatif.

Il est donc important de ne pas utiliser cette forme d’écriture dans les fichiers qui seront concaténer et mise en cache;

Pour reprendre l’exemple ci dessus,et pour definir le chemin vers le fichier en cours, il faut être plus precis, donc moins souple.

  $dir_ws_here=$page->getPathTemplate().’includes/plugins/generic/menu/’;

On precise ainsi le chemin vers le plugin menu, de type generic, dans le dossier du template courant.

Le dossier du template courat est obtenu grace à

$page->getPathTemplate()

Qui renverra /templates/genericLight/

osCSS 2 , template public , module ACA, simplification des appels vers le type courant

Dimanche 12 septembre 2010

Au sein des templates public, l’une des évolution majeur du moteur osCSS 2 , vient de l’utilisation des module de type ACA;

Ces modules , sont accessible, en appelant leur class mère, qui est nommé en fonction du type de contenu.

(Lire la suite…)

osCSS 2, module ACA , methode check_action

Dimanche 12 septembre 2010

Dans les modules de type ACA, les méthodes check_action assure l’exécution des enregistrement, update, etc..;
Elles permettent aussi d’influer, modifier et transformer l’action en elle même.

(Lire la suite…)

osCSS, fichier oscss.version.xml

Dimanche 22 août 2010

Ce fichier à déjà fait son apparition depuis quelques mois dans le common du moteur.

Jusqu’à présent, il servait uniquement à stocké le numéro de version et de révision svn du moteur.

Maintenant, , il dispose d’information completentaire ,

  • le template activé par defaut dans le backoffice
  • le niveau de developpement, stable | unstable
  • les url de liaison au svn pour le suivit des revisions

L’appel au information de l’object se font toujours via la fonction de la libraririe general.php

get_info_core(. DIR_WS_COMMON.’oscss.version.xml’,'svn’)

Le premier argument précise le nom du fichier, le second, le tag à retourner

Cette fonction doit être modifié, vérifier son fonctionnement avant usage.

osCSS 2 module de type pages vs configuration

Dimanche 22 août 2010

Le moteur ayant ajouté plusieurs type de modules, il n’est pas toujours évident de savoir ou ajouter une fonctionnalité. La nuance entres les modules de type configuration et ceux de type page peut être faible dans certaine situation.

Le module de gestion du cache  par exemple, doit il être un élément de configuration, ou un élément de gestion. Oui , la différence ce situe à ce niveau, quel est le but, ou l’objectif du module ajouté?
 Si elle concerne un élément de gestion ponctuelle, courante, il s’agit dans ce cas d’un éléement de type pages. Ces modules permettent de traiter du contenu du moteur, produits, catégories, menu etc.

Le cache quand à lui, n’est qu’un fonctionnement interne du moteur, qui ne nécessite pas en tant normal d’intervenir dessus, il appartient donc au clans des module de type configuration.

le choix entre ces 2 modules, est proche, et peut vraissemblablement être considerer comme null.  On notera toutefois que le support des module de pages intervient avec le jeu de fichiers pages.xxx.inc du dossier content.
Les module de type configuration, eux sont executé par les fichiers configuration.xxx.inc.

Enfin, notez aussi , que au niveau de l’autoload, des librairies associé, le fonctionnment n’est pas tous a fait le même .

De plus, les class de type pages, pour tous les contenus important, le module contient dans ce cas la laisons avec les fontionnalités ACA, ce qui n’est pas le cas avec les modules de configuration.

Une dernière remarque.
Les modules de type page, ont un focntionnement stabilisé, est il n’est pas annocé de revenir sur cette stabilité dans les versions a avenir. En dehors de l’optimisation, qui ne modifiera pas leur usages.
Par contre , pour les modules de configuration, l aversion 2.1.3 devrait modifier leur mode de fonctionnement, et le nom des methode, il sera alors necessaire de revenir sur ces modules;

osCSS 2 , popup via fancy, et bouton cancel/return

Mercredi 18 août 2010

Afin de simplifier les appels à la fermeture de la fancy, lors de l’affichage d’action, un fonction présente dans html_output à été ajouté. Elle ce charge de détecter les variable get, et ainsi d’adapter le code du bouton, anulation/retour. (Lire la suite…)