maximettb

Disons que la seule manière d'être réputé, c'est d'être présent sur la scène locale avant d'être bien présent sur Google ! Le site d'un groupe amateur, ainsi que des groupes et artistes professionnels, est d'offrir un support d'information pour rester en contact avec l'artiste ( prochaines date, réactions suite à un concert/tournée, les prochaines sorties, où trouver les albums, etc. ) par le biais du site directement, mais également et peut-être plus efficacement via une newsletter ou un fil RSS ( très important, car c'est le seul biais par lequel les personnes intéressée peuvent se tenir informées des nouvelles ) . Un site de groupe n'a pas vocation à vendre ou de service autre à proposer, il n'a donc pas lieu d'être réputé. À mon avis, le meilleur moyen est d'être très présent sur les forums de musiciens, sur des sites comme Jamendo, etc. Il est cependant essentiel qu'il arrivent premiers sur leur nom de groupe ! Mais si ce n'est pas un nom commun, quelques liens (respectueux) sur des forums ou des annuaires sera suffisant. Bonne chance à eux en tout cas.

Je voterai plus en faveur d'un seul gros site. Si ton site contient vraiment beaucoup d'informations, il vaudrait mieux en priorité passer du temps à faire un moteur de recherche pertinent et veiller à bien catégoriser les différentes formations et contenus afin que tous tes visiteurs y trouvent leur bonheur ! Les mini-sites, même si cela peut être très pratique pour le référencement, est au mieux luxueux, au pire inadapté : après tout, puisque tu as le contenu pour le mini-site, à quoi bon ne pas le fournir dans le site principal ? Cela dit, si tu décides de faire tout de même des mini-sites, il faut veiller à garder une structure et navigation cohérentes (mieux : identiques) entre tous ces mini-sites et ton site principal.

C'est entièrement logique, les caractères d'échappement sont supprimés dès l'insertion en BDD. Pour les garder dans ta base, il faut normalement faire un 2ème addslashes : $texte = addslashes(addslashes($donnees['texte']));

Bonjour à tous, Je voulais savoir si certains d'entre vous on déjà constater des baisses de vitesse significatives en incluant disons une quinzaine de fichiers PHP différents dans un même script ? J'aimerais nettoyer en profondeur mon site pour utiliser un système proche du MVC, pour totalement séparer les vues des contrôleurs et ainsi rendre mon travail plus rapide et flexible. C'est une habitude que j'ai en java que j'aimerais appliquer en PHP, mais je me demande si ce langage est vraiment adapté à cette utilisation. Merci !

Echo ne faisant que 4 lettres, il me semble logique qu'il soit plus rapide... à taper.

Techniquement, tu peux mettre autant d'index que tu veux sur une table. Cependant, il vaut mieux éviter de surcharger ta base d'index. À la longue, ça occupe beaucoup trop d'espace disque et, pire, risque de rendre certaines requêtes plus longue qu'avec des index judicieusement placés ( MySQL peut assez vite cafouiller s'il est confronté à des choix d'index lorsqu'il tente d'optimiser les requêtes ) . SELECT pr.ffusername,pr.birth, pr.sex,pr.photo,pr.photopath FROM ".$prefix."_user_profile AS pr JOIN ".$prefix."_user_photo AS ph ON pr.ffusername=ph.ffusername WHERE pr.approved=1 AND ph.approved=1 ORDER BY click DESC LIMIT 0,$numberofstars À mon sens, un seul index sur ffusername de la table user_photo est suffisant.

Le type TEXT est en effet totalement adapté à ta situation. Je ne vois pas trop en quoi il serait déconseiller d'y mettre de gros articles, après tout, ce sont des données comme les autres. Le type BLOB pourrait également fonctionner, mais est principalement destiné aux données binaires, donc déconseillé. L'avantage du type TEXT est également que tu peux l'indexer facilement pour être ensuite utilisé dans un éventuel moteur de recherche ( cf. index FULLTEXT ) , je ne l'ai jamais mis en application, mais ça a l'air pratique. Après, la question du cache... Je dirais que tout dépend de la fréquentation de ton site... Mais rien n'empèche de prévoir un système de cache tout de suite ! Quant à savoir si des articles de 16000 caractères feraient ramer le site, disons que quelques dizaines de ko qui circulent dans des serveurs l'un à côté de l'autre ( quand c'est pas directement en local pour certains hébergeurs low-cost ) , je vois pas vraiment le problème, à moins bien sûr d'avoir des centaines d'accès simultanés. Ce qui fait ramer une base, c'est avant tout les jointures bien gourmandes sur des 100aines de milliers voire millions d'enregistrements.

Pas de quoi. J'ai vu que tu utilises un OpenId. Comment ça marche exactement ? Tu pourrais faire quelques retours sur l'utilisation de cette technologie d'identification ? Merci.

Le design fait très apple.com ! J'aime bien ! ;-) Quelques remarques purement ergonomiques : Plutôt que de faire un lien rechercher en haut à droite, met plutôt directement une zone de texte avec un bouton rechercher, c'est beaucoup plus pratique et, surtout, visible. Un petit détail : le fil d'Ariane en haut quand tu parcours les photos est une bonne initiative, mais il vaut mieux préférer des ">" ( ou des flèches ) , qui sont plus compréhensibles pour une progression dans le site, que des "/" . Ne pas hésiter à souligner les liens ( ou au moins leur donner une couleur pour pouvoir les identifier comme tel ) . Par exemple, sur la page d'accueil, le texte "ou Découvrez les utilisateurs" n'est pas directement identifiable comme un lien. C'est d'autant plus destabilisant que le texte "Rechercher une photo" est exactement de la même couleur et police alors que ce n'est pas un lien. Quand je créé un nouvel album, disons "Mon Album #1" , il n'apparait pas immédiatement dans ma liste d'albums, ça nécessite un refresh. Je suis sous Safari, peut être un problème de compatibilité ? Par la même occasion, attention au charset : j'ai créé "Mon deuxième album" , mais il affiche mal par la suite le "è" . Le terme "Manager" peut ne pas être compris par tous, je suis pas sûr que ce soit un bon choix, d'autant plus si ce site peut s'adresser à des novices ( d'Internet, comme de la langue de Shakespeare ) . Proposer une alternative à l'applet java pour l'upload de photos, qui peut effrayer certaines personnes ( ce qui est compréhensible ) . Avoir un petit aperçu de la photo quand on est dans la liste des albums, si on veut en supprimer une dont on ne connais plus le numéro de photo donné par son appareil ( DSCN XXXXXX ) , on n'a pas forcément envie de toutes les voir les unes après les autres. D'ailleurs, je ne sais pas si c'est très naturel de mélanger dans les même onglets des aspects classement ( ie. "Vos albums" , "Mon premier album", etc. ) et actions ( "Envoyer des photos" , "Supprimer sélection" , etc. ) . En tout cas, ça m'a l'air vraiment sympa comme site, bonne présentation et l'autoscroll est bien pratique ! Bonne continuation ! Max

C'est plus un problème de présentation que de logique métier. Une requête SQL permet de récupérer les données, ensuite, c'est seulement à l'affichage que tu vas mettre en forme d'une manière ou d'une autre les données... À moins que je n'ai pas très bien compris ton problème.

Les goûts et les couleurs... C'est simplement une appréciation personnelle, si tes couleurs donnent un bon contraste pour lire correctement le contenu, il n'y a pas de problème ergonomique...

Pas mal cette fonction ! Bien pratique, je la garde sous le coude.

Au début, j'ai cru que tu avais fait des films sur Force Ouvrière ! Bienvenue à toi !

Un exemple de fichier ? Un petit SHOW CREATE TABLE aiderait aussi à résoudre ton problème.

À confirmer, mais la fonction mail de PHP est très basique et ne gère, à mon humble avis, pas l'envoi de mail "multipart" . En fait, quand tu veux envoyer un mail en texte + HTML, ou encore un mail avec pièce jointe par exemple, il découpe le message en plusieurs sections, une partie en mode texte et une partie en mode HTML pour ton cas. Or, la fonction mail n'accepte qu'un seul corp de message, c'est cela qui me fait dire qu'elle ne gére pas de tels message. Cependant, tu peux TRES facilement utiliser l'utilitaire sendmail à la place, qui lui sera capable de faire tout ce que tu veux, dont les messages "multipart" . PS : la fonction mail peut très bien envoyer des messages en HTML, il suffit de préciser dans les headers "Content-type: text/html" .

Ca dépend de beaucoup de choses. D'abord, vérifie que tu as accès au port MySQL de ton autre serveur dédié, si c'est ok, alors il ne devrait pas y avoir problème. En fait, il faut que l'utilisateur que tu utilises pour te connecter puisse se connecter de n'importe quel machine, alors que par défaut, seul "localhost" est autorisé. Pour cela, il faut que tu regardes du côté du champ Host de la table user dans la BDD mysql et le changer en "%" . Cette solution n'est cependant pas très sécurisée. Une solution un brin plus complexe, mais bien plus sécurisée consiste à créer un 2ème utilisateur autorisé uniquement à se connecter à partir de ton 2ème serveur.

Des sources de codes qui marchent et du code qui ne marche pas ? Ca nous aiderait grandement...

À mon avis, si ton site vient à contenir plus d'articles, il vaut mieux utiliser un index de type FULLTEXT, combiné à l'opérateur MATCH, bien plus efficace à mon avis.

Et pourquoi pas : $command = 'mysqldump --default-character-set=latin1 --h$host --u$user --p$password $database | gzip> /home/xxxxx/www/dump/$backup'; Ca me semble plus sûr si tu doutes du résultat. Après, faut voir si ta base de données n'est pas trop volumineuse, sinon, tu risques de dépasser la limite d'exécution du script PHP.

Contrôler les transactions entre les comptes, notamment ceux partageant la même adresse IP, et dissuader les transferts "suspects" ?

Ou alors un simple système de verrou en session, qui se met à 1 en début de page et revient à 0 à la fin. Après, l'idéal serait d'avoir des méthodes synchronisées comme en java, mais je ne pense pas que ce soit possible en PHP...

Idéalement, le charset de ta page et de ton champ doivent être identiques ! Pour appliquer un charset à un seul champ d'une table : ALTER TABLE matable CHANGE COLUMN monchamp VARCHAR(255) CHARACTER SET utf8; Quant au charset à utiliser, utf8 semble clairement le plus adapté... Au passage, il serait quand même plus "propre" d'utiliser un charset utf8 pour l'ensemble de ton site et l'ensemble de ta base de données.

Cela dit, en répétant inutilement plusieurs fois la même données, c'est surtout une question de place occupée. De plus, je suis quand même assez sceptique sur les performances. L'utilisation d'index numériques, plus petits que des noms de villes en varchar, sera beaucoup plus efficace.

Tu devrais peut-être afficher les numéros pour te joindre sur chaque page, non ?

J'utilise phpbb pour certains de mes sites, je n'ai jamais eu à m'en plaindre. Jusqu'à présent, si j'avais à choisir un forum payant, il est clair que j'aurais choisit vbulletin. C'est un forum qui a largement fait ses preuves et reconnu pour sa fiabilité, même avec une grosse charge de visiteurs. Cela dit, après avoir vu les vidéos, plus haut, de la future version de ipb, là, je dois dire que je suis vraiment bluffé!!! Tout simplement hallucinant!