Si vous avez besoin de mettre à jour une release d’Eclipse Indigo (3.7) ou d’installer un plugin à partir du menu « Help > Install new software… » mais que vous n’avez pas le site de mise à jour dans la liste cette information est pour vous !

Ce cas de figure peut arriver lorsque vous utilisez PDT par exemple (Eclipse pour PHP).

Donc pas de panique, ajoutez un nouveau site et renseignez l’URL ci-dessous, vous aurez alors accès à tous les plugins :

• Indigo – http://download.eclipse.org/releases/indigo/

N’oubliez pas de sélectionner l’entrée que vous venez de créer dans la liste « Working site »

Cet article propose deux lignes de code permettant de supprimer certaines balises HTML d’une chaîne de caractères en PHP. L’avantage est que vous allez pouvoir cibler certaines balises contrairement à la fonction native strip_tags qui supprime la totalité des balises PHP et HTML.

La solution est simple, il suffit d’utiliser preg_replace avec deux expressions régulières (REGEX) à adapter en fonction de la balise ciblée.

Supprimer un lien HTML (balise ouvrante <a> et balise fermante </a>

$string = preg_replace("`(<a[^>]*>)(.*)(<\/a>)`Ui", "",$string);

Supprimer une image HTML (balise auto-fermante <img />

$string = preg_replace('#<img(.*)/>#i', "",$string);

Il vous suffit d’adapter le nom de la balise dans l’expression régulière si vous souhaitez supprimer d’autres balises.

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');
 
?>

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 !

Cette erreur fatale peut subvenir lorsqu’un client SOAP tente de se connecter à un serveur en utilisant la mauvaise version de SOAP.

C’est notamment le cas lorsqu’un client tente de se connecter avec la directive SOAP_1_2 à un serveur SOAP ne supportant uniquement la directive SOAP_1_1.

L’erreur ci-dessous est alors remontée :

PHP Fatal error:  Uncaught SoapFault exception: [soap:Client] Unable to handle request without a valid action parameter. Please supply a valid soap action.

Afin de résoudre cette erreur, il suffit d’indiquer la version à utiliser lors de la construction du client SOAP (instance de la classe Zend_Soap_Client dans cet exemple) :

$soapclient = new Zend_Soap_Client('http://www.example.com/?WSDL',
	array(
		'soap_version' => SOAP_1_1,
		'encoding' => 'UTF-8'
	)
);

Voici une astuce publiée sur le forum de CodeIgniter qui permet de définir le timezone à utiliser par la base de données un seule fois pour tous les modèles de l’application.

Pour réaliser cette tâche, l’auteur à simplement dérivé la classe Model de CodeIgniter afin d’exécuter la requête SQL modifiant le timezone à la construction de l’objet. Ainsi, comme lorsqu’on utilise ACICRUD, les modèles de l’application doivent étendre la classe mère au lieu de la classe Model.

Voici l’exemple de code proposé par flaky :

class Master_model extends Model{
    public function __construct(){
        parent::__construct();
 
        $this->set_timezone();
    }
 
    public function set_timezone(){
        $this->db->query("SET time_zone='+0:00'");
    }
}
 
class Some_model extends Master_model{
    public function __construct(){
        parent::__construct();
    }
}

Voir le post original.