Impossible d'installer des composants

[vatokely]

Bonjour à tous,

Préambule

J'ai déjà posté ce message dans le fil http://forum.joomla.org/index.php?actio ... replies=28 mais celui-ci étant déjà [Réglé] j'ai pensé qu'il était préférable d'ouvrir ce nouveau fil.

Contexte

J'héberge depuis 2 ans chez Celeonet, pour ne pas les nommer, une dizaine de sites web Joomla! (v.1.0.13), dont une demi-douzaine développés pour le compte de clients.

Dans un répertoire spécifique installé à la racine de ce serveur, j'ai placé les versions dézippées des add-ons (composants, modules, mambots) que j'utilise couramment et j'utilise le mode "Installation à partir d'un répertoire" pour les installer. Jusqu'à présent (jusqu'au 28/01/08 en tout cas, dernière date de l'installation d'un composant -JCE - sur un de mes sites) pas de pb.

Le 4/02/08, à l'occasion d'une mise à jour de Joom!fish ( 1.7 -> 1.8 ) j'ai rencontré un pb récurrent et jusqu'à ce jour impossible à contourner ; les fichiers composants sont effectivement copiés dans "administrator/component" et dans "component" mais à l'issue de l'installation une fenêtre s'ouvre en me proposant de télécharger un fichier index2.php qui vérification faite, s'avère être totalement vide.

nb1 : je rencontre occasionnellement ce genre de pb lors de la sauvegarde d'un contenu

nb2 : Suite à des tests effectués sur d'autres sites hébergés sur le même serveur, l'erreur s'est parfois manifesté sous la forme du message suivant :

"Erreur du serveur!

Le serveur a été victime d'une erreur interne et n'a pas été capable de faire aboutir votre requête.

Message d'erreur:
Premature end of script headers: php5

Si vous pensez qu'il s'agit d'une erreur du serveur, veuillez contacter le gestionnaire du site.
Error 500
http://www.mondomaine.org
Tue Feb 5 07:00:23 2008
Apache"

Je me suis alors lancé ds une série de tests sur l'ensemble de mes sites pour identifier la source du pb

Résultats

1/ Le problème se reproduit pour n'importe quel composant mais pas avec les modules et les mambots. Qques petits pb occasionnels (téléchargement d'index2.php vide) avec les "gros" templates mais globalement cela fonctionne bien surtout avec une install à partir du serveur.

2/ Ce problème existe sur l'ensemble de mes sites. J'ai même été jusqu'à faire une nouvelle installation de Joomla! sur un site "test" sans plus de résultats au niveau de l'installation de composants (nb: c'est souvent dans ce cas que l'on rencontre l'erreur 500 lors de la première tentative de composant).

3/ J'ai fait le test avec iE7 (j'utilise habituellement FireFox) : idem

4/ Même chose si je fait une tentative à partir du PC d'un client connecté sur un autre FAI

Discussion avec Celeonet

Les différents forums consultés faisant état d'une erreur serveur (diagnostic conforté dans mon esprit par ce qui précède) je me suis tourné vers Celeonet.

En résumé, leur hotline, assez réactive au demeurant, m'a recommandé :
1/ D'augmenter le paramètre memory_limit dans php.ini -> je l'ai passé de 12 à 24 Mo
2/ D'installer mes composant "manuellement"; mais à priori c'est bien ce que je fais déjà !

Et après 2 jours et 18 mails échangés ils ont fini par baisser les bras en me suggérant de me tourner à nouveau vers la communauté. Ce que je ....

Voilà ! Je suis bien embêté (et mes clients avec moi) et j'ai grand besoin maintenant de bénéficier rapidement d'un avis autorisé sur la question. La moindre piste de recherche de solution serait la bienvenue.

D'avance merci pour votre aide et bonne journée

PS :
J'ai testé, sans succès, la solution proposée ici http://forum.joomla.org/index.php/topic,247134.0.html et je souhaiterais savoir si le patch proposé par ouly ici http://forum.joomla.org/index.php?actio ... replies=28 est bien susceptible de répondre à mon pb.

[ouly]

Bonjour vatokely,
Il est possible que l'hébergeur ait introduit ou réduit le temps d'exécution autorisé par les scripts PHP. Le problème survient alors sans prévenir et sans raisons apparentes (ceci m'est arrivé chez un hébergeur).

La procédure d'installation d'un composant implique des points supplémentaires aux procédures d'installations des modules et plugins (exécution d'un script d'installation personnalisé, exécution de requêtes d'installation, etc.), de plus la taille d'un composant est normalement supérieure à celle d'un module ou d'un plugin, il paraît donc normal que ce soit la première fonctionnalité impactée.

Relevez la valeur indiquée pour le temps d'exécution (max_execution_time) dans l'admin de Joomla!, menu Système | Information Système, onglet PHP Info.

Par installation semi-automatique, on entend déposer les fichiers contenus dans l'archive de l'extension sur le serveur. Puis indiquer le chemin du dossier où les fichiers ont été déposés à Joomla! qui installera alors l'extension sans devoir effectuer une opération de désarchivage.

ouly

[mejean]

Je n'ai pas relevé ce problème chez Celeonet, mais je n'ai pas installé de composants ces derniers temps.
Il est possible chez celeonet, selon l'offre d'hébergement, de relever max_execution_time

[vatokely]

Bonjour,

... et merci pour vos 1ères suggestions concernant l'augmentation de max_execution_time. J'ai vérifié mais ce paramètre est déjà au max (60 s) de ce qui proposé avec mon abonnement (Celeopro).


Je viens de refaire un test avec un poste sous linux avec le même (non) résultat.
Cela bloque complètement quelque soit le contexte :
- Type de PC,
- Type de système 'exploitation,
- Type composant,
- Site web sur ce serveur,
- Installation à partir du fichier zip sur le PC ou du fichier décompressé sur le serveur,
- etc

Je crois bien avoir essayé toutes les combinaisons possibles sans succès.
J'ai cherché sans succès dans les différents forums.

Et là je ne sais plus où regarder, d'autant que cela fonctionnait impec il y a 10 j et que je n'ai touché à rien depuis.

Heeeeeeelp

[mejean]

Voir ici http://www.celeonet.fr/index.php?onglet=php_ini à partir de celeoprimo (l'offre d'entrée de gamme).

[vatokely]

Bonjour,

En y réfléchissant (la nuit porte conseil !), il me semble que le "temps d'exécution" est une bonne piste de réflexion car (i) j'ai pu constaté que l'installation prend apparemment bcp plus de tps que d'habitude et (ii) j'ai parfois cette erreur (téléchargement d'un fichier index2.php vide) lorsque des opérations d'enregistrement d'article s'éternisent.

A partir de là, la question que je me pose est : quelle est l'origine de ralentissement ? Cela ne peut pas être ma "bécane" : j'ai fait le test sur d'autres PC, yc 1 sous Linux installé tout exprès pour l'occasion, sans plus de résultat; le serveur alors ? Celeonet me dit que non.

Ceci étant, lorsque je fais une install "semi-automatique" à partir d'un dossier composant de-zippé placé directement sur le serveur, a priori tout se passe sur le serveur et la machine cliente n'intervient pas dans le processus. Est ce que je me trompe ?

Que reste t'il dans la chaine: mon routeur et ma connexion internet. Est ce que cela pourrait venir de là ?.

Sinon, je vais faire un test d'install chez un autre hébergeur et je vous tiens au courant.

[vatokely]

Bonjour,,

Juste pour vous informer que je viens de faire un test chez Online ou j'avais un compte (-> installation "manuelle" de Joomla au lieu de l'installation automatique proposée par Celeonet) et que dans ce cas tout se passe bien. J'ai pu installer 3 composant dont DOCMan qui est particulièrement "lourd". Alors que cela ne marche pas même sur une install toute neuve de Joomla! chez Celeonet.

nb : ches Online le paramètre max_execution_time est réglé à 300 s  (vs 60 s pour un contrat Celeopro) - Ceci explique peut-être cela.

Quoiqu'il en soit ceci implique que le pb vient plutôt du serveur. Je vais de nouveau interroger Celeonet et je vous tiens au courant.

[sebiseb]

As-tu réglé le problème avec celeonet, car je crois que le fond de mon problème évoqué dans 2 ou 3 fils de discussion ici (désolé méjean) est similaire au mien

[vatokely]

Bonjour,

Bonne nouvelle: au bout d'un mois de discussion et une bonne cinquantaine de mail échangés, j'ai fini par aller frapper à la porte (électronique) des servies "Commercial" et "Qualité" de Celeonet (adresses dispo sur leur site).

Le responsable de leur service client s'est alors mis en rapport avec moi Il atout de suite admis que cela venait probablement d'un erreur de leur cluster. Et de fait, cela à tout réglé (compter quand même une grosse semaine de plus) alors que mes interlocuteurs de leur "support" ont passé plus d'un mois à me répondre de manière laconique et désinvolte, que "non le pb venait pas de chez eux et que de tte manière un changement de cluster ne changerait rien à l'affaire - alors casse toi pauv... et marche à l'ombre"). NB : dans mon cas le cluster défaillant était le n°4

Conclusion :
1/ Le service "support" de Celeonet (pour Joomla en tout cas) à considérablement baissé de niveau: ils sont non seulement incompétents mais aussi totalement désinvoltes (ce qui au bout d'un mois d'échanges d'e.mail, de tests dans tout les sens, et à la clé un somme considérable de temps perdu, fini par "lasser") ;
2/ Et ds le cas d'espèce "il vaut mieux s'adresser au Bon Dieu qu'à ses saints.

Bonne chance!

NB : J'ai quitté Online pour Celeonet pour les mêmes raisons il y a 3 ans. Mais il est vrai, que j'ai gardé un compte (de "secours" chez eux et que j'avais fait un test qui s'était passé sans pb. Idem chez OVH. Preuve donc que le pb venait bien de Celeonet. Et bien même comme cela, ces incapables du support ne sont pas venus "à résipiscence")

[sebiseb]

Je crois que nous avons eu le même cheminement. J'étais chez online que j'ai quitté suite à de multiples problèmes pour faire tourner joomla (mambo à l'époque). J'ai jusqu'à présent été satisfait de celeonet sur lequel j'héberge seulement 3 sites (je ne suis pas professionnel de la chose "webmastering") ; 2 tournent avec joomla, l'un sur le cluster 3, l'autre sur le 4 - Bingo ! En testant l'installation de joomla 1.5, et des composants réputés compatibles sur le cluster 3 no problem 'installation successfull" -> J'ai demandé de ce pas à celeonet de transférer

Merci beaucoup, je commençais à me demander si j'avais encore toutes mes facultés - Bon certes, je me posais de sérieuses questions sur la manière dont est configuré leur apache, et même en bidouillant les paramètres du php.ini (option intéressante chez cet hébergeur) je ne me faisais pas trop d'illusions. Encore merci.

[sebiseb]

Celeonet m'informe, après une semaine passée, qu'ils travaillent sur le problème.
Je vous tiens au courant..

[sebiseb]

Celeonet n'a pas su régler le problème. Ils m'ont fait une réponse que lorsque que je leur ai demandé des nouvelles. Et la réponse était "installer les modules manuellement". À la demande d'un transfert vers un autre cluster, la réponsé était "c'est impossible techniquement"..
Je pense me tourner vers le service commercial, selon les réponses obtenues ses prochaines heures. Voir carrément de changer d'hébergeur, bien que nous venions de renouveler notre hébérgement..
..à suivre !

[mejean]

Salut sebiseb,

Désolé de ne pouvoir t'aider. Je n'ai aucun site sur le cluster 4 chez céleonet. Curieux qu'ils ne puisse rien faire, il doit forcement y avoir une différence de configuration.

Peux-tu essayer avec ça ?

[mejean]

Si message à Céléonet, précise que 2 problèmes sont identiques sur le cluster 4 mais qu'il ne se reproduit pas sur les autres (2 et 3 pour ma part) pour les utilisateurs de Joomla!

[sebiseb]

C'est déjà fait, puisque j'ai un site sur le cluster 3 où tout se passe très bien..
C'est d'ailleurs suite à ta réponse (dans ce fil de discussion je crois) et un test sur le site en hébergé sur le cluster 3 que je les ai contacté ! Ils m'indiquent qu'ils relancent un test..

[mejean]

De notre côté,

Peux-tu essayer avec ça ?

Histoire de voir si on y décèle des différences.

Essayes également de mettre "Error Reporting": sur "maximum"

[sebiseb]

J'ai essayé évidement toutes les variables du php.ini au maximum, mais rien ?
Je n'ai pas compris le reste, mais mon problème est similaire à celui de vatokely..

[nader84]

meme probleme sos