Cette requête SQL peut être utile si vous travaillez sur une grosse base de données par exemple et que vous essayez de localiser un champ d’une table à partir du nom du champ.

Personnellement je m’en sert pour renommer les champs étant des noms réservés par Doctrine lors d’une introspection du framework Symfony.

Imaginons par exemple que nous recherchons toutes les tables possédant un champ nommé « last_modified » dans la base de données « introspection ». La requête SQL se présente alors comme suit :

SELECT *
FROM INFORMATION_SCHEMA.COLUMNS
WHERE COLUMN_NAME LIKE '%last_modified%'
AND TABLE_SCHEMA = 'introspection'

D’une manière générale, apprendre à utiliser les requêtes sur INFORMATION_SCHEMA peut se révéler très utile !

Voici une petite fonction sans grande prétention mais qui pourrait intéresser les webmasters désirant intégrer le moyen de paiement Ogone Basic e-Commerce sur leur site e-commerce. En effet, Ogone spécifie dans sa documentation technique que le formulaire d’appel au serveur de paiement doit contenir un paramètre invisible « SHASign » contenant une clé de vérification hashée.

Cette clé est formée à partir de tous les paramètres du formulaire envoyés au serveur de paiement ainsi que d’un mot de passe (passphrase) secret à définir sur votre interface d’administration Ogone.

Le principe est donc simple, toutes les clés doivent être en majuscules et rangées par ordre alphabétique et chaque valeur doit être concaténée au mot de passe.

La fonction ci-dessous permet de réaliser cette opération, elle nécessite un algorithme de hashage (sha1 par défaut), la liste de tous les paramètres de votre formulaire (excepté le champ « SHASign ») en majuscules ou non et pour finir votre mot de passe.

La fonction retourne la clé hashée qu’il faut ensuite renseigner dans le champ SHASign.

Si lors du paiement vous recevez l’erreur unknown order/1/r, c’est que votre clé de hashage est incorrecte (mauvais mot de passe, manque de paramètres ou encore mauvais algorithme de hashage).

<?php
/**
 * Fonction permettant de générer le HASH-IN d'Ogone.
 * @param string $_algorithm
 * @param array $_parameters
 * @param string $_passphrase
 * @return string
 */
function ogone_hash_parameters($_algorithm = 'sha1', $_parameters = array(), $_passphrase = 'mySecretPassphrase') {
 
	$str = '';
	$parameters = array();
 
	//__ On s'assure que toutes les clés sont en majuscules et rangées par ordre alphabétique
	foreach ($_parameters as $k => $v) {
 
		$parameters[strtoupper($k)] = $v;
 
	}
	ksort($parameters);
 
	foreach($parameters as $k => $v) {
		$str .= $k . '=' . $v . $_passphrase;
	}
 
	return call_user_func($_algorithm, $str);
 
}
?>

<?php
 
//__ Exemple d'appel de la fonction
$SHASign = ogone_hash_parameters('sha1', array('PSPID' => 'your_PSPID', 'orderID' => 1, 'amount' => 1504, 'currency' => 'EUR'), 'myProductionSecretPassphrase');
 
?>

Si vous-êtes sur ce billet c’est que vous recherchez l’User-Agent (Agent d’utilisateur ou encore signature) du moteur de recherche Bing de Microsoft

Sans plus attendre voici la chaine de caractères :

Mozilla/5.0 (compatible; bingbot/2.0 +http://www.bing.com/bingbot.htm)

Voici un titre de billet un peu barbare mais il s’agit ici de parler d’une erreur très spécifique qui peut survenir avec la version 2.0.2 de CodeIgniter lors de l’utilisation d’Acicrud.

Le cas de figure est le suivant, vous tentez de lire une entrée en base de données avec la méthode read($primary_key) (par exemple) et une erreur fatale est levée :

Call to a member function result_array() on a non-object in /system/database/DB_driver.php on line 837

La cause probable de cette erreur est une mauvaise configuration au niveau de la base de données ou au niveau d’Acicrud.

Voici une procédure de vérification qui vous permettra très certainement de corriger l’erreur :

• Si vous utilisez un préfixe de table, vous devez l’indiquer dans /application/config/database.php dans $db['default']['dbprefix'], assurez-vous d’avoir spécifié l’underscore final, par exemple « mon_prefixe_ ».
• Vérifiez ensuite que le modèle incriminé instancie bien la librairie Acicrud avec le nom de la table liée sans le préfixe et que le nom de la table est correct. Par exemple, pour une table nommée « my_prefix_users », l’appel du constructeur doit être le suivant : parent::__construct(‘users’);
• Dernière possibilité, vérifiez que la requête SQL générée par le driver de CodeIgniter est correcte, pour cela ouvrez /system/database/DB_driver.php et faîtes un echo de $sql en ligne 833 juste avant le $query = $this->query($sql);

Nous allons voir dans cet article comment rendre rapidement non éditables les listes déroulantes générées par les widgets symfony (1.4) sfWidgetFormDate et sfWidgetFormDateTime. En effet, il existe une petite subtilité de syntaxe qui peut rapidement faire penser à un bug du framework lorsque l’on essaye d’appliquer l’attribut « disabled » sur l’un de ces deux widgets.

Pour illustrer la méthode, nous allons éditer le fichier {model}Form.class.php (relatif à votre modèle) contenant la méthode configure() permettant de redéfinir les widgets
instanciés dans Base {model}Form.class.php.

En ajoutant l’attribut « disabled » directement dans cette classe, ceux-ci seront automatiquement désactivés (mais affichés à l’utilisateur) dès lors que vous générerez le formulaire du modèle.

Attribut disabled pour un sfWidgetFormDate

Pour la classe sfWidgetFormDate pas de problèmes, il suffit d’ajouter directement l’attribut au widget :

$this->getWidget('my_date')->setAttribute('disabled', 'disabled');

Attribut disabled pour un sfWidgetFormDateTime

Pour la classe sfWidgetFormDateTime il existe une petite subtilité, l’attribut doit être déclaré deux fois, une fois pour la configuration de la partie « date » et une seconde fois pour la partie « time » du widget :

$this->getWidget('my_datetime')->setAttribute('date', array('disabled' => 'disabled'));
$this->getWidget('my_datetime')->setAttribute('time', array('disabled' => 'disabled'));

Si vous rencontrez cette erreur fatale avec le framework CodeIgniter c’est que vous utilisez sûrement du code déprécié avec la version 2.0 du framework.

En effet, l’ancienne classe Controller dont tous les contrôleurs CodeIgniter devaient hériter à été renommée en CI_Controller avec la nouvelle version.

Pour corriger l’erreur, il vous suffit de vous rendre dans le contrôlleur en question et de remplacer la classe d’héritage extends Controller par extends CI_Controller.

N’oubliez pas de vérifier que votre constructeur de classe fait bien appel au bon super constructeur. Pour cela, l’expression parent::Controller(); doit être remplacée par le style PHP 5 : parent::__construct();

Dans mon récent apprentissage du framework PHP symfony j’ai été confronté à une problématique de syntaxe simple : comment charger un fichier de fixtures en particulier ?

Les fixtures au format YML sont des données représentant les jeux de tests de votre application.

En effet, il est possible d’insérer facilement les fixtures placées dans /data/fixtures du projet via doctrine et la commande symfony ci-dessous :

php symfony doctrine:data-load

En revanche, si vous désirez insérer un fichier en particulier vous devez spécifier le fichier de fixtures à la commande (ici il s’agit des fixtures du plugin sfGuard) :

php symfony doctrine:data-load data/fixtures/sfGuard.yml

Aussi simple que cela mais non présent dans la documentation !

Si vous désirez insérer des données sous MySQL ou effectuer une mise à jour sur la ligne s’il existe déjà, sachez qu’il existe une syntaxe permettant de réaliser l’opération au sein d’une instruction INSERT.

Pour pouvoir utiliser cette syntaxe vos tables devront obligatoirement posséder une clé primaire puisque c’est sur cette clé qu’un test va être effectué par MySQL.

Mise à jour d’une ligne MySQL si elle existe déjà

INSERT INTO `base`.`table` (`champ`) VALUES ('valeur') ON DUPLICATE KEY UPDATE `champ` = 'valeur';

Magento, la célèbre plateforme eCommerce Open Source vient d’annoncer la disponibilité de sa nouvelle solution Magento Mobile !

Le principe est simple, une extension est disponible sur Magento Connect permettant de gérer sa boutique mobile, il suffit ensuite d’acheter une licence Magento Mobile puis de transmettre à Magento les paramètres de sa boutique depuis l’extension. Magento s’occupe ensuite de la soumission de l’application à Apple afin que celle-ci soit disponible via l’Apple Store !

Magento prend ainsi une nouvelle avance technologique sur la concurrence ! En revanche, il faudra tout de même débourser 799$ de frais d’installation ainsi que 69$ par mois ! Autant dire que les petits commerçants ne sont clairement pas ciblés par Magento Mobile.

Plus d’informations sur Magento Mobile.

Vidéo de démonstration de Magento Mobile