Yosko.net

Keep Calm and Rock On.

26 résultats pour les tags php x

Ultimate PHP error_reporting wizard

18/03/2015 09:13 (source - permalien)

Un moyen pratique et rapide de définir les erreurs à remonter en PHP.

L'avantage ? Donne aussi la valeur numérique correspondante. Pour rappel les constantes type E_ALL ne peuvent être utilisées nominativement que dans le php.ini et le code PHP. Dans les autres cas, la valeur numérique est nécessaire : PHP en ligne de commande, dans un .htaccess et dans un vhost.

Update de mes projets

20/03/2014 07:02 (source - permalien)

Ca faisait un petit moment que je n'avais pas publié de mise à jour de mes projets PHP, donc voici :

- Jotter passe en v0.4 avec un editor Markdown en plus du Wysiwyg (pas encore ultra utile) et plein de corrections et évolutions mineures (https://github.com/yosko/jotter/releases/tag/v0.4)
- YosLogin (librairie de gestion d'authentification) passe en v4 avec une réécriture basée sur des callbacks pour intégration plus aisée dans un projet (https://github.com/yosko/yoslogin)
- Watamelo (framework MVC) passe en v0.6 et continue à s'enrichir et se stabiliser (https://github.com/yosko/watamelo)

Comme toujours n'hésitez pas à me faire part de vos remarques :)

Edit 2014-03-21 : ah zut, faut que je mette à jour la démo de Jotter (http://tools.yosko.net/demos/jotter/) Je fais ça dans l'aprèm.

PHP: mb_convert_encoding - Manual

13/01/2014 01:49 (source - permalien)

Vous connaissiez sans doute htmlentities() et htmlspecialchars(), les fonctions permettant de convertir les caractères spéciaux en entités HTML :
- htmlentities() les converti tous
- htmlspecialchars() converti uniquement les caractères < > & " '

Et bien sachez qu'il existe aussi mb_convert_encoding() qui, correctement paramétrée, fait exactement l'inverse : convertir tous les caractères spéciaux en leurs entités, à l'exception de < > & " '

$html = mb_convert_encoding($html, 'HTML-ENTITIES', 'UTF-8');

Quel intérêt me direz-vous ? En effet, si on encode bien ses fichiers au départ, et si il n'y a pas de risque de sécurité si on garde les tags, pourquoi convertir le reste ?
Un internaute le conseille par exemple (http://stackoverflow.com/a/8218649/863323) lors de l'utilisation de la méthode DOMDocument::loadHTML() avec du HTML en UTF-8 alors que la méthode est prévue pour du ISO-8859-1.

yosko/php-github-updater

02/01/2014 05:30 (source - permalien)

Hop hop hop !

Pour fêter la nouvelle année, je vous propose une petite classe utilitaire pour faciliter l'implémentation d'une mise à jour automatique de vos applications PHP hébergées sur Github.

Bon ok, pour l'instant c'est encore un peu en bêta, mais je suis sûr que ça va vite roxxer du poney, surtout si vous me faites vos retours :P

Edit : mon but était d'intégrer ça rapidement dans Jotter, mais je me suis dis que d'autres pourraient être intéressés :)

Publication de mon code open-source

18/12/2013 11:50 (source - permalien)

Je suis en train de publier sur Github / Gist pas mal de mes vieux bouts de code et mes principaux snippets. C'est plus pratique et clair que de les fournir dans des vieux ZIP accessibles sur des pages tombées dans l'oubli.

Pour l'instant, mes nouveaux dépôts :
- Anime Girl Generator (C#) : https://github.com/yosko/anime-girl-generator
- Yalig, gallerie d'images (PHP) : https://github.com/yosko/yalig

Et mes Gists :
- convertisseur DOM (XML/HTML) <-> Tableau PHP : https://gist.github.com/yosko/6991691
- script de batch download en PHP : https://gist.github.com/yosko/7989061
- fonction PHP pour générer une pagination : https://gist.github.com/yosko/8020218
- fonctions de conversion de couleurs en PHP : https://gist.github.com/yosko/8020258
- citation aléatoire du jeu "Empereur : L'Empire du Milieu" : https://gist.github.com/yosko/8020342
- script de migration de Blogotext vers Pluxml : https://gist.github.com/yosko/8020376

Je n'ai pas encore fait ça pour Avator (http://www.yosko.net/static3/avator) parce que j'ai un gros doute sur les sources. Voilà ce que c'est que de laisser trainer son code...

J'en profite pour ajouter que :
- Je vais bientôt faire des corrections sur DDb
- Je vais sans doute bientôt améliorer Yalig
- Je suis toujours bien penché sur Jotter (même si je galère un peu avec le Javascript ^^' ).

PHP: Download documentation

24/10/2013 11:50 (source - permalien)

Mais pourquoi n'y ai-je pas pensé plus tôt ? :D
Télécharger une doc en local, ça change vraiment la vie. Recherches instantanées, pas de souci de connexion, de chargement de js/css bloqués par le proxy, etc... et ça ne dépasse pas les 30 Mo AVEC les commentaires utilisateurs (et non compressé).

PS : vous me dite quand vous en avez marre de me voir poster des trucs basiques sur PHP xD

Mots clés : php

PHP Template Engine Comparison

22/10/2013 01:38 (source - permalien)

Petit benchmark sur les moteurs de template courants en PHP. Résultat, faire les choses direct en PHP semble (logiquement) plus léger et rapide.

Je suis tombé dessus en me demandant s'il était judicieux de me séparer de raintpl pour mon petit Framework MVC (https://github.com/yosko/watamelo), et cette comparaison a fini de me convaincre.

Bon, c'est peut-être plus verbeux de faire des vues/templates direct en PHP, mais c'est plus libre/puissant, et finalement pas beaucoup plus long à écrire...

Mots clés : php

PHP DOM vs SimpleXML - Stack Overflow

14/10/2013 02:17 (source - permalien)

C'est sans doute évident pour pas mal de gens, mais je ne m'étais encore jamais posé la question, donc je me garde ça sous le coude.

En gros : pour parser du XML en PHP, préférez DOM pour plus de possibilités, et SimpleXML pour plus de simplicité. J'ai cru comprendre que DOM était conseillé car il est plus souvent présent sur les install PHP (genre PHP4), parce qu'il permet d'ajouter du contenu (pas seulement de le lire), et parce qu'il ressemble à ce qui se fait en javascript...

Mots clés : php

PHP Snippet : (re)générer une base SQLite à partir d'un script SQL

25/09/2013 04:23 (source - permalien)

S'il vous prend l'envie de (re)générer une base SQLite rapidos en PHP, ce snippet est fait pour vous. Basé sur l'idée d'un fichiers SQL comportant tous les DROP/CREATE, et éventuellement des INSERT.

Quelques trucs à savoir :
1- l'emploi de la classe SQLite3 (ou son ancêtre  SQLiteDatabase pour PHP < 5.4, voir carrément sqlite_open / sqlite_exec si les classes vous font peur) est nécessaire pour pouvoir exécuter plusieurs requêtes d'un coup. PDO n'est pas capable de gérer...
2- L'exécution de ce script est préférable en ligne de commande. En effet, via un navigateur, vous vous payeriez probablement un timeout si votre base est assez grosse. Et ça évite les bidouilles sur set_time_limit (30s par défaut en web, et non limité par défaut en ligne de commande)

yosko/easydump

23/09/2013 04:40 (source - permalien)

Je viens de mettre EasyDump à jour. Il permet désormais de :
1- afficher le nom des variables (facultatif)
2- afficher le nom du fichier et le numéro de la ligne où EasyDump a été appelé
3- afficher le code complet de l'appel à EasyDump (facultatif, utile en cas de dumps nombreux)

Par contre, il n'est désormais compatible qu'avec PHP 5.1.0 ou supérieur (mais vous ne devriez de toute façon plus utiliser de versions plus anciennes...) car j'utilise la classe SplFileObject pour lire un fichier ligne à ligne à l'envers.

Pour l'affichage des noms de variable, je me suis bien amusé. Je voulais parser le code PHP en une seule regex, mais au final, j'en utilise 5. Je me suis longuement arraché les cheveux, avant de choisir la voie de la facilité...

Edit 10/10/2013 : plus de regex, parsage à la main. Je me suis bien prix le choux, quand même... Mais maintenant, l'essentiel des cas bizarres devrait être géré.

PHP: htmlentities - Manual

16/09/2013 01:59 (source - permalien)

Rah, cette satanée fonction d'htmlentities a changé d'encodage par défaut entre PHP 5.3 (ISO-8859-1) et 5.4 (UTF-8). Je vous le demande : qui pense à préciser un encodage lors de l'utilisation de cette fonction ?

Cela veut dire que des fichiers PHP en UTF-8, des encodages des pages HTML en UTF-8 (et déclarés comme tel) n'empêcheront pas htmlentities d'interpréter du texte issu d'un formulaire en ISO-8859-1 si vous ne lui forcez pas la main...

J'ai réussi à corrompre une bonne partie de mes données sur un projet avant de m'en rendre compte (quelle idée aussi de développer en PHP 5.4 quand la prod est en 5.3... :D ).

Tout ça pour dire : faut toujours être très vigilent avec les encodages. Décider de faire l'ensemble d'un projet dans un encodage unique, n'est pas forcément nécessaire, mais n'est surtout pas suffisant car il y'aura toujours des fonctions natives qui décident de faire différement...

Mots clés : php

page 1 / 2 Suivant »