Internal Error 500 chez OVH avec Akeeba Backup

Réduire
Ce sujet est fermé.
X
X
  • Filtrer
  • Heure
  • Afficher
Tout effacer
nouveaux messages

  • [RÉGLÉ] Internal Error 500 chez OVH avec Akeeba Backup

    INFO : Problème résolu, les solutions sont dans les différents posts qui suivent. Merci.
    Salut à tous,

    j'ai un problème récurent avec Akeeba Backup chez OVH, quand je sauvegarde le site tout se déroule correctement jusqu'à ce que Akeeba Backup commence à sauvegarder la base de donnée.

    Initialisation du processus de sauvegarde : OK
    Incorporation du dossier d´installation : OK
    Sauvegarde de la base de données : Ça va jusqu'à 35% environs et plante !

    Akeeba Backup m'indique en rouge ceci suite a cet échec :

    Sauvegarde échouée

    La sauvegarde a été stoppée car une erreur a été détectée.
    Le message d'erreur est :

    AJAX Loading Error
    HTTP Status: 500 (Internal Server Error)
    Internal status: error
    XHR ReadyState: 4
    Raw server response:
    Internal Server Error


    Ce phénomène ce produit depuis que j'ai mis Akeeba Backup à jour, j'ai la dernnière version.

    Voici mes logs, quelqu'un à eu ce même cas déjà ?

    [130217 17:13:32] PHP Version :5.3.16
    [130217 17:13:32] PHP OS :Linux
    [130217 17:13:32] PHP SAPI :cgi-fcgi
    [130217 17:13:32] OS Version :Linux
    [130217 17:13:32] DB Version :5.1.63-0+squeeze1-log
    [130217 17:13:32] Web Server :Apache/2.2.X (OVH)
    [130217 17:13:32] Joomla! version :2.5.9

    Si vous avez la parade merci de m'en faire part. J'ai plusieurs Joomla! sur plusieurs serveurs different et ça ne me le fait que chez OVH.

    Merci par avance.
    Dernière édition par felichon à 01/03/2013, 11h15

  • #2
    Re : Internal Error 500 chez OVH avec Akeeba Backup

    Bonsoir,

    Serveur dédié ou mutu ?
    Votre base de données est grosse, elle fait qu'elle taille ?

    Rien à voir avec Akeeba, mais PhpMyAdmin me faisait la même erreur quand j’essayais de sauvegarder ma base de données qui avait dépassée les 200Mo... ça peut être une piste.

    Je suis chez OVH avec un dédié.
    Besoin de debugguer votre site, pensez à Firebug : http://www.grafikart.fr/tutoriels/ht...ion-firefox-76
    Vous avez trouvé une solution, mettez votre discussion en [Réglé] ? http://forum.joomla.fr/announcement.php?f=58
    Je ne donne pas suite aux messages privés (MP) non sollicités !

    Commentaire


    • #3
      Re : Internal Error 500 chez OVH avec Akeeba Backup

      Hello,

      C'est en mutualisé effectivement et la BD est volumineuse.

      Ben alors c'est ça effectivement, je crois que ça expliquerai beaucoup de choses, la base de donnée est relativement conséquente.

      Y'a t'il un moyen de contourner ce problème et comment sauvegarder le site dans ses conditions ?

      C'est le site d'une association avec énormément de données, je ne peu pas leur dire raisonnablement de virer des choses pour sauvegarder leur site.

      Merci de votre aide.

      Commentaire


      • #4
        Re : Internal Error 500 chez OVH avec Akeeba Backup

        Je ne connais pas du tout le fonctionnement et donc l'interface d'AkeebaBackup, mais peut être que tu peux "découper" la sauvegarde de la bdd en 2 ou 3 pour éviter l'erreur 500.
        Avec PhpMyAdmin c'est faisable en tout cas, bien sûr c'est plus pénible à réaliser (connexion à phpmyadmin, ensuite lancer l'exportation des fichiers, arrêter en cours, récupérer le 1er fichier SQL, relancer l'exportation etc ...).
        Besoin de debugguer votre site, pensez à Firebug : http://www.grafikart.fr/tutoriels/ht...ion-firefox-76
        Vous avez trouvé une solution, mettez votre discussion en [Réglé] ? http://forum.joomla.fr/announcement.php?f=58
        Je ne donne pas suite aux messages privés (MP) non sollicités !

        Commentaire


        • #5
          Re : Internal Error 500 chez OVH avec Akeeba Backup

          Envoyé par XdiZ Voir le message
          Jpeut être que tu peux "découper" la sauvegarde de la bdd en 2 ou 3 pour éviter l'erreur 500.
          Avec PhpMyAdmin c'est faisable en tout cas, bien sûr c'est plus pénible à réaliser (connexion à phpmyadmin, ensuite lancer l'exportation des fichiers, arrêter en cours, récupérer le 1er fichier SQL, relancer l'exportation etc ...).
          Depuis 3 mois, il y a des erreurs 500 à la pelle chez OVH suite à leur problème d'infra
          Tout dépend du cluster : dans ma liste, le 6 et le 14 sont bien malades.
          J'ai depuis longtemps renoncé au backup complet ( Base + Dossiers )

          Depuis que j'utilise le plugin Lazydbbackup avec envoi par mail, j'ai nettement moins de soucis.
          Ma plus grosse base fait 6,5 Mo zippée, mais j'avais des erreurs 500 sur toutes les bases, y compris les petites.
          Nous pouvons donc en déduire que la taille n'a pas d'importance ( vérifié dans beaucoup de domaines )

          Pour les dossiers, j'opère 1 dossier à la fois en limitant le nombre de connexions simultanées à 2.
          C'est ch...mais ça passe bien mieux.

          Depuis 1 mois, j'ai déplacé les sites qui étaient dans les choux chez un autre hébergeur
          Résultat : 6 min de coupure par jour au lieu des 6 heures intolérables ...et plus aucune aucune erreur 500.

          C'est donc bien le mutu OVH qui merdoie quand il héberge un CMS. Dommage.
          J'ai aussi les mêmes problèmes sur mes sites Wikimédia.

          Commentaire


          • #6
            Re : Internal Error 500 chez OVH avec Akeeba Backup

            Juste pour info : sur plusieurs sites en mutu OVH, il m'a fallu désactiver AJAX dans les paramètres de la sauvegarde (pas d'erreur 500 mais elle n'aboutissait pas), alors que sur d'autres, les paramètres par défaut de posent pas de problème.

            A propos de LazyDbBackup, je n'ai pas eu l'occasion de le tester sur de grosses bases, mais lorsqu'elles le sont, il est possible de ne pas expédier par mail et de conserver la sauvegarde sur le serveur, puis de la récupérer par ftp (et de gérer éventuellement le nombre avec LDBChecker).
            Dernière édition par RobertG à 18/02/2013, 10h15
            "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide). MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info hébergés chez PHPNET - +sites gérés chez 1and1 et OVH - Site pro : www.robertg-conseil.fr

            Commentaire


            • #7
              Re : Internal Error 500 chez OVH avec Akeeba Backup

              Envoyé par Steve Voir le message
              Depuis 3 mois, il y a des erreurs 500 à la pelle chez OVH suite à leur problème d'infra
              Tout dépend du cluster : dans ma liste, le 6 et le 14 sont bien malades.
              J'ai depuis longtemps renoncé au backup complet ( Base + Dossiers )

              Depuis que j'utilise le plugin Lazydbbackup avec envoi par mail, j'ai nettement moins de soucis.
              Ma plus grosse base fait 6,5 Mo zippée, mais j'avais des erreurs 500 sur toutes les bases, y compris les petites.
              Nous pouvons donc en déduire que la taille n'a pas d'importance ( vérifié dans beaucoup de domaines )

              Pour les dossiers, j'opère 1 dossier à la fois en limitant le nombre de connexions simultanées à 2.
              C'est ch...mais ça passe bien mieux.

              Depuis 1 mois, j'ai déplacé les sites qui étaient dans les choux chez un autre hébergeur
              Résultat : 6 min de coupure par jour au lieu des 6 heures intolérables ...et plus aucune aucune erreur 500.

              C'est donc bien le mutu OVH qui merdoie quand il héberge un CMS. Dommage.
              J'ai aussi les mêmes problèmes sur mes sites Wikimédia.
              Ok, c'est bon à savoir.
              Je ne fais aucune sauvegarde à partir de composant Joomla, mais tout en ligne de commande, donc je ne constatais pas ce genre de symptôme.

              Comme toi, j'ai 2 sites utilisant Mediawiki, et c'est ces bdd qui me posaient souci.
              Besoin de debugguer votre site, pensez à Firebug : http://www.grafikart.fr/tutoriels/ht...ion-firefox-76
              Vous avez trouvé une solution, mettez votre discussion en [Réglé] ? http://forum.joomla.fr/announcement.php?f=58
              Je ne donne pas suite aux messages privés (MP) non sollicités !

              Commentaire


              • #8
                Re : Internal Error 500 chez OVH avec Akeeba Backup

                Envoyé par RobertG Voir le message
                Juste pour info : sur plusieurs sites en mutu OVH, il m'a fallu désactiver AJAX dans les paramètres de la sauvegarde (pas d'erreur 500 mais elle n'aboutissait pas), alors que sur d'autres, les paramètres par défaut de posent pas de problème.
                Merci pour l'info.
                A propos de LazyDbBackup, je n'ai pas eu l'occasion de le tester sur de grosses bases, mais lorsqu'elles le sont, il est possible de ne pas expédier par mail et de conserver la sauvegarde sur le serveur, puis de la récupérer par ftp (et de gérer éventuellement le nombre avec LDBChecker).
                Je n'utilise plus LDBchecker : si un mail ne passe pas ( ça arrive ), le fichier reste dans le dossier et il faudra obligatoirement aller le purger. Je passe ainsi chaque semaine sur la racine du site avec une série de contrôles divers. Ca prend 2 minutes et c'est plus rassurant pour moi.

                Commentaire


                • #9
                  Re : Internal Error 500 chez OVH avec Akeeba Backup

                  Salut,

                  Merci de vos retours, c'est cool.

                  Je n'ai pas ses soucis avec Nuxit, 1&1 , ni en local ca crain juste avec OVH.

                  J'ai fais un test avec un site "vide" juste avec Joomla!2.5 par défaut et Akeeba Backup et hop sa plante.

                  J'ai également désactivé l'ajax dans Akeeba juste pour voir, j'ai choisi l'option Iframe.

                  Rien a faire, ça plante systématiquement quand ça commence a sauvegarder la base de donnée.

                  Pourtant elle est optimisé au maximum, Zéro perte, en plus j'ai AdminTool pour faire le ménage, mais rien y fait ça plante.

                  J'ai fait une copie de ce site intégrale que j'ai installé en local et là pas de bug, la sauvegarde va au bout sans erreurs.

                  C'est donc bien OVH qui merdouille en cherchant par élimination !

                  Grrrr !

                  Si quelqu'un a la parade, je lui en serai reconnaissant car c'est frustrant de ne pas en connaitre la cause.

                  @ +

                  Commentaire


                  • #10
                    Re : Internal Error 500 chez OVH avec Akeeba Backup

                    Envoyé par felichon Voir le message
                    Si quelqu'un a la parade, je lui en serai reconnaissant car c'est frustrant de ne pas en connaitre la cause.
                    Rien pour la parade, désolé ( et le carnaval est passé )
                    Quant à en connaitre la cause, qui sait ? un jour peut-être...
                    Sinon tu peux toujours suivre les échanges houleux sur le sujet qui émaillent le forum OVH
                    http://ovh.wxop.com/posts.php?lang=fr
                    ( à consulter avec modération pour ne pas sombrer dans la déprime )

                    Commentaire


                    • #11
                      Re : Internal Error 500 chez OVH avec Akeeba Backup

                      Hello,

                      Ce que je ne comprend pas, c'est que lorsque je lance la configuration automatique, Akeeba m'indique que tout les testes on été passés avec succès et que le site peu donc être sauvegardé sans soucis.

                      De plus, j'ajoute que lorsque j'avais mis le site la première fois chez OVH (Octobre 2012) j'ai pu sauvegarder 3 fois sans soucis le site + base avec Akeeba. (D'ailleurs je conserve cette archive depuis, c'est ma seul sécurité en cas de plantage mais bon elle date a présent)

                      Ce qui a changé de mon coté depuis cette configuration stable :

                      - J'ai mis plusieurs fois à jour Joomla!2.5 vers les dernières versions.
                      - J'en ai bien entendu fait de même avec quelques extension incontournables (AdminTool, CBuilder, PhocaGallery etc...)
                      - J'ai bien entendu fais la mise à jour régulierement de AkeebaBacup

                      Coté OVH, je ne sais pas si quelque chose à changé en revanche depuis cette date.

                      Je suis preneur de toute pistes, même si elle ne mènent nul par car je suis prèt à tout pour éviter de rapatrier tout le site via FTP fichier par fichier + base de donnée, c'est d'un autre age cette méthode et avec ma connexion ADSL du village, il me faudrait 2 mois pour faire la manipulation un vrai calvaire.

                      31 Ko en émission et 126 en récéption ! Merci Orange, même au Sénégal ils on plus pourtant je suis en Alsace à coté de la frontière Suisse !!!

                      Juste pour info :

                      Je te jure, c'est la précarité informatique, j'ai le débit maximum pour mon village, c'est ce qu'il appellent "La Formule Plus" soit internet jusqu'à 20 méga théorique bien sur car que je l'atteint jamais, mon record absolu c'est 126ko/s sur crête ! Ils me disent depuis 4 ans que ça viendra un jour chez moi aussi.


                      Xaxa, je peu toujours rêver ...

                      @+
                      Dernière édition par felichon à 19/02/2013, 09h27 Raison: Précisions divers et mise en page

                      Commentaire


                      • #12
                        Re : Internal Error 500 chez OVH avec Akeeba Backup

                        Envoyé par felichon Voir le message
                        Ce que je ne comprend pas, c'est que lorsque je lance la configuration automatique, Akeeba m'indique que tout les testes on été passés avec succès et que le site peu donc être sauvegardé sans soucis.
                        C'est normal : Akeeba va tester la taille du tuyau, le débit etc... moyen en 3 minutes.
                        Quant tu lances la sauvegarde complète, tu vas consommer plus de ressources ...et c'est OVH qui te renvoie une erreur 500 ( et là, c'est anormal, mais tu ne peux rien faire )

                        De plus, j'ajoute que lorsque j'avais mis le site la première fois chez OVH (Octobre 2012) j'ai pu sauvegarder 3 fois sans soucis le site + base avec Akeeba.
                        Idem pour moi :
                        J'ai mis un site en ligne mi_octobre
                        3 jours sans problèmes ( après 3 mois de développement sans soucis aucun )
                        3 mois de dégradations : temps de réponse > 6s, token de sécurité invalide 10 fois par jour, coupures etc...
                        Grosse surprise pour les 500 membres qui sortaient d'une vieille page HTML... et découvraient les CMS
                        Grosse galère pour moi : 2 heures de boulot par jour à essayer de trouver la merdouille dans mon code. Ca m'a couté un bras.
                        Mi-janvier, j'ai perdu le client.
                        Fin janvier j'ai déménagé le site sur un autre hébergeur.
                        J'ai récupéré le client et renégocié mon contrat ...en perdant l'autre bras.
                        Plus aucun problème depuis.
                        Mes autres sites sur OVH tournent bien ( mais je contrôle chaque jour et je dors mal chaque nuit )

                        Coté OVH, je ne sais pas si quelque chose à changé en revanche depuis cette date.
                        On va pas tirer sur une ambulance, mais apparemment ils ont remonté leur manches depuis une quinzaine.
                        Il ne reste plus qu'à attendre des certitudes plus "industrielles" et surveiller de très près les travaux sur ton cluster et tes bases.

                        Je suis preneur de toute pistes, même si elle ne mènent nul par car je suis prêt à tout pour éviter de rapatrier tout le site via FTP fichier par fichier + base de donnée, c'est d'un autre age cette méthode et avec ma connexion ADSL du village, il me faudrait 2 mois pour faire la manipulation un vrai calvaire.
                        Je faisais les backups pour un pote du coté de Montreux-Vieux. Il est aussi au bout du monde avec sa connexion Orange. Ca lui faisait gagner du temps.
                        La dégradation actuelle du mutu OVH m'interdit d'effectuer la sauvegarde complète et je fais comme toi : dossier par dossier. Youpi ! Au moins, je peux le dépanner pour les mises à jour et les transferts d'images.

                        31 Ko en émission et 126 en réception ! Merci Orange, même au Sénégal ils on plus pourtant je suis en Alsace à coté de la frontière Suisse !!!
                        EstVideo n'a pas sévi dans ton patelin ? Tu as peut-être un voisin sympa...


                        Je te jure, c'est la précarité informatique, j'ai le débit maximum pour mon village, c'est ce qu'il appellent "La Formule Plus" soit internet jusqu'à 20 méga théorique bien sur car que je l'atteint jamais, mon record absolu c'est 126ko/s sur crête ! Ils me disent depuis 4 ans que ça viendra un jour chez moi aussi.
                        J'avais la même à la maison ...et j'ai pris l'offre promo Nobox OVH à son lancement. Le débit est pas franchement mieux ( et c'est normal ), mais j'ai plus jamais eu de coupures. Je touche du bois.
                        Dernière édition par Steve à 19/02/2013, 12h10

                        Commentaire


                        • #13
                          Re : Internal Error 500 chez OVH avec Akeeba Backup

                          Pour info : je teste pour un client divers hébergeurs. Le site est assez simple, bien qu'un peu lourd, mais sur le serveur dédié de son prestataire actuel, une sauvegarde Akeeba met autour de 30 secondes pour 38 Mo de jpa. Sur un mutu OVH, ça tourne la plupart du temps en 4 minutes : 8 fois plus lent.
                          Chez 1&1 en mutu Illimité, la première sauvegarde du clone n'a mis que 19 secondes, mais ensuite, j'ai eu l'impression qu'il y avait un effet de cache, car si la plupart du temps une sauvegarde prend une trentaine de secondes, elle tourne parfois entre 2 et 3 minutes lorsque je n'en ai pas fait depuis un moment.
                          Mais la cerise sur le gâteau est le site d'un autre client, site en développement sur un sous-domaine en mutu OVH, site e-commerce VM avec une vingtaine de produits, très peu d'images pour le moment : 11min 45s il y a quelques instants pour 47 Mo de jpa, alors que le temps il y a 3 mois était de 1min 30s, et que c'est passé à 4min mi-novembre, pour osciller entre 3 et 8 depuis !
                          Nouvel essai 45 minutes plus tard : 8 minutes pour la sauvegarde ! Et le patron d'OVH nous a pourtant ditq ue les choses s'étaient améliorées avec le déplacement des sites "lourds" vers des serveurs adaptés.
                          Comment continuer à conseiller du mutu OVH à nos clients pour des CMS, Joomla! ou autres ?
                          "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide). MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info hébergés chez PHPNET - +sites gérés chez 1and1 et OVH - Site pro : www.robertg-conseil.fr

                          Commentaire


                          • #14
                            Re : Internal Error 500 chez OVH avec Akeeba Backup

                            Hello,

                            Merci pour vos retours, j'apprécie sincèrement car là c'est la panade chez OVH.

                            Je me suis vachement reconnus dans les propos de Steeve j'ai pratiquement subi la même galère. J'ai également apprécié les précisions de RobertG.

                            Je trouve que OVH c'est pas terrible, je ne connaissais pas, j'aime pas du tout leur espace "manager" pour le client, c'est tres moche graphiquement et on dirait une usine à Gaz.

                            Créer une BD chez eux depuis cet espace est aussi déroutant que de programmer du PHP.

                            C'est mon client qui a choisi lui même son hébergeur, du coup je me suis adapté.

                            Perso j'ai toujours été chez Nuxit, même en mutualisé je sauve mon site avec Akeeba Bacup en moins de 2 à 4 minutes pourtant tout le site fait 300 MO avec une base déjà bien fourni sans compter les sous-domaines que j'ai en plus dessus.

                            Pour ce qui est de Montreux-Vieux j'habite pas loin (Pfetterhouse 68480) je connais la misère. mes seul fournisseur possibles sont Orange et Free c'est tout, aucun autre fournisseur ne veut s'embourber, personne ne viens jusqu'ici. L’émetteur principal est à Seppois-le-Bas, soit 5.5 km de chez moi, ce qui engendre des pertes monstres sur une tel distance !

                            Orange me propose de tout passer par le satellite, aucune autre solution n'est envisageable dans un délais de 5 ans au moins.

                            La commune avait fait un devis pour tirer un câble optique entre les 2 villages, devis 60.000 euros, une fortune pour notre blède de 1000 habitants.

                            Quoi qu'il en soit je surveille les forum OVH pour essayer de voir ce qui déconne.

                            PS : j'ai beaucoup aimé la phrase "Je ne vais pas tirer sur l'ambulance" je ne connaissais pas
                            Dernière édition par felichon à 19/02/2013, 13h07

                            Commentaire


                            • #15
                              Re : Internal Error 500 chez OVH avec Akeeba Backup

                              Envoyé par RobertG Voir le message
                              Comment continuer à conseiller du mutu OVH à nos clients pour des CMS, Joomla! ou autres ?
                              Je le fais sans trop de bobos :
                              Le client prend son domaine chez OVH, mais je place son CMS sur un multi-domaines "à moi" que j'ai ouvert spécialement.
                              [checkbox-ON] Je sais que je prends le risque d'avoir tous les sites plantés en cas de défaillance de mon hébergement.

                              Le jour où OVH sera de nouveau dans les clous, le client prendra un plan Perso ou Pro, puis je transfèrerai le CMS, la base et modifierai les DNS.
                              Le client aura donc un domaine indépendant de son hébergement, que les deux soient chez le même hébergeur ou pas.
                              J'avais initialement prévu d'utiliser mon multi-domaine pour y placer une copie de tous mes sites en cas de pépin.
                              Or, depuis 1 mois il se transforme en hébergement de prod alors qu'OVH devient le backup.
                              J'ai commencé doucement avec mes sites persos pour me faire la main et maintenant j'en bascule 2 par semaines.
                              Je me suis fait peur au début, maintenant ça me rassure.

                              L'opération est quasi transparente pour le client. Faut juste lui expliquer pour l'administration et les mails.
                              Le coût de l'opération pour 2013 est inférieur à 100 zorros ( pour ma pomme )
                              Pour info, j'en perdais nettement plus ...chaque semaine depuis le 15 octobre.

                              Je continuerai de bosser avec OVH : leurs problèmes ne sont qu'une "grippe" passagère.
                              Ils grandissent, ils avancent et commettent des erreurs. Rien d'anormal.
                              Ils s'en remettront et tout le monde sera content.
                              Dans le cas contraire, nous serons bien obligés d'aller ailleurs.

                              Commentaire

                              Annonce

                              Réduire
                              1 sur 2 < >

                              C'est [Réglé] et on n'en parle plus ?

                              A quoi ça sert ?
                              La mention [Réglé] permet aux visiteurs d'identifier rapidement les messages qui ont trouvé une solution.

                              Merci donc d'utiliser cette fonctionnalité afin de faciliter la navigation et la recherche d'informations de tous sur le forum.

                              Si vous deviez oublier de porter cette mention, nous nous permettrons de le faire à votre place... mais seulement une fois
                              Comment ajouter la mention [Réglé] à votre discussion ?
                              1 - Aller sur votre discussion et éditer votre premier message :


                              2 - Cliquer sur la liste déroulante Préfixe.

                              3 - Choisir le préfixe [Réglé].


                              4 - Et voilà… votre discussion est désormais identifiée comme réglée.

                              2 sur 2 < >

                              Assistance au forum - Outil de publication d'infos de votre site

                              Compatibilité: PHP 4.1,PHP4, 5, 6DEV MySQL 3.2 - 5.5 MySQLi from 4.1 ( @ >=PHP 4.4.9)

                              Support Version de Joomla! : | J!3.0 | J!2.5.xx | J!1.7.xx | J!1.6.xx | J1.5.xx | J!1.0.xx |

                              Version française (FR) D'autres versions sont disponibles depuis la version originale de FPA

                              UTILISER À VOS PROPRES RISQUES :
                              L'exactitude et l'exhaustivité de ce script ainsi que la documentation ne sont pas garanties et aucune responsabilité ne sera acceptée pour tout dommage, questions ou confusion provoquée par l'utilisation de ce script.

                              Problèmes connus :
                              FPA n'est actuellement pas compatible avec des sites Joomla qui ont eu leur fichier configuration.php déplacé en dehors du répertoire public_html.

                              Installation :

                              1. Téléchargez l'archive souhaitée : http://afuj.github.io/FPA/

                              Archive zip : https://github.com/AFUJ/FPA/zipball/master

                              2. Décompressez le fichier de package téléchargé sur votre propre ordinateur (à l'aide de WinZip ou d'un outil de décompression natif).

                              3. Lisez le fichier LISEZMOI inclus pour toutes les notes de versions spécifiques.

                              4. LIRE le fichier de documentation inclus pour obtenir des instructions d'utilisation détaillées.

                              5. Téléchargez le script fpa-fr.php à la racine de votre site Joomla!. C'est l'endroit que vous avez installé Joomla et ce n'est pas la racine principale de votre serveur. Voir les exemples ci-dessous.

                              6. Exécutez le script via votre navigateur en tapant: http:// www. votresite .com/ fpa-fr.php
                              et remplacer www. votresite .com par votre nom de domaine


                              Exemples:
                              Joomla! est installé dans votre répertoire web et vous avez installé la version française du fichier FPA:
                              Télécharger le script fpa-fr.php dans: /public_html/
                              Pour executer le script: http://www..com/fpa-fr.php

                              Joomla! est installé dans un sous-répertoire nommé "cms" et vous avez installé la version française du fichier FPA:
                              Télécharger le script fpa-fr.php dans: /public_html/cms/
                              Pour executer le script: http://www..com/cms/fpa-fr.php

                              En raison de la nature très sensible de l'information affichée par le script FPA, il doit être retiré immédiatement du serveur après son utilisation.

                              Pour supprimer le script de votre site, utilisez le lien de script de suppression fourni en haut de la page du script. Si le lien de suppression échoue pour supprimer le script, utilisez votre programme FTP pour le supprimer manuellement ou changer le nom une fois que le script a généré les données du site et le message publié sur le forum. Si le script est toujours présent sur le site, il peut être utilisé pour recueillir suffisamment d'informations pour pirater votre site. Le retrait du script empêche des étrangers de l'utiliser pour jeter un oeil à la façon dont votre site est structuré et de détecter les défauts qui peuvent être utilisé à vos dépends.
                              Voir plus
                              Voir moins
                              Travaille ...
                              X