SStephane

J'arrive un peu tard, dans la discussion, mais je pense que s'appuyer sur akismet ( http://akismet.com/ , gratuit pour un perso ) et stopforumspam (gratuit), retire une bonne partie du traffic illégitime (99.99%).

Je gérai un forum (il y a environ 2 ans, phpbb, 1M de messages), et je crois qu'il y a eu un spam en 1 an, surement manuel. J'avais également une surcouche qui demandait une modération a priori sur le premier message d'un membre ce qui faisait tomber le compte à 0 (il y a le meme dispositif sur les forums symfony http://forum.symfony-project.org/ si tu veux voir à l'oeuvre, cela dit, ça peut donner du travail : http://forum.symfony-project.org/viewtopic.php?f=23&t=76454 ).

Akismet & stopforumspam pour diminuer les taches de modération, et la modération a priori du premier message pour finir le travail.

Les questions & les captchas, ça fonctionnait moyen (je pense que certains spammeurs inscrivent à la main). En plus, si un catcha n'est pas presque illisible, la reconnaissance de caractère peut fonctionner, et s'il l'est, c'est limite chiant pour l'utilisateur

Hello,

Franchement, on peut pas te dire. Si la lecture d'un message pose problème, c'est plus le message complet qu'il faut poster (en PJ, pas en copier/coller par ailleurs), mais quoi qu'il en soit, il faudra certainement te dépatouiller toi-même tant les fonctions auxquelles tu fais appel sont rarement utilisées.

Au pif, je dirai des caractères zarbi dans les headers qu'il te faudra traiter à la main puisque tu utilises les fonctions nâtives de PHP, et les primitives de PHP dans le domaine du mail sont pas top.

<?php //troll

Je comprends la joie que peut procurer le développement from scratch (encore que), mais même si les protocoles mails n'évoluent fondamentalement pas des masses, il me parait quand même plus aisé d'utiliser quelque chose pour abstraire ce type de traitement (genre imap_open, imap_fetchheader, mysql_query ou PDO...).

http://framework.zend.com/apidoc/1.0/Zend_Mail/Zend_Mail_Storage_Imap.html

http://framework.zend.com/apidoc/1.0/Zend_Mail/Zend_Mail_Message.html

(exemple)

fais un phpinfo() et vérifies que display_errors est sur on. Vérifie aussi error_reporting

#!/usr/local/bin/php

J'ai du mal à piger vu ce qu'il y a derriere, tu veux pas plutot ecrire #!/bin/bash ?

dans tous les cas si tu veux tracer une commande, tu n'a qu'à ecrire dans un fichier de log :

sh machin.sh >> log.txt

">" pour ecrire dans un fichier, ">>" pour ecrire à la suite, ce qui est surement ton cas.

Vu que les modules de paiement des principales banques existent déjà avec prestashop, je dirai très peu de temps.

Dans tous les cas, ce n'est pas bien complexe à développer; après ça dépend essentiellement d’où tu pars.

http://home.snafu.de/tilman/xenulink.html pour trouver tes liens internes 404.

C'est vrai qu'il y a toujours un hic, redkite j'aime autant éviter, un CMS simple pour coller un gros symfony derrière, on va à l'encontre de l'esprit du machin

Madsimple n'a pas de gestion de document très correcte je trouve

Hello,

Non c'est plus au sens content type, ça peut donc être n'importe quoi ! (une page avec des champs personnalisés donc )

Hello,

Je recherche un CMS pas vraiment particulier et attends des retours utilisateurs. Je vais lister par liste d'importance mes attentes. Ce CMS doit se contenter de faire de la gestion de contenu, et uniquement de la gestion de contenu (article, page etc...). Pas forcément de blog, pas de forcément sondage pas forcément de boutique intégrée.

Voilà longtemps que je cherche un CMS pour les petits projets; je suis adepte d'eZPublish et ne réalise que rarement de petits projets, c'en est un. Ce CMS doit être très simple mais posséder les caractéristiques suivantes : (en gras les bloquants)

Niveau fonctionnalités :

1. Un wysiwyg avec gestion de documents (images etc.)
   
2. doit permettre de gérer des types de contenu dans l'admin (content type comme on dit dans drupal, classe dans eZ etc.)


3. doit éventuellement gérer les utilisateurs et les workflows (niveau d'édition etc.)


4. Idéalement le même genre de système de gestion de contenu que Drupal dans le front.


5. Belle UI d'admin et facile à prendre en main pour des rédacteurs (pas joomla, pas eZ, pas drupal, pas wordpress, pas 90% des CMS)


6. multilingue (pour ce projet pas de souci)


7. multisite (ce serait top)

Développement :

1. Un core très facile à prendre en main (genre wordpress) : facile à étendre et à plugguer


2. Un système de gestion de template fiable et faisant autorité (smarty, twig etc. ou directement php)


3. Idéalement full objet (ou presque)

Maintenance :

1. CMS avec de l'âge (>4-5 ans) : pas l'âge de la version, mais de l'éditeur
   
2. Un kernel très fiable avec peu de mises à jour (2/an max) : j'ai pas dît non maintenu


3. Je souhaite que le core du CMS possède tout ce dont j'ai besoin ou presque : pas de plugin additionnel, si je dois développer un peu,pas de souci. (Ce CMS ne s'appelle donc pas Drupal; si j'apprécie la manipulation de ses API, je vomis la philosophie du tout plugin à autorité communautaire.


4. Léger

Je connais bien les frameworks zend, codeigniter et sf2 si vos propositions sont basées sur des frameworks, mais un truc parfait sur cake ne me rebute pas

Mes choix éventuels: cmsmadesimple (que je ne connais que de nom), http://redkite-labs.com, symfony CMF (si je trouve pas)

Dans ce cas vous pouvez déclarer un 410 comme on me l'a suggéré naguère. Mais google les traite comme des 404 (ça prend des mois à disparaitre dans GWT).

Si ces URLs ont un truc en commun, vous pouvez toujours faire une redirection 301 sur celles-ci en une ligne.

Sur le principe tu as, elles vont disparaitre un jour; je ne suis pas spécialiste, mais je dirai qu'il ne faut pas "marquer comme corrigé" si tu n'as pas pris les devants en mettant en place des redirections 301.

Si tu ne marque pas comme corrigé, ça peut durer des mois, et bien que n'étant pas spécialiste du référencement, je peux t'affirmer qu'il y a un forte pénalité sur les moteurs pour ça (moult expériences clients).

De plus, tu ne peux maîtriser totalement les erreurs 404 de ton site (ça peut venir d'un lien provenant d'un site tiers).

Le mieux dans tous les cas est de faire des 301, je t'invite à faire une recherche sur le forum et à regarder notamment dans la section .htaccess et apache (si tu es sous apache)

Alors, je me répète, mais soit c'est des constantes, et c'est dans le fichier de constantes, soit c'est des données variables partagées et à ce moment là ça n'existe pas en PHP nâtif (pas plus avec codeigniter qu'un autre framework).

Tu parles de partager des variables entre plusieurs sessions utilisateurs. Les variables globales ne conviennent pas car leur portée est limitée à l'exécution du script en cours. Si tu cherches à partager des données sur plusieurs processus, regarde du côté des sémaphores http://fr2.php.net/manual/fr/intro.sem.php.

Mais franchement, je suis curieux de savoir quelles données tu peux avoir envie de partager pour gagner en performance par rapport à MySQL.

PS : si une requête met du temps à répondre parce qu'elle est particulièrement couteuse et récurrente, il y a aussi memcache http://www.php.net/manual/fr/book.memcached.php

S'il s'agit d'affichage, varnish.

QU'apelle tu des variables de portée application ? (si c'est une globale, $GLOBALS, comme en PHP ..; mais j'ai des doutes sur ton utilisation).

Ou alors il s'agit de constante, et tu as un fichier dans la conf où les stocker, de mémoire.

Tu n'as pas autre chose dans ta query string ? (il sert à quoi le NC dans ta règle du bas ?)

Ça dépend de l'infogerant. Généralement il s'occupe :

- de la santé de ton serveur et des services qu'il installe

- des mise à jour des services

- de configurer le serveur niveau sécurité

- des backups selon ton contrat (fichiers bdd...snapchots etc.)

Généralement un tarif mensuel/annuel pour cela.

Certains ne proposent que des installations de services aux tarifs attractifs pour les néophytes ; ne t'engage pas la dedans (avis personnel) : il est important d'avoir une notion de co-responsabilité dans le rapport gérant/gere (c'est d'ailleurs cette responsabilité de l'info gérant qui coûte cher).

Cependant, Il ne sera pas responsable de la couche tierce que tu y ajouteras sauf s'il s'y engage (suicidaire quand même) : en gros, si ton prestashop se fait hacker, ce n'est pas de son ressort s'il a pris toutes les dispositions qui le concerne.

Je pense qu'une des missions de l'infogérant reste néanmoins le conseil. Il est donc important que celui que tu choisis ait une bonne connaissance générale de prestashop (du web) et de ses évolutions pour savoir t'orienter vers des choix pertinents.

si tu prospères sur le net encore davantage, un seul serveur ne te suffira plus; c'est alors ton infogérant qui devra te conseiller sur la stratégie d'hébergement à adopter.

Après, ton hébergement actuel est-il vraiment trop faible (question sous jacente, non ?) ? Impossible de répondre, il y a trop de facteurs qui nécessitent une petite analyse trafic, sources...). Ce qui est sur, c'est que le mutualise à ses limites ; si tu comptes faire évoluer cette activité sur le net, tu ne pourras pas y rester éternellement.

Pour la croissance de ton bébé, seule toi a la réponse de savoir si le modèle sur lequel tu vas t'engager est économiquement viable avec en plus des frais d'infogerance ! En tout cas, techniquement, le bébé en question peut croître

Tout d'abord, $(".action_suppression_type_libre") & $(".suppressionchamps") ne sont pas des fonctions mais des sélecteurs. Ils retournent un/des pseudo(s) objet(s) jquery enrichis par rapport à ceux de JS.

Lorsque tu poses un écouteur sur ".action_suppression_type_libre" (sur l'événement clic), cet objet n'est tout simplement pas dans le DOM, donc en gros, le selecteur $(".action_suppression_type_libre") est vide. En gros ce code ne sert à rien :

$(".action_suppression_type_libre").click(function(){

alert('test');


return false;

});

});

Une façon plus correcte serait :

$(document).ready(function(){

	$(".suppressionchamps").on('click', function(){

		$('#valeur1').html('<div class="action_suppression_type_libre">OUI</div>');

		// là il existe

		$(".action_suppression_type_libre").on('click',function(){

			alert('test');

			return false;

		});

	});

});

Je ne saurais que trop te recommander de te familiariser avec DOM et JS nâtif avant de te lancer dans jQuery.

Hello,

J’envoie des mails à partir d'un cron via sendmail. Le cron execute un fichier PHP qui utilise PHPMailer pour envoyer le mail.

Les mails arrivent en spam chez gmail (et peut-être d'autres).

Je précise, le serveur n'est pas blacklisté par les RBL (listés sur mxtoolbox en tout cas); la signature DKIM & le SPF est ok comme en atteste ces lignes :

Received-SPF: pass (google.com: domain of contact@exemple.com designates xxxx:xxxx:x:xxxx::1 as permitted sender) client-ip=xxxx:xxxx:x:xxxx::1;

Authentication-Results: mx.google.com;

       spf=pass (google.com: domain of contact@exemple.com designates xxxx:xxxx:x:xxxx::1 as permitted sender) smtp.mail=contact@exemple.com;

       dkim=pass header.i=contact@exemple.com

En fait j'ai un doute sur un header ajouté par sendmail (que je n'arrive cependant pas à virer) :

Received: (from cronjobs@localhost)

	by ns.exemple.com (8.14.4/8.14.4/Submit) id s0CHA9iq008104;

	Sun, 12 Jan 2014 18:10:09 +0100

Ce doute est-il fondé d'après vous ? (cronjobs est l’utilisateur linux qui exécute la tâche)

Comment peut-on virer cette %!ù^# d'en-tête sur sendmail ? (uniquement sendmail, pas de postfix d'installé)

Voici toute l'en-tête au cas ou :

Delivered-To: XXXXX@gmail.com

Received: by 10.217.54.199 with SMTP id t49csp72183wew;

        Sun, 12 Jan 2014 09:10:09 -0800 (PST)

X-Received: by 10.180.36.78 with SMTP id o14mr9041368wij.51.1389546609850;

        Sun, 12 Jan 2014 09:10:09 -0800 (PST)

Return-Path: <contact@exemple.com>

Received: from ns.exemple.com ([xxxx:xxxx:x:xxxx::1])

        by mx.google.com with ESMTPS id bm3si8109728wjc.125.2014.01.12.09.10.09

        for <XXXXX@gmail.com>

        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);

        Sun, 12 Jan 2014 09:10:09 -0800 (PST)

Received-SPF: pass (google.com: domain of contact@exemple.com designates xxxx:xxxx:x:xxxx::1 as permitted sender) client-ip=xxxx:xxxx:x:xxxx::1;

Authentication-Results: mx.google.com;

       spf=pass (google.com: domain of contact@exemple.com designates xxxx:xxxx:x:xxxx::1 as permitted sender) smtp.mail=contact@exemple.com;

       dkim=pass header.i=contact@exemple.com

Received: from ns.exemple.com (ns.exemple.com [127.0.0.1])

	by localhost.localdomain (8.14.4/8.14.4/Debian-4) with ESMTP id s0CHA9DZ008105

	for <XXXXX@gmail.com>; Sun, 12 Jan 2014 18:10:09 +0100

Received: (from root@localhost)

	by ns.exemple.com (8.14.4/8.14.4/Submit) id s0CHA9iq008104;

	Sun, 12 Jan 2014 18:10:09 +0100

DKIM-Signature: v=1; a=rsa-sha1; q=dns/txt; l=18229; s=contact;

	t=1389546609; c=relaxed/simple;

	h=From:To:Subject;

	d=exemple.com; i=contact@exemple.com;

	z=From:=20=3D?UTF-8?B?U01BUlRmaWNoZXMgTcOpZGVjaW5l?=3D=20<contact@exemple.com>

	|To:=20XXXXX@gmail.com

	|Subject:=20=3D?UTF-8?B?QmllbnZlbnVlIHN1ciBTTUFSVGZpY2hlcyBNw6lkZWNpbmU=3D?=3D;

	bh=iiJzWW5dgQMz9fRDFs107OW9Azs=;

	b=x1l4oCGGVNl5HmlKXnVPupFZgEbOTHRC/hR0r9RXqnZhc1MBCN4wCAuYIEilFZtScIhfDKLRVz7yyHDjrJ7xcKu+6D+y7hXV8EB53rt0IHMIhhrxU8CECQtATtxamvcJKiaHYMzJ6YoMvBAOQiZdxYTIctCwJ7XWziUCxQ4FnO0=

RewriteCond %{HTTP_HOST} !s\.mon-domaine\.com

RewriteRule /?s/(.*) http://s.mon-domaine/$1 [QSA,L,R=301]

Tout simplement non ?

Un réponse de dev qui vaut ce qu'elle vaut :

A) Site neuf : J'ai une idée géniale et le temps pour la développer (rêvons un peu), j'estime le tout à pas moins que :

1. le prix du dev (rapport à mon temps passé, estimable)


2. le prix de l'idée (subjectif)


3. éventuellement sa popularité s'il y en a une (au prix du marché si ça s'évalue).

Partons du postulat que je crois en mon idée (vaut mieux si j'ai passé un mois dessus).

Chercher un acheteur plutôt qu'un investisseur, pourquoi faire ? (faudrait être simplet pour investir son temps (1) dans un truc qui me rapporte pas plus que mon temps "normal" de production). Pour me faire vendre, faut que tu m'achètes l'idée (2) un prix qui va tout de même me convaincre de vendre (disons, au minimum mon espérance mathématique dans mon calcul interne).

Ou alors, j'arrive plus à rembourser mon crédit relai

tu achètes un site bien établi

Le problème c'est que je ne peux pas me permettre de lancer un site de zéro et devoir attendre plusieurs années avant d'avoir des revenus. J'aimerais pouvoir racheter un site déjà bien établi.

Je pense comme Arlette, tu achètes une entreprise, et tu devras forcément attendre avant d'être dans l'excédent. Dans tous les cas, je pense qu'il faut apporter quelque chose pour que cet excédent voit le jour. OUtre les charges fixes (maintenance etc.), prévoir 5 ans d'exploitation rentable sur un jeu d'élevage sans évolution logicielle me paraît hard (enfin ça j'en sais trop rien).

Je n'ai aucune idée de comment est évalué le prix d'un site "établi", mais j'aurai tendance à analyser le bilan, les relais de croissance possibles et certains chiffres qui ne te sont surement pas inconnus (ebe etc.). Jouer sur un service inexploité par son propriétaire pour en tirer un prix correct, malheuresement, j'ai peur que les entreprenneurs du net soient peu à prendre leur retraite encore aujourd'hui

Le mieux n'est-il pas d'approcher les propriétaires des sites qui t'intéressent plutôt ? Je ne suis pas certain que les entreprises en place mettent en vente leurs vaches à lait (d'après ta description, c'est ce que tu cherches) mais plutôt leurs poids morts .

Euh, aucune idée, mais tu n'as pas grand chose de plus à faire que ce que je t'ai déjà expliqué : t'ajoutes une ligne au hosts, et tu configure correctement apache avec les virtualhost

RewriteEngine on

RewriteBase /PERSO/mon_dossier

RewriteRule ^accueil$ /PERSO/mon_dossier [L,R=301]

RewriteCond %{QUERY_STRING} ^$

RewriteRule ^/?$ ?slug=accueil [L]

RewriteRule ^([a-z0-9\-]+)$ ?slug=$1 [L]

Et oui pour le hosts, j'ai une ligne par projet.

Le mieux lorsque tu développes, c'est d'avoir un environnement de dev le moins différent de ton envirronement de production. Ca t'évitera déjà d'avoir des soucis lors du déploiement de tes sites.

En clair, cet exemple fonctionnera pour www.tonsite.com/?slug=truc, mais pas sur ton environnement de dev, ce qui est fort regrettable... mais passons.

Tu travailles manifestement dans un sous-dossier du domaine localhost, genre http://localhost/machin

Dans ce cas :

RewriteEngine on

RewriteBase /machin

RewriteRule ^/?$ ?slug=accueil [L]

RewriteRule ^accueil$ /machin [L,R=301]

RewriteRule ^([a-z0-9\-]+)$ ?slug=$1

En remplaçant machin par ton sous-dossier, ce sera surement ok. Mais ça t'impose de changer à chaque déploiement, et c'est franchement laid.

Si tu souhaites creuser, je te recommande ce que j'impose à ceux qui bossent avec moi : edites ton fichiers hosts (c:\windows\system32\drivers\etc\hosts sur windows; /etc/hosts sur mac & unix) et ajoute le domaine final que tu vas utiliser pour le faire pointer en local - 127.0.0.1- . (change l'extension, si tu n'as pas envie de jouer avec l'hosts à chaque déploiement, genre www.tonsite.dev ). ce qui donne :

127.0.0.1   www.tonsite.com

Ensuite crée un virtualhost dans apache de la même manière que ce sera très certainement fait dans ton environnement de production.

<Virtualhost  *:*>

 DocumentRoot "F:\www\tonsite"

 ServerName www.tonsite.com

</VirtualHost>

(ajouter un namevirtualhost avant si ce n'est déjà fait dans la conf)

Ainsi, tu n'as pas à te poser la question de savoir si t'auras des problèmes de path ou non quand tu déploieras en production.

enlève le "test" qu'il y a dans ton htaccess

RewriteEngine on

RewriteRule ^/?$ ?slug=accueil [L]

RewriteRule ^accueil$ / [L,R=301]

RewriteRule ^([a-z0-9\-]+)$ ?slug=$1

Un truc comme ça devrait suffire à vue de nez