Jump to content

oli004

Members
  • Posts

    32
  • Joined

  • Last visited

Posts posted by oli004

  1. Je remonte ce sujet uniquement pour donner une éventuelle solution que j'ai mis en place.
    En revanche, elle n'ai pas vraiment adaptée aux grosses boutiques ayant de nombreux produits dans chaque catégorie.
    Donc, pour éviter le duplicate qui apparaissait dans le webmaster tools de google, ma boutique le permettant car peu de produits, j'ai tout simplement vidé product-sort.tpl et pagination.tpl.

    Bien entendu il s'agit là d'une solution radicale, mais que le faible nombre de produits me permet de faire.

  2. Bonjour à toutes et à tous,

    Après avoir installé, configuré et personalisé une boutique voilà un peu plus de 2 ans, je suis en charge de migrer celle-ci vers une version plus ressente nottement pour beneficier des nombreux modules ajoutés dont les statistiques et bien d'autres.

    Je pense opter pour une reinstall complète avec refonte aussi du template, mais ce qui me freine ce sont les 800 et quelques produits que je ne me vois pas ressaisir à la main.

    Aussi, pensez-vous qu'un import des données de l'ancienne base (V1.0.0.8) concernant les produits et catégories puisse être appliquée ? et si oui, comment dois-je m'y prendre puisque la structure même des tables à évoluée ?

  3. Voici la solution au problème qui permet d'envoyer des fichiers joints d'un volume suppérieur à 2 Mo

    La réponse provient d'un autre sujet : http://www.prestashop.com/forums/viewreply/185020/
    (merci Midimix)

    Pour résumer : modifier admin/tabs/AdminAttachments.php

    (dans le Back Office)

    class AdminAttachments extends AdminTab
    { protected $maxFileSize = 2000000;

    et remplacer 2000000 par la valeur en octets souhaitée.

  4. Bonjour,

    Je rencontre le problème suivant :

    Lors de l'ajout d'un nouveau document joint, 3 erreurs :
    * Fichier trop volumineux, taille maximum autorisée : 2000 kb
    * le champ fichier est requis
    * le champ mime est requis

    POURTANT

    Lors de l'ajout d'un nouveau produit à télécharger, le transfert s'effectue sans erreur.

    Le problème semble donc se situer uniquement au niveau de la taille des documents joints.

    J'ai bien entendu adapté php.ini en specifiant
    * post_max_size : 100M
    * upload_max_filesize : 100M
    * max_execution_time : 9000
    * max_input_time : 18000
    et le phpini est bien pris en compte (vérification sur un fichier affichant la config du phpinfo)

    Le config.inc.php mentionne également : @ini_set('upload_max_filesize', '100M');

    J'ai même essayé d'ajouter les valeurs décrites dans le php.ini dans le config.inc.php de telle sorte que :

    /* Improve PHP configuration to prevent issues */
    @ini_set('display_errors', 'on');
    @ini_set('post_max_size', '100M');
    @ini_set('upload_max_filesize', '100M');
    @ini_set('max_execution_time', '9000');
    @ini_set('max_input_time', '18000');
    @ini_set('default_charset', 'utf-8');



    Mais sans succès.

    Je constate après maintes recherches sur le forum que ce problème semble récurent sans pour autant qu'une solution fiable ne soit évoquée.

    Je pense avoir exploité toutes les pistes mais je me heurte à ce problème de fichiers joints important car devant être utilisé pour joindre des documentations techniques pouvant atteindre une 60aine de Mo

    Quelle solution pouvez-vous de proposer pour régler ce problème ?

  5. Je remonte le sujet car étant confronté au même problème malgré une modification du php.ini pour passer post_max_size à 100M ainsi que upload_max_filsize à 100M aussi.
    Dans la foulée, le config.inc.php mentionne également en tête : @ini_set('upload_max_filesize', '100M');

    Je précise que l'affichage du phpinfo me confirme la prise en compte des post_max_size et upload_max_filsize à 100M.

    Lors du transfert d'un fichier joint :
    * Fichier trop volumineux, taille maximum autorisée : 2000 kb
    * le champ fichier est requis
    * le champ mime est requis

  6. Bonjour,

    Décidement, à chaque fois que je procède à l'installation d'une e-boutique prestashop, je me heurte à divers problèmes. Aujourd'hui, la liste des modules accédée depuis le BO est vide. Hors, le FO m'affiche bien par défaut la liste des produits phares ou encore le module "page d'accueil"

    La partie "positions" des modules me retourne une liste deroullante affichant "tous les modules" mais aucun n'apparait.

    Lorsque je clique sur "greffer un module", ça a pour effet de fermer le bandeau.


    Je précise que j'ai utilisé la dernière version (1.2.5), que l'installation s'est déroulée sans soucis, tous les checks au vert

    J'utilise un serveur dédié kimsufi (ovh, avec une release 2 gentoo) sur lequel ne se trouve pour le moment que la boutique, php version 5.2.5 et mysql 5.0.44

  7. Bonjour,
    Je suis confronté au même problème d'incompatibilité utf-8. Décidément, je n'ai pas de chance. Il y a quelques temps c'était un bug avec la version de php, et maintenant c'est du coté d'ovh.
    Je dispose de plusieurs hébergements 60gp et effectivement, certains sont en MYSQL5 et d'autres plus anciens en MYSQL4.

    Question : Avez-vous demandé à ovh de migrer vers un serveur disposant de M5 ?

  8. Attention toutefois aux mirroirs aux allouettes.

    Prestashop chez ovh sur un dédié, mais prestashop sur un mutu : AU SECOURS les performences. Je continue pour ma part à proposer une intégration de prestashop sur mutu à mes clients si vraiment le budget est un critère important, sans quoi, moyennant 400€ de plus environ, je leur conseille vivement une solution sur dédié !

  9. Bonjour,

    Je suis confronté au probleme de connexion signal& en bug sur la page de téléchargement : * Some PHP 5 versions are bugged and prevent PrestaShop from working correctly:
    - PHP 5.2.1 (authentication is impossible)

    j'était en 5.2.5 et prestashop fonctionnait bien, n'y a t il pas de possibilité de se connecter lorsque la version de php installée est 5.2.1 ???

  10. Alors, je me permets de remonter le sujet que j'avais ouvert il y a quelques semaines car après avoir basculé la boutique du mutu 60gp sur lequel elle était implantée vers un dédié kimsufi, c'st maintenant le jour et la nuit.
    Temps d'accès et de navigation beaucoup plus rapide.
    Je n'ai fait que transferer intégralement le site + la bdd. Et même après avoir allourdi le template de quelques images, la navigation est fluide et agréable.

  11. Enfin une réponse ... (de normand)


    Bonjour,


    Au bout de 10 secondes d'exécution et si le script consomme plus de 30% de CPU , okiller mets une sorte de verrou sur le script pour le limiter à 30% de CPU, afin de permettre aux autres utilisateurs d'avoir suffisamment de ressource pour exécuter leurs scripts .Votre site a peut-être atteint une taille critique sur un point particulier. La majorité des CMS fonctionnent parfaitement bien jusqu'à ce que certaines limites soient atteintes, et à partir de là il faut souvent faire quelques modifs au niveau du code ou faire un peu le ménage dans les bases de données ou les fichiers pour rétablir un fonctionnement normal.

    Tout est ok de notre coté.

    Cordialement, Mohamed
  12. la boutique n'est pas sur un plan ni même un dédié, mais sur un gp.
    Hors avant de basculer sur un hebergement plus important j'aimerai avoir des précisions sur la source exacte du problème. J'ai ouvert un ticket auprès de l'assitance technique, je vous tiens informé de l'avancement du problème.

    PS : sur le forum ovh, tjs pas de réponse pour le moment.

  13. Bonjour à toutes et tous,

    Voilà plusieurs semaine que je n'arrive pas à résoudre un probleme d'erreur 500 aléatoire, avec des temps d'affichage affolant sur certaines pages sur une boutique en ligne utilisant prestashop sur un 60gp.

    Les erreurs ne sont pas systématique, mais le temps de navigation lent rend la viste plutôt désagréable et non fluide.

    J'ai lu ça et là que le problème "pourrait" être du au nombre de fichier appelé important à la génération de la page, mais bon sang, il y a bien des boutiques prestashop qui tournent sur des mutus chez ovh et où le temps d'affichage n'est pas aussi long.

    Le design est relativement épuré, mais ce n'est pas ce qui ralenti, voir essais avec Pingdom : http://tools.pingdom.com/fpt/default.asp?url=http://www.jm-distribution.com/&id=757745

    Et bien sur, YSlow + Firebug me donnent quasiment les mêmes graphes.

    Comment remédier à ce problème ?

    Je précise que j'ai également ouvert un sujet sur le forum ovh pour avoir deux pistes à suivre

    Une idée, voir une solution serait la bienvenue.

  14. Bien, après quelques heures passées sur le système j'ai enfin mis en ligne la boutique sur le nouveau domaine.
    Pour le moment, j'ai procédé ainsi :

    1) transfert via ftp de tout le repertoire de la boutique sur mon pc
    2) export de la bdd de l'anciene boutique
    3) modification des fichiers .php et .tpl contenant l'ancienne adresse (css, theme, etc.) pour indiquer la nouvelle adresse
    4) modification du fichier /config/settings.inc.php pour indiquer la nouvelle bdd (URI,NAME,SERVER et USER)
    5) transfert ftp de tous les fichiers vers le nouveau domaine directement à la racine
    6) import de la bdd de l'ancienne boutique


    Pour le moment, tout semble fonctionner. Mais je suis toujours en V1.0

    Je crains qu'en effectuant la mise à jour comme spécifié ici : http://www.prestashop.com/wiki/Getting_Started/#Update_PrestaShop je ne retrouve l'erreur SQL que j'avais précédement car globalement, c'est ce que j'avais fait!

×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More