John_attend

Bonjour à tous,

Je crois que tout est dans le titre. Je suis à la recherche d'une classe PHP (ou d'un script tout fait) qui convertit un fichier Excel en HTML, avec conservation intégrale des couleurs et de la mise en forme.

Je souhaiterais faire quelque chose un peu comme la fonction "View as HTML" intégrée à Gmail qui permet d'afficher les fichier Excel, Word etc. sans avoir besoin de les télécharger. (mais juste le cas Excel m'intéresse)

Je vois beaucoup l'inverse sur Internet, mais pas vraiment XLS => HTML...

Merci d'avance de l'aide que vous pourrez m'apporter

Fonctionne parfaitement sur Firefox 3.

Sous IE 7, il fonctionne à l'affichage sur la page mais pas à l'affichage dans les infobulles (le caractère n'est pas reconnu dans les infobulles).

Pas testé sur les autres navigateur

KaRaK > Justement la fonction que tu me propose permet de faire des césures, moi c'est tout le contraire que je veux (je veux empêcher les césures provoquées par les tirets).

jcaron > Merci !! C'est exactement ce qu'il me fallait

Merci à vous!

Bonjour à tous,

Lorsque l'on affiche un texte dans une page HTML, le tiret (ou trait d'union) "-" peut faire faire des sauts de lignes automatiquement.

Comment faire pour empêcher cela ?

Je voudrais que le tiret soit considéré comme toutes les autres lettres, c'est à dire comme un caractère ne pouvant pas donner lieu à la coupure d'un mot entre deux lignes.

Merci d'avance.

Si tu restaures le dump sur une autre base temporaire je vois pas pourquoi cela affecterait les tables de la base principale...

Par contre penses bien à préciser un nom de base différent que celle sauvegardée lors de la restauration, sinon ça va tout restaurer sur ta base principale

Ok, c'est aussi ce à quoi j'avais pensé.

Merci de vos réponses

Bonjour à tous !

Mon problème est simple. Pour mes export de base de données, j'utilise la commande mysqldump en sauvegardant toute ma base de données.

Pour la restaurer à partir de ces backup, j'utilise la commande mysql database < fichier.sql.

Mais j'aimerais ne pouvoir restaurer que certaines tables. Je sais qu'il n'est possible d'exporter que certaines tables avec mysqldump, mais je ne vois pas comment ne restaurer que certaines tables.

Il n'est par exemple pas possible de faire mysql --database=mabase --tables table1 table2 table3 < fichier.sql.

Quelqu'un saurait comment faire ça ??

Merci d'avance

Bonjour à tous !

Mon problème est très simple. J'essaye d'exécuter un script PHP5 avec la commande system, mais ça ne fonctionne pas :

system("/usr/local/bin/php-v5 /home/monsite/www/monscript.php5");

Voilà ce que renvoit ce code :

Status: 404

X-Powered-By: PHP/5.1.6

Content-type: text/html

No input file specified.

Le fichier contenant le code se trouve dans /home/monsite/www/.

J'obtiens à chaque fois une erreur 404, quelque soit le répertoire que je met en paramètre.

Quelqu'un a une idée ? Après avoir tout essayé, je sèche complètement.

Petite précision : vous me direz surement qu'il s'agit réellement d'une erreur 404. Mais quand je tape :

/usr/local/bin/php-v5 /home/monsite/www/monscript.php5

sous putty, ça fonctionne bien. Sous la commande PHP system, non.

Merci d'avance de l'aide que vous pourrez m'apporter

Merci de vos réponses

La liste n'est pas longue comme le bras, je n'ai donc pas à m'inquiéter.

Ce sont des processus qui sont terminés, mais dont le parent n'a pas été averti de cet état (quelle qu'en soit la raison)

Comme ils sont déjà terminés, on ne peut donc pas les "killer"

Mais alors concrètement, qu'est ce qui provoque cela au niveau des scripts PHP ? Est ce que je peux changer quelque chose dans mes scripts pour arrêter de voir ces zombies ? Cela va peut être vous paraître bête, mais cela n'aurait il pas un rapport avec la fonction PHP exit() qui arrête l'éxecution ?

Bonjour tout le monde,

Quand j'utilise la commande top sur putty, il n'est pas rare de voir ce genre de ligne :

22970 mysite  17   0	 0	0	0 Z	2  0.0   0:00.07 php-v5 <defunct>
15488 mysite  17   0 28420 8004 6416 R	2  0.2   0:00.06 php-v5
19339 mysite  17   0	 0	0	0 Z	1  0.0   0:00.03 php <defunct>

J'aimerais savoir ce que signifie le "defunct" qui survient visiblement avec certains scripts PHP ou PHP5. Qu'est ce que ça signifie concrètement ? Doit on s'inquiéter quand on voit ce genre de chose ou est ce que cela signifie forcément qu'il y a un problème ? En cherchant sur Google je ne trouve pas réellement la réponse à cette question.

Merci d'avance

Bonjour à tous les webmasters du Hub !

Afin d'optimiser les performances de l'espace membre de mon site Web, je stocke les informations principales du membre dans des variables de sessions (exemple : pseudo, id, etc). (au lieu de faire une connexion à MySQL à chaque fois)

Toutefois, mes fichiers de sessions commence à atteindre à un nombre de 30 variables dont certaines sont des tableaux d'entiers pouvant contenir eux même jusqu'à 20- 25 entiers...

Au final, ça ne fait pas forcément un fichier très gros, mais un fichier avec beaucoup de variables.

J'aimerais avoir votre avis, pensez vous que cela peut atténuer les performances du serveur ??

(c'est un Bixeon qui peut accueillir 400 - 450 connectés simultanément).

Sachant que je fais un session_start sur la quasi totalité des pages (donc désérialisation de la session sur chaque page).

Je ne demande pas exactement si c'est possible avec mon serveur mais si en règle général le nombre de variables influe beaucoup sur les performances (ou si c'est plutôt la taille du fichier de session en octets).

Merci d'avance de votre avis

PS : Au cas où, pensez vous que le fait de répartir ces fichiers de sessions dans plusieurs répertoires temporaires peut pallier à ce problème ??

Pour ceux que ça intéresse, je viens de trouver une info super importante (enfin, à mon goût).

Avec MySQL 4, si vous avez un champ non signé auquel vous soustrayez une valeur plus grand que la valeur déjà dans le champ, cette valeur deviendra 0.

Alors que sous MySQL 5, cette valeur prendra taille_max.

Exemple, vous avez un champ int(11) "nombre" non signé qui vaut 4.

Sous MySQL 4, si vous faites UPDATE SET nombre = nombre - 5; alors nombre vaudra 0.

Sous MySQL 5, la valeur prendra 4294967295.

Imaginez les bug...

Merci, je vais regarder ça plus en profondeur

Bonjour à tous,

Dans quelques temps, je compte changer de serveur MySQL, et par la même occasion upgrader la base de données de 4.x vers 5.x. J'ai déjà entendu des echos comme quoi il n'y avait aucun problème de comptabilité entre les requêtes SQL, qui fonctionnent sur MySQL4 et ces mêmes requêtes sur MySQL5.

Toutefois, je ne compte pas faire ça à la légère, si je dois changer de version ça concernera les quelques dizaines de milliers de membres du site concerné. Bien sûr, je compte d'abord tester toutes les requêtes (tous les scripts) sur ce nouveau serveur, avec cette nouvelle version. Mais j'appréhende que quelque chose m'échappe.

En fait, y a t'il quelque chose qui fasse que, dans un certain cas, une requête qui fonctionnait sous MySQL 4 ait des réactions imprévisibles sur MySQL 5 ? Une infime modification qui fasse qu'une syntaxe soit interprétée differement, je sais pas... Toute info est bonne à prendre.

... et je vous serais reconnaissant des info que vous pourrez m'apporter

John

Sois réaliste ! Au tarif de l'hébergement mutualisé, tu espères quoi pour moins de 30 HT par mois ?

J'espère que mon site ne sera pas coupé pendant plusieurs jours et / ou qu'il n'aura pas de coupure de plusieurs heures plusieurs fois par mois. J'espère également ne pas avoir a contacté le support pour que le problème se règle de lui même. Est ce vraiment exigeant ?

C'est à dire qu'il faut t'attendre à 8H45 de coupure ou indisponibilité par an.

Et le rêve devient réalité

Mais est ce vraiment respecté ?

D'autre part, et le titre de mon sujet était peut être trop précis, je ne cherche pas à tout prix à savoir si l'uptime en lui même est bon, mais si le service est bon, d'une manière générale. Est il arrivé qu'une perte de données résulte d'une coupure des serveurs (mutualisé) ? Ou leur infrastructure est elle prévue pour pallier à ces problèmes ?

xgamer soulève dailleurs un problème important qui ne concerne pas l'uptime :

quand on envoit un mail avec la fonction mail() en php c'est pas sur du tout qu'il arrive

C'est ce genre de petits problèmes en plus qui m'intéresse aussi. A quoi est ce due ? Un client d'OVH doit il se faire à l'idée d'oublier la fonction mail ?

Enfin, Leonick aborde un sujet intéressant.

Sur certains de mes GP (60 et 300), j'ai de temps a autre des problèmes de connexion sur la BDD ou sur le site, alors que sur un 90Plan, ça n'arrive que très peu, du genre 4 ou 5 fois dans l'année.

Le service est il meilleurs chez les PLAN que chez les GP ? Ce n'est pas forcément évident en théorie... Mais en pratique ?

Je ne cherche pas à dénigrer OVH, au contraire, si on ne pouvait m'en dire que du bien je n'aurais pas d'hésitation.

Merci de vos réponses

Bonjour à tous,

Il y a quelques années encore, j'avais des sites hébergés en mutualisé chez OVH, et j'en était content. La gestion était simple, je n'avais pas énormément de downtime ni de ralentissement, en gros je n'avais quasiment jamais de raison de contacter le support technique. J'envisage de revenir vers le mutualisé d'OVH dans les mois à venir. J'ai donc commencé à faire mes petites recherches sur internet pour savoir ce que les gens en pensaient étant donné que mon point de vue n'était pas très à jour.

Et maintenant je ne sais plus trop quoi penser... Il m'arrive de lire que certains ont des sites hébergés en mutualisés (90 ou 240plan) et qu'ils ont régulièrement des coupures de leurs sites Web, parfois même jusqu'à plusieurs jours. Je considère qu'en mutualisé on ne doit jamais avoir à se prendre la tête avec des coupures ou des innaccessibilités de son site. Un downtime d'une heure est pour moi déjà ENORME, je n'arrive même pas à le croire... Et d'un autre côté, il y a les biens heureux d'OVH...

J'aimerais donc avoir un point de vue réellement objectif de votre part que se soit de votre expérience personnelle ou de celle de vos collègues / ami(e)s. Attention : je parle bien du mutualisé, notamment de l'offre qui m'intéresse, à savoir XXL Plan.

- L'hébergement mutualisé de OVH est il réellement de qualité ?

- Y a-t-il souvent des problèmes ?

- A quelle fréquence ?

- Des problèmes de quel type ?

- Ces problèmes sont ils résolus rapidement ?

- Je me souviens avoir déjà eu des problèmes injusitifés avec Okillerd, le support technique avait corrigé le problème quelques semaines après, avez vous des anecdotes de ce type à raconter ?

Plus généralement, j'aimerais être au courant de toutes les mauvaises surprises sur lesquelles je pourrais tomber en étant hébergé sur un XXL Plan OVH. Mon état d'esprit étant "je ne dois jamais avoir à toucher à mon site, tout doit être stable et fonctionner sans aucune intervention quelqu'elle soit de ma part". Est ce vraiment possible ?

Merci de me donner votre opignon

par contre si tu etait listé sur SPAMHAUS , la tu n'aurrait plus qu'a changer d'adresse

Il y a encore quelques jours mon site était black listé chez SPAMHAUS (mon serveur n'était pas en cause mais d'autres de mon hébergeur).

Après négociation de mon hébergeur je ne suis plus blacklisté.

A ta place j'irais plutôt voir par ici : http://openrbl.org/client/

Regarde si l'IP de ton serveur n'est pas bannie quelque part.

Tu peux également passer le nom de la session par GET. Donc là aucun cookie n'est utilisé.

Merci

Ok, merci de vos réponses, même si ça dérive un peu sur la fin

J'aimerais quand même que vous me confirmer quelque chose, je vais faire simple et vous allez comprendre pourquoi je posais la question, voici un morceau de script :

<?php

// On vérifie que l'entrée de l'utilisateur se situe bien aux bornes souhaitées

if($_GET[numero] >= "0" && $_GET[numero] <= "30")
{
$requetesql = 'UPDATE table SET numero=''.$_GET[numero].'' WHERE num="5"';

// Ensuite on execute la requête SQL, peu importe comment

}
else
{
echo 'Erreur !';
}

?>

Vous comprenez peut être mieux maintenant le but de ma question. Y a t'il ici un risque de SQL Injection avec la variable numero ?

Je préfère être sûr...

Merci

Bonjour à tous,

Voici quelques lignes de code :

<?

if($var >= "0" && $var <= "30")
{
echo 'La variable $var est un nombre';
}

?>

Est ce que ces lignes équivalent EXACTEMENT à ces lignes :

<?

if($var >= "0" && $var <= "30" && is_numeric($var))
{
echo 'La variable $var est un nombre';
}

?>

En gros, est ce que le fait de mettre $var >= "0" && $var <= "30" voudra forcément dire que $var est un nombre, y a t'il un moyen de contourner cela, c'est une question de sécurité quant à la vérification des entrées de l'utilisateur.

Merci d'avance

PS : Je me demande s'il n'y a pas une exception qui puisse contourner cette vérification.

Je ne stocke pas le message dans le fichier de session mais juste la valeur booléenne qui indique que l'utilisateur à un (des) nouveau(x) message(s).

Le message lui est stocké dans une BDD, simplement je veux pas avoir à vérifier à chaque page dans la BDD si il y a un nouveau message.

Mais je suis d'accord avec toi quand tu dis que la session n'est pas faite pour ça

C'est faisable avec PHP + Javascript

D'abord je voudrai savoir si le fait de créer des include allège vraiment le poid des pages et le temps de traitement

Pour répondre à ta première question : non, les includes ne vont pas alléger la page renvoyée au navigateur

En effet, l'include n'allège pas le poids des pages mais accélere le temps de traitement lorsqu'il est bien utilisé.

Je ne suis pas sûr de ce qui va suivre, il te faudra donc confirmer cela auprès de quelqu'un qui s'y connait un peu mieux dans le fonctionnement de PHP. Il me semble que lorsque tu inclu des pages à répétition, PHP met "en cache" ce traitement, et donc ça va plus vite. Je ne sais pas si ça fonctionne exactement comme ça, mais include à d'autres avantages que d'être pratique (qui est déjà un grand atout)