Comment récuperer les parametres d’appel de votre page en javascript.

Bonjour,

Juste un petit code super rapide, pour extraire les paramêtres de l’url d’appel d’une page en javascript. Dans mon cas ca a été utile pour retransmettre certains  paramètres dans le cas d’une redirection pour de l’affiliation.

Attention, ce post n’est en aucun cas une redite par rapport a mon post précédent : Je parle ici des paramètres d’appel à la page html :

Si par exemple, votre page a comme url  monsite.tld/toto.php?arg1=AAAAA&arg2=BBBBB, ce script va vous permettre de recuperer une tableau associatif de cette forme :

array(
    [arg1]=>'AAAAA',
    [arg2]=>'BBBBB'
);

La différence vient que dans mon précédent post ( Voir le post ) j’extrayer les paramêtres d’appel du fichier javascript et non du fichier PHP (ou html).

Voila le snippet :

function extractUrlParams(){	
	var t = location.search.substring(1).split('&');
	var f = [];
	for (var i=0; i<t.length; i++){
		var x = t[ i ].split('=');
		f[x[0]]=x[1];
	}
	return f;
}

En espérant que ce petit bout de code puisse pour permettre d’extraire les paramètres de l’appel de votre url en javascript.

Comment récuperer des paramètres passés en Url d’un appel de javascript !

Bonjour,

Derrière ce titre quelque peut imbitable, se cache une problèmatique réelle. Dans le cadre de l’affilation certains diffuseurs ont besoin d’inclure des javascript plutot que des widget en iframe.

Pourquoi ? Ben tout simplement pour pouvoir afficher de manière asynchrone leur page et les widgets des annonceurs.

Si comme moi, vos bannières sont des médias riches incluant des images, css, et js, vous  et si en plus vos médias ont besoin de paramètres particuliers, vous allez aimer ce billet !

Je m’explique.

J’ai des bannières paramétrables et qui nécéssitent d’être insérées dans la pages du diffuseur via une iframe (Oui je sais les iframes c’est mal ! :-D).

Exemple de script Iframe :

<iframe src="monurliframe" width="malargeur" height="mahauteur"/>

Seulement je voudrais faire ceci en chargeant simplement un fichier javascript avec un appel du type :

<script type="application/x-javascript" src="httpw://monsite/js/monscript.js?param1=valeur1&param2=valeur2"></script>

Ah oui mais seulement voila, les paramêtres ne sont pas recupérable  en javascript, donc “Houston ? On as un problème !”

L’astuce consiste a rechercher l’inclusion du script, de “parser” la source de l’appel et à en extraire les paramètres.

Pour ce faire, j’ai utliser un bout de code trouvé à l’adresse suivante : http://linuxfr.org/forums/programmationweb/posts/javascript-appel%C3%A9-avec-param%C3%A8tres-dans-lurl

Avec un peu de reformattage, on arrive au code suivant :

//Recuperation des parametres passés en url de l'appel javascript.
function getParam(){
  var src;
  var scripts = document.getElementsByTagName('script');
  for(var i = 0; i < scripts.length; i++){
    src = scripts[i].getAttribute('src');
    if(src.match(/widget\.js(\?.*)?$/) != null){
      var splitURL = src.split('?');
      var params = splitURL[1].split('&');
      var myParams = new Object();
      var keyValue = new Array();
      for(var j = 0; j < params.length; j++){
        keyValue = params[j].split('=');
        myParams[keyValue[0]] = unescape(keyValue[1]);
      }
    }
  }
  return myParams;
}
params = getParam();
//Ecriture de l'iframe
document.write('<iframe src=\"http:/monsite.com/mapageiframe.php?param1='+params['param1']+'&param2='+params['param2']+'\" frameborder=\"0\" border=\"0\" marginwidth=\"0\" marginheight=\"0\" scrolling=\"no\"></iframe>');

La premiere partie est la fonction qui parcourt le document courant et isole toutes les balises <script>, ensuite pour chacune d’entre elles, on verifie que le nom du fichier javascript correspond bien au notre. Si c’est le cas, on extrait les paramêtres que l’on retourne dans un tableau associatif.

La seconde partie est un exemple d’utilisation : l’ecriture d’une iframe, ceci dit c’est applicable à nombre de cas !

En espérant que ce billet vous sera utile !

Symfony 2 : erreur 502 sur le profiler.

Bonjour,

J’ai installer Symfony2 pour une petite application “perso” et je me suis rendu compte que la barre de debug de Symfony renvoyait systématiquement sur une erreur 502.

Cela vient du fait que les entêtes http sont trop importants parce que par défaut Symfony 2 envoie des informations de debug pour des plugins FirePHP et ChromePHP.

On peut très simplement les désactiver dans le fichier de configuration app/config/config_dev.yml

monolog:
    handlers:
        main:
            type:  stream
            path:  %kernel.logs_dir%/%kernel.environment%.log
            level: debug
#        firephp:
#            type:  firephp
#            level: info
        #chromephp:
         #   type:  chromephp
          #  level: info

En commentant les lignes 7 à 12, on désactive l’envoi des informations de debug dans les entêtes, réactivant ainsi l’utilisation des barres de debug “en ligne” de Symfony 2.

Voila, pensez juste à vider le cache par sécurité.

php app/console cache:clear

Yapluka !!

Configuration Nginx php5-fpm pour symfony 2

Bonjour,

Voilà, je me suis pris la tête pour configurer correctement Symfony sur ma machine (ubuntu) pour faire tourner Symfony 2.

Je vais vous donner quelques astuces supplémentaires et quelques exemples de configuration.

Tout d’abord, on va commencer par php5-fpm (fastcgi). Symfony consomme de la mémoire, pas énormément en “prod” par contre en version de développement, ça bouffe pas mal surtout si on veut faire du debug. On va donc commencer par augmenter la quantité de mémoire allouée a FPM.

On va rechercher le fichier php.ini utilisé.

mathieu@mathieu:~/workspace/statis$ locate php.ini
/etc/php5/apache2/php.ini
/etc/php5/cli/php.ini
/etc/php5/fpm/php.ini
mathieu@mathieu:~/workspace/statis$

Dans le cas présent, je sais que j’utilise nginx donc pour l’exécution de PHP, j’utilise “fpm”, c’est donc le fichier que je vais modifier.

; Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
memory_limit = 1024M

Ici, j’ai fixé la limite de mémoire a 1024Mb, on pourrait aussi l’écrire 1G. Une fois ceci fait, on redémarre “fpm” :

root@mathieu:~/workspace/statis# service php5-fpm restart
 * Restarting PHP5 FastCGI Process Manager php5-fpm    [ OK ] 
root@mathieu:~/workspace/statis#

Symfony 2 utilise dans certains cas les entêtes Http pour retransmettre des informations de debug, notamment à l’attention de ChromePHP et FirePHP. Par défaut la transmission en environnement de “Dev” est active. Du coup, nginx sature et renvoie des erreurs 502 parce que les entêtes sont trop “gros”.

Je vous mets ici ma conf actuelle de nginx, que je commenterai par la suite :

server {
    listen 9999;
    server_name symfony2;
    root /home/mathieu/workspace/statis/web;
    error_log /var/log/nginx/statis.error.log warn;
    access_log /var/log/nginx/statis.access.log warn;
    rewrite ^/app\.php/?(.*)$ /$1 permanent;
    location / {
        index app.php;
        try_files $uri @rewriteapp;
    }
    location @rewriteapp {
        rewrite ^(.*)$ /app.php/$1 last;
    }
    location ~ ^/(app|app_dev|config)\.php(/|$) {
                fastcgi_pass unix:/var/run/php5-fpm.sock;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO       $path_info;
                fastcgi_read_timeout 600;
                fastcgi_buffer_size   16k;
                fastcgi_buffers       4 16k;  # up to 4k + 128 * 4k
                fastcgi_max_temp_file_size 0;
                fastcgi_index index.php;
                include fastcgi_params;
                gzip off;

    }
}
  • Ligne 1 : on ouvre la configuration du serveur
  • Ligne 2 : on définit le port d’écoute. Ici il s’agit du 9999 mais plus généralement on utilise le port 80 spécifique au protocole http.
  • Ligne 3 : on définit le nom du serveur.
  • Ligne 4 : On définit le répertoire racine de l’application. Attention ici le “Webe est important pour symfony parce qu’il contient le système de boot de symfony.
  • Ligne 5 et 6: On définit les noms des fichiers de log nginx.
  • Ligne 7 : On réécrit l’url pour virer les noms app.php en environnement de production.
  • Ligne 8 à 11: on définit l’index de l’application et on stocke en mémoire.
  • Ligne 12 à 14 : on définit les règles de réécriture avec la variable précédemment enregistrée.
  • Ligne 15 à 26 : Parametres pour l’exécution de Fast-cgi : Je vais revenir dessus plus précisément ci-dessous.

Voilà un exemple de configuration Nginx pour le fonctionnement de Symfony 2, je vais maintenant reprendre la partie FPM pour corriger les problèmes d’entêtes trop importants

location ~ ^/(app|app_dev|config)\.php(/|$) {
                fastcgi_pass unix:/var/run/php5-fpm.sock;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO       $path_info;
                fastcgi_read_timeout 600;
                fastcgi_buffer_size   16k;
                fastcgi_buffers       4 16k;  # up to 4k + 128 * 4k
                fastcgi_max_temp_file_size 0;
                fastcgi_index index.php;
                include fastcgi_params;
                gzip off;

    }

Ce qui nous intéresse ici ce sont les ligne 7 et 8, pour redéfinir les tailles des buffers. On les augmente avec les valeurs ci-dessus.

Ce sont les 2 astuces que j’ai repéré pour les configurations des serveurs pour faire fonctionner Symfony 2 avec nginx et phpfpm.

Git : installation d’un repository sur une hébergement mutualisé OVH – Partie 1 : Preparation du repository

Bonjour !

Hier je vous ai parlé de GIT, un système simple de “versioning”. Perso, j’ai certains projets de développement qui m’intéresserait de “versionné”. J’avais essayer Subversion sur un hébergement mutualisé mais comme cela nécessite de pouvoir installer les éléments propres à subversion … j’ai abandonné.

Du coup, après m’être intéressé à git j’ai voulu tenter l’expérience. Après quelques recherches je suis tombé sur plusieurs tutoriel qui expliquait comment le faire. Ceci dit, ces tutoriels n’était à mon gout pas assez clair et documenter. Je ne prétends pas faire mieux mais je vais quand même essayer.

Aujourd’hui, on va donc créer le repository principal de git.

  1. On va donc créer un dossier git dans le répertoire racine pour ne pas interferer avec notre site en lui même.
    mkdir git
  2. Notre répertoire de repository est créé, on va maintenant créer le repository proprement dit en commençant par le répertoire où il sera stocké.
    mkdir monrepo.git
  3. Une fois ce répertoire créé, on va dedans et on initialise la base de données git
    ~/$cd ~/git/monrepo.git
    ~/test.git$ git init-db
    Initialized empty Git repository in ~/test.git/.git/~/test.git$
  4. On as initialisé le repository git. on va maintenant le configurer une petit peu. Il existe quelques instructions a définir: “user.name” qui permet de définir le nom du codeur, “user.email”, qui se passe de commentaire, “color.ui”  permet de faire de la colorisation syntaxique, et enfin “help.autocorrect” qui permet d’executer directement la commande si une seule commande est  trouvée par git.

Bon ben voila le repository de Git est en place. Il ne reste plus qu’à l’utiliser