[== PHP ==]
function file_curl_contents($url,$pretend=true){
$ch = curl_init();
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Accept-Charset: UTF-8'));
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_URL, $url);
if (!ini_get("safe_mode") && !ini_get('open_basedir') ) {curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);}
curl_setopt($ch, CURLOPT_MAXREDIRS, 10);
if ($pretend){curl_setopt($ch, CURLOPT_USERAGENT, 'Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0');}
curl_setopt($ch, CURLOPT_REFERER, 'http://mon-cul-sur-la-commode.com');// notez le referer "custom"
$data = curl_exec($ch);
$response_headers = curl_getinfo($ch);
// Google seems to be sending ISO encoded page + htmlentities, why??
if($response_headers['content_type'] == 'text/html; charset=ISO-8859-1') $data = html_entity_decode(iconv('ISO-8859-1', 'UTF-8//TRANSLIT', $data));
curl_close($ch);
return $data;
}
Et bien le zip est téléchargé normalement (ce n'est plus un fichier tronqué...)
Donc, le soucis viendrait de la fonction downloadRemoteFile.
Je continue à chercher et je tiens au courant en temps réel ^^
Depuis un navigateur, tout baigne.
Par contre, avec curl, on a une belle erreur 404, quelle que soit la demande. Et le zip téléchargé, si le repo est chez jéjé ne se dezippe pas.
Est-ce ça qui merdouille
if (!ini_get("safe_mode") && !ini_get('open_basedir') )
[del]Deux [/del] Trois petites améliorations toutefois :
* le bouton "installé" relance le téléchargement quand on clique dessus
* il faudrait voir de modifier l'interface vu que le nombre de dépôt va augmenter.
* classer les plugins chargés par ordre alphabétique (si le fichier xml des dépôts pouvait l'être également)
Faut-il réfléchir à une "certification" du dépôt pour être sûr de ce que l'on charge ???
Un petit résumé des futures améliorations possibles pour la partie dépot plugins:
[list=*]
[*]gestion de la compatiblité des plugins avec la version courante de pluxml <compatibility>5.1.6,5.1.7</version>[/*]
[*]le bouton "installé" redirige vers la page des plugins (actifs ou inactifs)[/*]
[*]Scinder les onlgets en 2 catégories : depots officiels et non officiels <official>1</official>[/*]
[*]Updater un plugin zippé manuellement[/*]
[*]Intégrer un moteur de recherche dans les plugins non officiels (recherche par dépots, par nom et description[/*]
[*]Prevoir un champs en anglais popur le nom et la description du plugin et des dépots[/*]
[*]Pouvoir classer les plugins chargés par ordre alphabétique[/*]
[*]Réfléchir à une "certification" du dépôt[/*]
[/list]
Dépot thèmes:
[list=*]
[*]Avoir la meme logique que les plugins (stores, depot des themes, présentation...)[/*]
[*]ajout des champs pour savoir les plugins nécessaires liés au thème <plugins>spxshortcodes,Mybetterurl</plugins>[/*]
[*]Rajout d'un fichier infos.xml dans le thème (comme les plugins) pour que spxplugindownloader puisse gérer les thèmes[/*]
[*]Rajout d'un lien vers une copie d'écran du thème (sympa d'avoir une preview)[/*]
[/list]
Et voila pour le moment je n'ai pas une <big><form> donc il <meta>rde me mettre à <table>.
Hi !
gesttion de la compatiblité des plugins avec la version courante de pluxml <compatibility>5.1.6,5.1.7</version>
Très bonne idée ! (même si ça sous entend de tester le plugin sur plusieurs versions oO)
le bouton "installé" redirige vers la page des plugins (actifs ou inactifs)
Bien aussi, toujours donner une fonction de plus aux décorations ^^
Scinder les onlgets en 2 catégories : depots officiels et non officiels <official>1</official>
Bonne idée aussi, c'est un critère qui m'a effleuré: il faurait du coup que les plugins répondent à un certain degré d'exigence (traduction possible, normalisation se la feuille de style pour la rendre compatible avec le lien editer les css tout ça...), non ?
Updater un plugin zippé manuellement
Pas saisi :-)
Intégrer un moteur de recherche dans les plugins non officiels (recherche par dépots, par nom et description
Si on ajoute beaucoup de dépôts, ça me paraît une bonne idée.
Prevoir un champs en anglais popur le nom et la description du plugin et des dépots
L'internationalisation est toujours nécessaire à partir d'un certain moment ^^
Du coup c'est un champ de plus dans les infos de dépôt... Peut-être pourrait-on récupérer les infos dans les fichiers de langue fr.php en.php etc..., non ?
Voire même les afficher en fonction de la langue de l'utilisateur admin.
Pouvoir classer les plugins chargés par ordre alphabétique
Pourquoi pas, c'est pas le temps que ça prend: je pourrais même le faire directement dans repositorix.
Réfléchir à une "certification" du dépôt
Bonne idée: sur quels critères ?
Avoir la meme logique que les plugins (stores, depot des themes, présentation...)
ajout des champs pour savoir les plugins nécessaires liés au thème <plugins>spxshortcodes,Mybetterurl</plugins>
Essentiel en effet, même si peu de thèmes doivent être concernés, je pense.
Rajout d'un fichier infos.xml dans le thème (comme les plugins) pour que spxplugindownloader puisser gérer les thèmes
Du coup ça deviendrait une directive officielle.
Rajout d'un lien vers une copie d'écran du thème (sympa d'avoir une preview)
En effet: pour moi c'est même essentiel ^^
Je vais sûrement dire une bêtise (une de plus), mais :
Tant qu'à faire un plugin qui va finir par être plus gros qu'un PluXml de base ( :P ), pourquoi ne pas en faire un site (avec miroirs ?) sur lequel les utilisateurs renseigneraient l'adresse de leur(s) pluxml(s) et pourraient ainsi recevoir (par l'intermédiaire d'un petit plugin) les notifications de mises à jour des dépôts existants, l'ouverture (ou la fermeture) d'un nouveau dépôt, d'un nouveau plugin, d'un nouveau thème etc.
No ?
Un genre d'annuaire de plugins, donc...
Mais comment l'intégrer à PluXML ?
Car l'intérêt de ce plugin, c'est précisément qu'il est parfaitement intégré au cms, comme une rubrique market à part entière: il est inutile d'aller dans une autre appli ou sur un autre site.
En plus, le plugin en lui-même reste dans des tailles très raisonnables et ne complique pas tellement l'architecture native ^^
(Tu verrais mon plugin de galerie )
Pour ma part, je le trouve tellement bien qu'il me semble qu'il faudrait songer à l'intégrer à pluXML, sous une forme ou une autre (seule la présence de deux espaces dédiés aux plugins peut déconcerter un peu mais elle me semble logique: une partie pour télécharger/mettre à jour et une pour gérer les plugins locaux.)
Le module de ressources est (toujours) en cours de développement. Mais il finira par arriver. Il permettra d'être une vitrine claire de ce qui gravite autour de Pluxml (plugins et thèmes).
Pour ce qui est de ce plugins, c'est en effet une sorte de market dont le code est très léger en fait.
Hi !
gestion de la compatiblité des plugins avec la version courante de pluxml <compatibility>5.1.6,5.1.7</version>
Très bonne idée ! (même si ça sous entend de tester le plugin sur plusieurs versions oO)
Non, il suffit que l'auteur mette à partir de quelle version il a développé son plugin.
Scinder les onlgets en 2 catégories : depots officiels et non officiels <official>1</official>
Bonne idée aussi, c'est un critère qui m'a effleuré: il faurait du coup que les plugins répondent à un certain degré d'exigence (traduction possible, normalisation se la feuille de style pour la rendre compatible avec le lien editer les css tout ça...), non ?
Non, les plugins officiels sont ceux développés par l'équipe officielle ou ceux que l'équipe officielle accepte de prendre en "gestion" en plus du développeur d'origine. Ça arrive peu souvent. Donc il n'y a qu'un dépôt qui répond à ce critère et c'est celui de Stephane (pluxopolis).
Les autres sont donc par essence, non-officiels.
Updater un plugin zippé manuellement
Pas saisi :-)
Si tu pousses un dossier de plugin par ftp sans passer par le plugin, il faudrait qu'il soit aussi pris en compte. Mais je ne vois pas trop comment gérer sans alourdir le binzou.
Intégrer un moteur de recherche dans les plugins non officiels (recherche par dépots, par nom et description)
Si on ajoute beaucoup de dépôts, ça me paraît une bonne idée.
Prevoir un champs en anglais popur le nom et la description du plugin et des dépots
L'internationalisation est toujours nécessaire à partir d'un certain moment ^^
Du coup c'est un champ de plus dans les infos de dépôt... Peut-être pourrait-on récupérer les infos dans les fichiers de langue fr.php en.php etc..., non ?
Voire même les afficher en fonction de la langue de l'utilisateur admin.
Je ne pense pas qu'il faille ajouter quoi que ce soit. Libre à chaque développeur d'utiliser la langue qu'il souhaite.
Pouvoir classer les plugins chargés par ordre alphabétique
Pourquoi pas, c'est pas le temps que ça prend: je pourrais même le faire directement dans repositorix.
Ça serait très pratique à l'usage. Si le fichier xml est déjà classé, on gagnerait du temps dans le traitement des infos ensuite.
Réfléchir à une "certification" du dépôt
Bonne idée: sur quels critères ?
C'est LA question : actuellement, on fait ça entre nous. On a confiance et on télécharge les yeux fermés. Mais quid de l'avenir et de ce qui sera proposé. Il ne faudrait pas mettre le loup dans la bergerie.
Avoir la même logique que les plugins (stores, dépôt des thèmes, présentation...)
ajout des champs pour savoir les plugins nécessaires liés au thème <plugins>spxshortcodes,Mybetterurl</plugins>
Essentiel en effet, même si peu de thèmes doivent être concernés, je pense.
Rajout d'un fichier infos.xml dans le thème (comme les plugins) pour que spxplugindownloader puisser gérer les thèmes
Du coup ça deviendrait une directive officielle.
Ça serait bien en effet. Directive officielle mais facultative. Celui qui ne veut pas partager son thème ne le met pas.
Je viens de plonger un peu dans le forum et je découvre pas mal de trucs, comme quoi un peu d'absence ne fait pas de mal
Je me suis motivé pour remettre mon plugin hamGravatar à jour pour Pluxml 5.4 et du coup, j'en ai profité pour créer un dépôt.
Je dois également me pencher sur hamRSS pour voir si tout marche bien avec la 5.4 et il devra rejoindre son petit frères (et d'autres je pense) dans mon dépôt.
Réponses
Bon, j'ai localisé le problème en faisant une modif à la pelle de chantier, pour tester:
avec ma fonction de curl perso:
Et bien le zip est téléchargé normalement (ce n'est plus un fichier tronqué...)
Donc, le soucis viendrait de la fonction downloadRemoteFile.
Je continue à chercher et je tiens au courant en temps réel ^^
Par contre, avec curl, on a une belle erreur 404, quelle que soit la demande. Et le zip téléchargé, si le repo est chez jéjé ne se dezippe pas.
Est-ce ça qui merdouille et qui n'est pas dans la version de jéjé ???
Voici une version 2.3 qui devrait corriger nos problèmes.
Pouvez-vous la tester et me dire si c'est ok pour vous les zip de bronco ?
Voici le lien : ici
## Version spx 2.3 (23/03/2015) ##
BUG: fix bug for downloadRemoteFile (downloadRemoteFile2 with bronco method)
Si ça marche merci a bronco !!!! (je suis pour le retour aux bottes et aux chapeaux de cowboy
Je mettrais à jour les liens dans le magasin des dépots pour branco car la méthode zip, version et xml sont les memes.
a+
jéjé
[del]Deux [/del] Trois petites améliorations toutefois :
* le bouton "installé" relance le téléchargement quand on clique dessus
* il faudrait voir de modifier l'interface vu que le nombre de dépôt va augmenter.
* classer les plugins chargés par ordre alphabétique (si le fichier xml des dépôts pouvait l'être également)
Faut-il réfléchir à une "certification" du dépôt pour être sûr de ce que l'on charge ???
Les améliorations vont venir pas de soucis. Je prends note de tes remarques Jerry.
L'important était la correction du depot de bronco. C'est cool.
a noter l'excellent article : Repositorix: un gestionnaire de dépôt pour spxplugindownloader (ou comment automatiser son centre de dépot made by bronco)
Pour le moment, je suis en mode papa-goûter-devoirs-bains-dîner-les-dents-au-lit... mais après, no souçaille
à plus,
Gzyg
Excellent !!!!
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Je la ressortirai (la blague, hein ? La blague...).
Un petit résumé des futures améliorations possibles pour la partie dépot plugins:
[list=*]
[*]gestion de la compatiblité des plugins avec la version courante de pluxml <compatibility>5.1.6,5.1.7</version>[/*]
[*]le bouton "installé" redirige vers la page des plugins (actifs ou inactifs)[/*]
[*]Scinder les onlgets en 2 catégories : depots officiels et non officiels <official>1</official>[/*]
[*]Updater un plugin zippé manuellement[/*]
[*]Intégrer un moteur de recherche dans les plugins non officiels (recherche par dépots, par nom et description[/*]
[*]Prevoir un champs en anglais popur le nom et la description du plugin et des dépots[/*]
[*]Pouvoir classer les plugins chargés par ordre alphabétique[/*]
[*]Réfléchir à une "certification" du dépôt[/*]
[/list]
Dépot thèmes:
[list=*]
[*]Avoir la meme logique que les plugins (stores, depot des themes, présentation...)[/*]
[*]ajout des champs pour savoir les plugins nécessaires liés au thème <plugins>spxshortcodes,Mybetterurl</plugins>[/*]
[*]Rajout d'un fichier infos.xml dans le thème (comme les plugins) pour que spxplugindownloader puisse gérer les thèmes[/*]
[*]Rajout d'un lien vers une copie d'écran du thème (sympa d'avoir une preview)[/*]
[/list]
Et voila pour le moment je n'ai pas une <big><form> donc il <meta>rde me mettre à <table>.
a+
gesttion de la compatiblité des plugins avec la version courante de pluxml <compatibility>5.1.6,5.1.7</version>
Très bonne idée ! (même si ça sous entend de tester le plugin sur plusieurs versions oO)
le bouton "installé" redirige vers la page des plugins (actifs ou inactifs)
Bien aussi, toujours donner une fonction de plus aux décorations ^^
Scinder les onlgets en 2 catégories : depots officiels et non officiels <official>1</official>
Bonne idée aussi, c'est un critère qui m'a effleuré: il faurait du coup que les plugins répondent à un certain degré d'exigence (traduction possible, normalisation se la feuille de style pour la rendre compatible avec le lien editer les css tout ça...), non ?
Updater un plugin zippé manuellement
Pas saisi :-)
Intégrer un moteur de recherche dans les plugins non officiels (recherche par dépots, par nom et description
Si on ajoute beaucoup de dépôts, ça me paraît une bonne idée.
Prevoir un champs en anglais popur le nom et la description du plugin et des dépots
L'internationalisation est toujours nécessaire à partir d'un certain moment ^^
Du coup c'est un champ de plus dans les infos de dépôt... Peut-être pourrait-on récupérer les infos dans les fichiers de langue fr.php en.php etc..., non ?
Voire même les afficher en fonction de la langue de l'utilisateur admin.
Pouvoir classer les plugins chargés par ordre alphabétique
Pourquoi pas, c'est pas le temps que ça prend: je pourrais même le faire directement dans repositorix.
Réfléchir à une "certification" du dépôt
Bonne idée: sur quels critères ?
Avoir la meme logique que les plugins (stores, depot des themes, présentation...)
ajout des champs pour savoir les plugins nécessaires liés au thème <plugins>spxshortcodes,Mybetterurl</plugins>
Essentiel en effet, même si peu de thèmes doivent être concernés, je pense.
Rajout d'un fichier infos.xml dans le thème (comme les plugins) pour que spxplugindownloader puisser gérer les thèmes
Du coup ça deviendrait une directive officielle.
Rajout d'un lien vers une copie d'écran du thème (sympa d'avoir une preview)
En effet: pour moi c'est même essentiel ^^
A+ Jéjé !
Tant qu'à faire un plugin qui va finir par être plus gros qu'un PluXml de base ( :P ), pourquoi ne pas en faire un site (avec miroirs ?) sur lequel les utilisateurs renseigneraient l'adresse de leur(s) pluxml(s) et pourraient ainsi recevoir (par l'intermédiaire d'un petit plugin) les notifications de mises à jour des dépôts existants, l'ouverture (ou la fermeture) d'un nouveau dépôt, d'un nouveau plugin, d'un nouveau thème etc.
No ?
à plus,
Gzyg
Mais comment l'intégrer à PluXML ?
Car l'intérêt de ce plugin, c'est précisément qu'il est parfaitement intégré au cms, comme une rubrique market à part entière: il est inutile d'aller dans une autre appli ou sur un autre site.
En plus, le plugin en lui-même reste dans des tailles très raisonnables et ne complique pas tellement l'architecture native ^^
(Tu verrais mon plugin de galerie
Pour ma part, je le trouve tellement bien qu'il me semble qu'il faudrait songer à l'intégrer à pluXML, sous une forme ou une autre (seule la présence de deux espaces dédiés aux plugins peut déconcerter un peu mais elle me semble logique: une partie pour télécharger/mettre à jour et une pour gérer les plugins locaux.)
Pour ce qui est de ce plugins, c'est en effet une sorte de market dont le code est très léger en fait. Non, il suffit que l'auteur mette à partir de quelle version il a développé son plugin. C'est sûr
Les autres sont donc par essence, non-officiels. Si tu pousses un dossier de plugin par ftp sans passer par le plugin, il faudrait qu'il soit aussi pris en compte. Mais je ne vois pas trop comment gérer sans alourdir le binzou. Essentielle même. Je ne pense pas qu'il faille ajouter quoi que ce soit. Libre à chaque développeur d'utiliser la langue qu'il souhaite. Ça serait très pratique à l'usage. Si le fichier xml est déjà classé, on gagnerait du temps dans le traitement des infos ensuite. C'est LA question : actuellement, on fait ça entre nous. On a confiance et on télécharge les yeux fermés. Mais quid de l'avenir et de ce qui sera proposé. Il ne faudrait pas mettre le loup dans la bergerie. Oui, essentiel. Ça serait bien en effet. Directive officielle mais facultative. Celui qui ne veut pas partager son thème ne le met pas. Oui et c'est ce qui donne envie. Il faudrait par contre définir des dimensions standard pour les images ainsi que leur nombre max.
## Version spx 2.4 (30/07/2015) ##
DISPLAY: fix css for pluxml 5.4
Bronco j'ai un petit soucis avec ton repository.version ?? tu as modifié un truc ?
Depot de Jormun avec les plugins Advanced Search, CaTags, My HTML Tags, SimpleStat, Gravatar, filAriane
Bienvenue dans l'équipe des dépots !
A noter l'article suivant pour intégrer vos plugins dans la liste des dépots : ici
a+
jeje
Faudrait mettre à jour le dépot des best-of, avec les dernières version des plugins
Ah oui, et je l'avais pas vu venir le coup du referrer "mon-cul-sur-la-commode" du coup je l'avais bloquer, je comprenais pas ce que c'etait !
Je viens de plonger un peu dans le forum et je découvre pas mal de trucs, comme quoi un peu d'absence ne fait pas de mal
Je me suis motivé pour remettre mon plugin hamGravatar à jour pour Pluxml 5.4 et du coup, j'en ai profité pour créer un dépôt.
Je dois également me pencher sur hamRSS pour voir si tout marche bien avec la 5.4 et il devra rejoindre son petit frères (et d'autres je pense) dans mon dépôt.
Possible de me rajouter ?
https://github.com/Hamtar0/repository/tree/master
Merci d'avance.
Je viens de te rajouter ce qui donne le code suivant :
Si tu as un lien pour l'icon autre que git ?
Bonco : j'ai toujours un soucis sur ton depot... J'ai pas trouvé d'ou ça venait. Voila ce que j'obtiens :
A noter que je vais intégrer un moteur de recherche prochainement avec surement une gestion des tags.
a+
jeje
Dis moi si c'est mieux.
Tout va bien pour toi
N'affiche pas le dépot si le depot ne répond pas (numéro de version absent)
## Version spx 2.5 (17/08/2015) ##
BUG: hide a repository if version = 0 or ""
http://forum.pluxml.org/search.php?action=show_user_topics&user_id=19285
Tels que cssNoCache, plnExtendedJurisdiction, plnCalendrier, plnPrivatePages , plnStaticPages et etc ;-) Merci (sans savoir ce qu'en pense lui meme!)