Ses derniers messages sur les forums
Heu... ouais.
J'ai envie de dire que c'est normal.
T'as un problème de concaténation : ta fonction highlight_file n'est pas interprété par PHP car elle est "lue" comme une chaine de caractère par PHP.
C'est comme si tu faisais :
<?php
echo 'pom strlen(\'blu\');';
?>
Ben ca, ca n'affichera pas la longueur de la chaine, ca affichera "pom strlen('blu');".
Il faudrait faire :
<?php
echo 'pom '.strlen('blu');
?>
(pour que la concaténation soit prise en compte et que ca affiche "pom 3")
Mais bon, ca c'est une chose.
Le problème, c'est que dans ton cas, ca ne t'aidera pas, car pour faire ce que tu cherches à faire, un simple str_replace ne suffit pas.
Il faut faire une expression régulière avec un preg_replace_callback.
Je te conseille de lire le cours sur les expressions régulières.
C'est un problème de javascript et non de PHP.
En gros, tu dois mettre un attribut onchange sur ton menu déroulant, et dans ce onchange, et bien, tu ouvres une pop up avec un window.open, ou un truc du genre.
C'est pas dangereux en soit, mais c'est chiant si jamais un jour tu changes tes images de place.
Cela voudrait dire : modifier toutes les entrées en base.
Moi, je stockerais le minimum syndical en base : soit juste le chemin du fichier, voir même seulement le nom du fichier (si mes images sont dans un seul dossier, ce qui semble être ton cas, excepté le fait de la distinction maxi / mini, mais çà, tu n'as pas besoin du chemin de l'image pour savoir que si tu as une grande image dans maxi, ben théoriquement, tu as la même en petit dans mini).
Tu aurais vu ton erreur en faisant un echo $sql
<?php
if(isset($_POST['photo_name'])&& $_POST['photo_name']!= "") {
include'connexiondb.php';
$date = date("Y-m-d H:i:s");
$lien='<a href="images/maxi/'.$_POST['photo_name'].'.gif"><img src="images/mini/'.$_POST['photo_name'].'.gif"></a>';
$sql = "INSERT INTO photo_lan VALUES('', '".mysql_escape_string($lien)."', '".mysql_escape_string($date)."')";
mysql_query($sql) or die('Erreur SQL !'.$sql.'<br />'.mysql_error());
mysql_close();
}
else {
echo'veuillez remplir tout les champs';
}
?>
PS :
TOUJOURS escaper ce que tu mets dans une requête SQL !
PPS : mettre du html en base, c'est mal ©
C'est normal, exit() ou die() coupe l'exécution du script.
Par conséquent, tout ce qui suit est ignoré.
Que dire pour t'aider ? Enlever le exit() ?
Je viens de voir qu'il existait des décodeurs md5
Tu devrais lire une doc. sur le md5.
En effet, dès l'invention du md5, il existait déjà des "décodeurs" : la puissance de calcul des processeurs.
Je m'explique.
Le md5, c'est une technique de hachage, donc pour décoder, il faut soit brutforcer (tester toutes les possibles et voir si le md5 match ou non), soit avoir en sa possession, une base qui fait la corrélation entre une chaine en clair et son md5 (ce que tu as l'air de citer dans ton message).
md5 n'est pas infaillible : c'est une technique de hachage, par conséquent, deux chaines différentes peuvent avoir le même md5.
Ensuite, brutforcer un md5 qui d'origine fait 2 caractères, ca se trouve en 2 secondes, mais un mot de passe original qui fait 10 caractères, il faut s'accrocher quand meme (si jamais tu n'as pas de base qui fait le lien entre md5 et chaine en clair).
Donc je ne pense pas que les webmasters s'amusent à essayer de brutforcer tous les md5 qu'ils ont en base.
Sinon, ils les stockeraient directement en clair (ben ouais, c'est plus simple, pas besoin de déhacher :p).
PS : ce n'est pas une limite de MySQL, c'est juste MySQL qui ne fait qu'implémenter une technique de hachage connue.
Regarde la doc MySQL sur la fonction EXPLAIN.
Elle te permet de voir l'algorithme qu'utilise MySQL pour résoudre tes SELECT et de voir aussi quels index il utilise, et le nombre estimé de lignes retournées.
La clé pour avoir des requêtes rapides, c'est d'utiliser de bons index et les clés primaires, et surtout d'arriver à estimer la taille de tes tables dans 6 mois.
En effet, dans le temps, il se peut que des requetes, meme avec des clés primaires, mettent du temps à s'executer, et dans ce cas, il faut penser à faire des tables temporaires ou de backup.
Mais rassure toi, avec un site perso, arriver à ces extrêmes est tout simplement extrêmement rare.
MySQL reste très rapide dans l'ensemble (si tu as bien pensé à ton schéma de base).
Si tu veux un ordre d'idée, au boulot, on a une base de données MySQL de 1 Tera octet (1 000 Go) qui se prend 1500 SELECT par seconde, et "çà ne bronche pas trop".
Donc tu peux y aller.
PS : attention, je le répète, tu peux y aller que si tes requêtes sont propres : clés primaires / index et EXPLAIN jolis qui utilisent tous des clés avec un nombre de rows retournés minimal (cf. doc pour les rows).
Tu peux faire ainsi :
<?php
function decompose_date($date) {
$temp = explode('.', $date);
$retour = 0;
foreach ($temp AS $chiffre) {
if (is_numeric($chiffre)) $retour = $retour + $chiffre;
}
return $retour;
}
function calcul_taro($nombre) {
$nombre = ''.$nombre;
if (strlen($nombre) > 1) {
$string = 0;
for ($i=0; $i<strlen($nombre); $i++) {
$string = $string + $nombre{$i};
}
$nombre = calcul_taro($string);
}
return $nombre;
}
echo calcul_taro(decompose_date('21.03.2007'));
?>
L'idée du truc, c'est de faire une fonction récursive : c'est à dire tant que ta somme est un nombre (au moins un chiffre), et bien il faut reprendre le calcul avec ce nombre jusqu'à tomber sur un chiffre unique.
PS : j'ai aussi mis dans le code, une fonction qui décompose la date comme tu le disais dans ton message, c'est à dire que le nombre de départ, c'est le jour plus le mois plus l'année.
Je suis aussi sous linux, et je n'ai pas ce problème.
A mon avis, c'est ton firefox qu'est bugué :)
La textearea a une taille prédéfinie pour rentrer en 800x600 pixels.
Pour ton problème d'insertion de message, je ne vois pas trop comment expliquer le problème vu que je n'ai rien changé.
