J'ai cette erreur lorsque je télécharge la mise à jour d'un plugin que j'ai supprimé sans le désactiver :
Fatal error: Call to a member function getLang() on a non-object in /home/www/monsite/plugins/plxMyPluginDownloader/plxMyPluginDownloader.php on line 166
J'ai cette erreur lorsque je télécharge la mise à jour d'un plugin que j'ai supprimé sans le désactiver :
Fatal error: Call to a member function getLang() on a non-object in /home/www/monsite/plugins/plxMyPluginDownloader/plxMyPluginDownloader.php on line 166
Salut,
Quel est le plugin en question qui t'as généré cette erreur ?
J'ai cette erreur lorsque je télécharge la mise à jour d'un plugin que j'ai supprimé sans le désactiver :
Fatal error: Call to a member function getLang() on a non-object in /home/www/monsite/plugins/plxMyPluginDownloader/plxMyPluginDownloader.php on line 166
Salut,
Quel est le plugin en question qui t'as généré cette erreur ?
## Version 1.0 (02/08/2013) ##
+ Compatibilité PluXml 5.2
Bonjour
nouvelle version installée sur pluxml 5.2 en la téléchargeant à partir d'ici
Par contre, dans l'interface de gestion de ce plugin, j'ai une nouvelle version de proposée MyPluginDownloader - version 1.2 (04/08/2013)
Je clique sur Mettre à jour Le téléchargement et la MAJ se déroulent bien mais j'ai toujours la MAJ de proposée !!! ???
J'ai désactivé le plugin, je me suis déconnecté puis reconnecté et réactivé le plugin sans changement.
@fpp: pour annuler la réécriture d'url: à partir de l'admin remettre le paramètre à Non pour désactiver la réécriture, ou alors editer manuellement le fichier data/configuration/parametres.xml pour mettre à 0 le paramètre et supprimer le fichier .htaccess à la racine de PluXml
Vu, je ne pouvais plus accéder à l'admin donc j'ai utilisé la seconde méthode, plus de problème.
Et cette version de MyPluginDownloader fonctionne en effet, merci :-)
Je me repenche sur PluXml (je le fais régulièrement) pour un projet d'un client où il conviendra parfaitement; et je tombe sur ce plugin qui m'avait échappé.
Ce plugin est générateur d'une foule de possibilités que je voudrais bien voir développées. Mais mes compétences s'arrêtent à l'architecture, ayant depuis longtemps laissé le code à des plus jeunes que moi.
D'un autre coté, je sais qu'il suffit parfois de "lâcher une idée" pour qu'un développeur s'en empare et la réalise, alors j'ose.
Voyez ce post comme une wichlist et n'hésitez pas à le déplacer si nécessaire.
1) Il serait pratique de pouvoir faire gérer tous les plugins installés sur un site, d'où qu'ils viennent, par cette extension (un peu à la manière des dépôts sous Linux); et ça n'a pas échappé à Bankai (à voir son post #44)
La structure du repository nécessaire au fonctionnement n'est pas très complexe; il serait certainement assez simple d'agréger plusieurs fichiers [repository.name].xml dans le répertoire cache en les nommant différemment.
Par exemple :
[== Fichiers du répertoire ==]
repository.my-pluxml.googlecode.com.xml
repository.my-pluxml.googlecode.com.version
repository.site-de-bankai.fr.xml
repository.site-de-bankai.fr.version
Pourquoi ? Pour disposer d'un lieu central où trouver toutes les mises à jour à faire (voir l'idée 4).
Il suffirait alors de livrer PluXml avec cet unique plugin installé (ou de l'intégrer totalement) avec le dépôt "officiel" préconfiguré pour que tout aspect technique dans l'installation de plugins disparaisse.
2) Pour fignoler le point précédent, il faudrait pouvoir simplement ajouter (et retirer) un "dépôt".
Un simple champ pour saisir une URL où aller piocher les deux fichiers .xml et .version et un fichiers XML "plugin.depots" pour en conserver la liste et en permettre la mise à jour automatique et une gestion (ajout et suppression) via une page de type "Liste des dépôts".
Pourquoi ? Pour que l'ajout de dépôt puisse se faire sans utiliser Filezilla et permette un contrôle facilité des sources de plugins.
3) Actuellement, une seule liste des plugins, complète, est affichée dans l'administration, et l'étiquette de couleur indique pour chacun s'il est installé ou pas, et s'il faut le mettre à jour.
Toujours dans une approche similaire aux dépôts d'une distribution Linux, une deuxième page (ou onglet) n'affichant que les plugins installés simplifierait le suivi de 'son' site.
La page actuelle garde toute son utilité comme catalogue des plugins disponibles, se mettant à jour au rythme des nouveautés.
Pourquoi ? Parce qu'en permettant l'agrégation de plusieurs dépôts, la liste risque d'être longue (elle l'est déjà sur le seul dépôt officiel), et l'information de mise à jour pourrait passer inaperçue.
Une autre possibilité serait de trier les plugins en plaçant ceux qui sont installés et/ou à mettre à jour en tête de liste; mais je pense que ce serait plus compliqué à réaliser, et pas forcément plus clair à utiliser.
4) Si le point trois est réalisé, créer un plugin qui intègre la boucle qui teste et détermine s'il y a mise à jour ou pas ne doit pas être bien sorcier (le foreach() avec le version_compare() dans admin.php). Reste à pouvoir l'activer régulièrement, via une crontab par exemple.
Encapsuler cette fonction dans une page accessible par un wget sur une URL ferra l'affaire; quitte à créer une URL "salée" avec une chaine de caractère pseudo aléatoire pour cela. Par exemple : http://monsitepluxml.com/testmaj-qdC3fh7FL2smp5lFC/scanmaj.php
Dans cette page, à la suite de la boucle de test, coder l'envoi d'un mail à l'administrateur si au moins une mise à jour existe ne serait que la petite cerise sur un bien beau gâteau.
Faire le wget de cette URL à intervalle régulier (d'où la crontab) permet d'être averti dès qu'il y a des mise à jours à faire.
Pourquoi ? Pour ceux qui ne passent pas leur temps à venir visiter l'administration de leur site (ce sont les plus nombreux, croyez moi), il est bien agréable de recevoir une alerte indiquant qu'une mise à jour requiers leur attention.
Si en plus, ce plugin alerte en cas de mise à jour du core, c'est le top ;-)
5) Point cosmétique; quant un plugin est installé, il est flanqué d'une étiquette grise libellée "Télécharger"; un simple "Installé" ne serait-il pas plus clair ?
Et dans le cas de ceux qui sont installés, un bouton "Supprimer le ZIP" pourrait apparaitre si ce dernier traine encore dans le répertoire (inutile d'embarquer l'archive du plugin dans la sauvegarde journalière de l'arborescence).
Un bouton "Désinstaller" pourrait aussi être affiché.
Pourquoi ? Toujours pour retirer l'aspect technique de la gestion des plugins (et des skins si mon idée suivante abouti à quelque chose)
6) Une deuxième instance de ce plugin, ou une variante nommée différemment, pourrait facilement permettre de gérer l'installation des skins, toujours d'après un ensemble de repository (l'officiel et des PPA-like).
Pourquoi ? Comme au dessus, pour retirer toute nécessité d'action technique dans l'installation d'une skin.
Cet absence d'actes jugés "techniques" par la grande majorité des non-initiés est l'une des raisons qui leur fait choisir WordPress où ces deux aspects (plugins et thèmes) sont parfaitement intégrés et transformés en clicodromes.
Merci d'avoir lu jusque là. Voilà de quoi cette extension, dans son état actuel déjà bien pratique, m'a donné envie.
Et si ces idées vous semblent intéressantes et nécessitent plus de développements, je suis prêt à les décrire avec plus de détails.
@C.Catarina: Bonjour Christophe. De très bonnes remarques tout à fait justifiées. J'en prends bonnes notes pour améliorer l'ergonomie du plugin. Merci d'avoir pris le temps de rédiger toutes ses bonnes idées.
Merci d'avoir pris le temps de rédiger toutes ses bonnes idées.
Ce serait plutôt à moi de vous remercier de les prendre en compte
Sans parler de tout le travail déjà produit pour amener PluXml là où il est aujourd'hui.
En y regardant un peu plus à froid, je pense que l'actuelle page de gestion des plugins pourrait s'orner d'un troisième choix donnant sur ce plugin.
À la suite de : Plugins actifs (X) | Plugins inactifs (Y)
on pourrait trouver un : | Catalogue (Z)
Les fonctions de mise à jour s'intégrant à la liste des plugins actifs.
J'utilise ce plugin depuis un bon moment déjà et je le trouve tout simplement génial !
Une petite remarque tout de même : les zip ne sont pas supprimés automatiquement.
Voilou, merci pour ce plugin qui permet de gagner énormément de temps =]
plus tard ci, je charge plxMyPluginDownloader, qui me trouve d'autres versions, sur googlecode?, respectivement: 1.1, 1.2, 1.3
comme selon les commentaires du lien pluxopolis,
je gère les mises à jour de manières à ce que les sources dans les .zip téléchargés par MyPluginDownloader soient au même niveau que ceux sur github
je remonte ce petit blême
PS:
si ce principe de chargement de plugin pouvait être "livré" en standard, avec un catalogue de plugins considérés un tant soit peu libres/fiables/utiles (ou un dépot central) le tout organisé par thème, cela aiderait grandement un premier arrivant à découvrir et démarrer.
juste une remarque pour appuyer l'idée déjà émise
Est-ce que ce ne serait pas intéressant de s'en servir pour mettre en place un dépôt officiel directement dans Pluxml, un peu comme Wordpress propose. Je ne pense pas que ça viendrait alourdir le moteur, non ?
## Version 1.1 (27/06/2014) ##
[+] Relocalisation des dépôts sur github
[+] Mise à jour dUnzip2 en version 2.67
[+] Changement d'emplacement du dossier cache
[+] Suppression du fichier .zip du plugin téléchargé après décompression
[-] Suppression du formulaire d'installation des plugins non gérés par le dépôt de Pluxopolis
Suite à la relocalisation des plugins sur github cette mise à jour est à faire manuellement en téléchargeant le .zip. Ne pas utiliser plxMyPluginDownloader pour mettre à jour le plugin plxMyPluginDownloader
Je rencontre quelques difficultés avec la version 1.1 :
[list=*]
[*]sur Pluxopolis, le plugin est en version 1.0[/*]
[*]le dossier extrait ressemble à ceci plxMyPluginDownloader-1.0 et ne fonctionne pas si on ne le renomme pas en plxMyPluginDownloader[/*]
[/list]
Bonjour
J'ai oublié de mettre à jour le lien de téléchargement de la version 1.1
C'est corrigé
Sinon, oui, pour un téléchargement manuel il faut renommer le dossier une fois décompressé
cf: http://pluxopolis.net/myplugins, en bas de page: En cas de problème
Réponses
Encore un bon point pour Pluxml, la même chose pour les Thèmes et pluxml sera accessible pour le plus grand nombre ;O) Cooooo
l
Bienvenu au "AppPluxml Catalogue" ;o)
Merci beaucoup Stephane
Merci beaucoup !
Salut,
Quel est le plugin en question qui t'as généré cette erreur ?
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
ckeditor (1.4.2)
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
[BUG] Fatal error: Call to a member function getLang() on a non-object in plxMyPluginDownloader.php on line 166
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
+ Compatibilité PluXml 5.2
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
nouvelle version installée sur pluxml 5.2 en la téléchargeant à partir d'ici
Par contre, dans l'interface de gestion de ce plugin, j'ai une nouvelle version de proposée MyPluginDownloader - version 1.2 (04/08/2013)
Je clique sur Mettre à jour Le téléchargement et la MAJ se déroulent bien mais j'ai toujours la MAJ de proposée !!! ???
J'ai désactivé le plugin, je me suis déconnecté puis reconnecté et réactivé le plugin sans changement.
Merci pour la remontée du problème
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
Ça marche maintenant.
Je viens d'installer mon premier PluXml et j'ai tout de suite voulu y ajouter ce plugin dans le but d'en tester d'autres...
A priori l'installation s'est bien passée et j'ai bien la nouvelle entrée "MyPluginDownloader" dans le menu d'administration.
En revanche lorsque je l'active je tombe sur une page blanche avec l'erreur suivante :
Celle-ci n'est pas répertoriée dans la doc.
Est-ce que ça pourrait être une autre sorte de limitation PHP imposée par mon hébergeur ?
D'avance merci,
FP
https://code.google.com/p/my-pluxml/downloads/list
nb: le lien n'était pas le bon dans le 1er post de ce fil de discussion. J'ai mis à jour le lien
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
Cela dit je n'arrive plus à refaire marcher mon site depuis le test de MyBetterUrls, donc je ne peux pas vérifier :-)
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
Et cette version de MyPluginDownloader fonctionne en effet, merci :-)
Je me repenche sur PluXml (je le fais régulièrement) pour un projet d'un client où il conviendra parfaitement; et je tombe sur ce plugin qui m'avait échappé.
Ce plugin est générateur d'une foule de possibilités que je voudrais bien voir développées. Mais mes compétences s'arrêtent à l'architecture, ayant depuis longtemps laissé le code à des plus jeunes que moi.
D'un autre coté, je sais qu'il suffit parfois de "lâcher une idée" pour qu'un développeur s'en empare et la réalise, alors j'ose.
Voyez ce post comme une wichlist et n'hésitez pas à le déplacer si nécessaire.
1) Il serait pratique de pouvoir faire gérer tous les plugins installés sur un site, d'où qu'ils viennent, par cette extension (un peu à la manière des dépôts sous Linux); et ça n'a pas échappé à Bankai (à voir son post #44)
La structure du repository nécessaire au fonctionnement n'est pas très complexe; il serait certainement assez simple d'agréger plusieurs fichiers [repository.name].xml dans le répertoire cache en les nommant différemment.
Par exemple :
Pourquoi ? Pour disposer d'un lieu central où trouver toutes les mises à jour à faire (voir l'idée 4).
Il suffirait alors de livrer PluXml avec cet unique plugin installé (ou de l'intégrer totalement) avec le dépôt "officiel" préconfiguré pour que tout aspect technique dans l'installation de plugins disparaisse.
2) Pour fignoler le point précédent, il faudrait pouvoir simplement ajouter (et retirer) un "dépôt".
Un simple champ pour saisir une URL où aller piocher les deux fichiers .xml et .version et un fichiers XML "plugin.depots" pour en conserver la liste et en permettre la mise à jour automatique et une gestion (ajout et suppression) via une page de type "Liste des dépôts".
Pourquoi ? Pour que l'ajout de dépôt puisse se faire sans utiliser Filezilla et permette un contrôle facilité des sources de plugins.
3) Actuellement, une seule liste des plugins, complète, est affichée dans l'administration, et l'étiquette de couleur indique pour chacun s'il est installé ou pas, et s'il faut le mettre à jour.
Toujours dans une approche similaire aux dépôts d'une distribution Linux, une deuxième page (ou onglet) n'affichant que les plugins installés simplifierait le suivi de 'son' site.
La page actuelle garde toute son utilité comme catalogue des plugins disponibles, se mettant à jour au rythme des nouveautés.
Pourquoi ? Parce qu'en permettant l'agrégation de plusieurs dépôts, la liste risque d'être longue (elle l'est déjà sur le seul dépôt officiel), et l'information de mise à jour pourrait passer inaperçue.
Une autre possibilité serait de trier les plugins en plaçant ceux qui sont installés et/ou à mettre à jour en tête de liste; mais je pense que ce serait plus compliqué à réaliser, et pas forcément plus clair à utiliser.
4) Si le point trois est réalisé, créer un plugin qui intègre la boucle qui teste et détermine s'il y a mise à jour ou pas ne doit pas être bien sorcier (le foreach() avec le version_compare() dans admin.php). Reste à pouvoir l'activer régulièrement, via une crontab par exemple.
Encapsuler cette fonction dans une page accessible par un wget sur une URL ferra l'affaire; quitte à créer une URL "salée" avec une chaine de caractère pseudo aléatoire pour cela. Par exemple :
http://monsitepluxml.com/testmaj-qdC3fh7FL2smp5lFC/scanmaj.php
Dans cette page, à la suite de la boucle de test, coder l'envoi d'un mail à l'administrateur si au moins une mise à jour existe ne serait que la petite cerise sur un bien beau gâteau.
Faire le wget de cette URL à intervalle régulier (d'où la crontab) permet d'être averti dès qu'il y a des mise à jours à faire.
Pourquoi ? Pour ceux qui ne passent pas leur temps à venir visiter l'administration de leur site (ce sont les plus nombreux, croyez moi), il est bien agréable de recevoir une alerte indiquant qu'une mise à jour requiers leur attention.
Si en plus, ce plugin alerte en cas de mise à jour du core, c'est le top ;-)
5) Point cosmétique; quant un plugin est installé, il est flanqué d'une étiquette grise libellée "Télécharger"; un simple "Installé" ne serait-il pas plus clair ?
Et dans le cas de ceux qui sont installés, un bouton "Supprimer le ZIP" pourrait apparaitre si ce dernier traine encore dans le répertoire (inutile d'embarquer l'archive du plugin dans la sauvegarde journalière de l'arborescence).
Un bouton "Désinstaller" pourrait aussi être affiché.
Pourquoi ? Toujours pour retirer l'aspect technique de la gestion des plugins (et des skins si mon idée suivante abouti à quelque chose)
6) Une deuxième instance de ce plugin, ou une variante nommée différemment, pourrait facilement permettre de gérer l'installation des skins, toujours d'après un ensemble de repository (l'officiel et des PPA-like).
Pourquoi ? Comme au dessus, pour retirer toute nécessité d'action technique dans l'installation d'une skin.
Cet absence d'actes jugés "techniques" par la grande majorité des non-initiés est l'une des raisons qui leur fait choisir WordPress où ces deux aspects (plugins et thèmes) sont parfaitement intégrés et transformés en clicodromes.
Merci d'avoir lu jusque là. Voilà de quoi cette extension, dans son état actuel déjà bien pratique, m'a donné envie.
Et si ces idées vous semblent intéressantes et nécessitent plus de développements, je suis prêt à les décrire avec plus de détails.
Bon weekend
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
Sans parler de tout le travail déjà produit pour amener PluXml là où il est aujourd'hui.
En y regardant un peu plus à froid, je pense que l'actuelle page de gestion des plugins pourrait s'orner d'un troisième choix donnant sur ce plugin.
À la suite de :
Plugins actifs (X) | Plugins inactifs (Y)
on pourrait trouver un :
| Catalogue (Z)
Les fonctions de mise à jour s'intégrant à la liste des plugins actifs.
Peut-être en V6 ...
J'utilise ce plugin depuis un bon moment déjà et je le trouve tout simplement génial !
Une petite remarque tout de même : les zip ne sont pas supprimés automatiquement.
Voilou, merci pour ce plugin qui permet de gagner énormément de temps =]
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
Merci Stéphane.
je découvre pluxml, je fouine sur http://pluxopolis.net/article25/mes-plugins-pour-pluxml-sur-github
j'en charge quelqu'un dont, selon les infos.xml:
plxMyAutoMetaDescription , v1.0, 27/01/2013
MyGoogleAnalytics, v1.1, 28/06/2012
MyPrivateStatic, v1.2 19/03/2013
plus tard ci, je charge plxMyPluginDownloader, qui me trouve d'autres versions, sur googlecode?, respectivement: 1.1, 1.2, 1.3
comme selon les commentaires du lien pluxopolis, je remonte ce petit blême
PS:
si ce principe de chargement de plugin pouvait être "livré" en standard, avec un catalogue de plugins considérés un tant soit peu libres/fiables/utiles (ou un dépot central) le tout organisé par thème, cela aiderait grandement un premier arrivant à découvrir et démarrer.
juste une remarque pour appuyer l'idée déjà émise
[+] Relocalisation des dépôts sur github
[+] Mise à jour dUnzip2 en version 2.67
[+] Changement d'emplacement du dossier cache
[+] Suppression du fichier .zip du plugin téléchargé après décompression
[-] Suppression du formulaire d'installation des plugins non gérés par le dépôt de Pluxopolis
Suite à la relocalisation des plugins sur github cette mise à jour est à faire manuellement en téléchargeant le .zip. Ne pas utiliser plxMyPluginDownloader pour mettre à jour le plugin plxMyPluginDownloader
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
Je rencontre quelques difficultés avec la version 1.1 :
[list=*]
[*]sur Pluxopolis, le plugin est en version 1.0[/*]
[*]le dossier extrait ressemble à ceci plxMyPluginDownloader-1.0 et ne fonctionne pas si on ne le renomme pas en plxMyPluginDownloader[/*]
[/list]
J'ai oublié de mettre à jour le lien de téléchargement de la version 1.1
C'est corrigé
Sinon, oui, pour un téléchargement manuel il faut renommer le dossier une fois décompressé
cf: http://pluxopolis.net/myplugins, en bas de page: En cas de problème
Merci pour avoir remonté le problème
Consultant PluXml
Ancien responsable du projet (2010 à 2018)