Dotclear

Vous n'êtes pas identifié(e).

Annonce

13 février 2024 Sortie de Dotclear 2.29

#1 2018-10-27 11:03:48

pierrevg
Membre
Inscription : 2005-04-13
Site Web

[dlManager] Support du plugin

Salut,

Quelqu'un pour m'aider à résoudre un bug ?

https://www.brol.info/mediaplayer/1762

WARNING /homepages/15/d258054173/htdocs/brol/all-blogs/plugins/dlManager/_public.php:366        Creating default object from empty value        1       /download/1737
Trace d'exécution

    [/homepages/15/d258054173/htdocs/brol/dotclear/inc/libs/clearbricks/url.handler/class.url.handler.php:166] : dlManagerPageDocument::download
    [/homepages/15/d258054173/htdocs/brol/dotclear/inc/public/lib.urlhandlers.php:187] : urlHandler::callHandler
    [/homepages/15/d258054173/htdocs/brol/dotclear/inc/public/prepend.php:161] : dcUrlHandlers::getDocument
    [/homepages/15/d258054173/htdocs/brol/brol/index.php:3] : ::require

Merci

Hors ligne

#2 2018-10-27 12:04:48

nanart
Membre
Lieu : Roubaix
Inscription : 2007-08-19

Re : [dlManager] Support du plugin

Premier constat:

Quand on ajoute un média, la page publique ne se met pas a jour "automatiquement".

Quant on enregistre la configuration dans l'admin du plug, la mise à jour est effectuée.

Idem pour ce qui concerne la mise en mode "privé" d'un média.

L'actualisation de la page publique ne se fait que si on on sauvegarde à nouveau la configuration du plugin depuis sa page d'administration.

D'après ce que je comprends: le widget ne remet pas à jour les listes des fichiers téléchargeables, même après la réactualisation de la page publique, si on a pas sauvegardé à nouveau la config du plug....

Il semble donc qu'une réactualisation de la liste des fichiers disponibles - et de la config du plug?, doit aussi se faire - ou être appelée(s), quelque part dans le fichier _widget.

J'avoue ne pas utiliser - et donc comprendre, le fonctionnement des fichiers _widget. Va falloir que je creuse.

Mais si quelqu'un a une idée du comment faire ce serait un pas de géant :-)

Dernière modification par nanart (2018-10-27 12:24:45)


Dernière version stable Dotclear sur wampserver et chez ovh
Versions testing & unstable en local
https
php: 7.4  - 8 +

Hors ligne

#3 2018-10-27 12:29:08

nanart
Membre
Lieu : Roubaix
Inscription : 2007-08-19

Re : [dlManager] Support du plugin

En fait, en ayant fouillé un peu il a deux endroits "publics"
Le widget (dont j'ai tiré les conclusions ci-dessus) et une page publique.
Les deux proposent une liste de medias et réagissent de la même façon: pas de réactualisation des fichiers téléchargeables.
Du coup, il manque quelque chose dans ces deux fichiers (ou avant?) qui réactualise la config -et notamment la liste des fichiers...


Dernière version stable Dotclear sur wampserver et chez ovh
Versions testing & unstable en local
https
php: 7.4  - 8 +

Hors ligne

#4 2018-10-27 15:33:16

Philippe
Stagiaire
Lieu : Toulon
Inscription : 2004-06-13
Site Web

Re : [dlManager] Support du plugin

Le plugin intègre-t-il la fonction $core->blog->triggerBlog(); dans l'enregistrement de la configuration ? Et lors de l'ajout d'un média ?

Hors ligne

#5 2018-10-27 15:52:39

pierrevg
Membre
Inscription : 2005-04-13
Site Web

Re : [dlManager] Support du plugin

Comme les médias peuvent être ajoutés directement via ftp (avec un passage via la médiathèque depuis l'admin du blog pour actualiser la liste des médias dispos), je me dis que le soucis de mise à jour de la liste des médias dispos est un peu accessoire, non ?

Hors ligne

#6 2018-10-27 17:26:09

nanart
Membre
Lieu : Roubaix
Inscription : 2007-08-19

Re : [dlManager] Support du plugin

Philippe: Concernant triggerBlog(), j'ai pas fouillé. Le plug est assez complexe, va falloir que je fasse des tests / quelle fonction fait quoi ?

pierrebg: la liste des médias (et autres fichiers) à disposition est importante car c'est celle qui doit alimenter les listes publiques des fichiers disponibles, tenant compte des fichiers à ne pas afficher, supprimés, renommés, ou mis en privé, par ex;
L'erreur indique bien un "objet" qui est 'empty', cad, par extension, qui se réfère à un fichier qui n'existe pas/plus.
C'est ce qui semble se passer quand la liste des fichiers à disposition n'est pas réactualisée avant affichage et qu'un fichier a été supprimé, (quelque soit le mode de suppression)

EDIT:
la ligne erreur est générée après un try/catch d'une fonction download($args) de la classe class dlManagerPageDocument extends dcUrlHandlers
Va falloir fouiller ce qui rejette le try en catch error (le message),

EDIT 2:
La fonction download est appelée à partir de l'url générée dans la liste des fichiers dispos, partie public
Ex: blog/index/download/1
C'est donc un entier qui est examiné dans la fonction.
Si on tape n'importe quoi genre 'abcde' -> erreur 404, donc captée avant try
Si on on tape un entier, genre 123425 -> erreur objet donc try=>catch

Dernière modification par nanart (2018-10-27 18:20:58)


Dernière version stable Dotclear sur wampserver et chez ovh
Versions testing & unstable en local
https
php: 7.4  - 8 +

Hors ligne

#7 2018-10-28 09:10:05

Philippe
Stagiaire
Lieu : Toulon
Inscription : 2004-06-13
Site Web

Re : [dlManager] Support du plugin

nanart a écrit :

Philippe: Concernant triggerBlog(), j'ai pas fouillé. Le plug est assez complexe, va falloir que je fasse des tests / quelle fonction fait quoi ?

triggerBlog() vide le cache de template, afin que les réglages enregistrés soient pris en compte côté public si nécessaire. Après un rapide coup d’œil, cette fonction est bien appelée dans l'index.php du plugin à la ligne 65. Mais cela concerne uniquement l'enregistrement de la configuration.

J'ai testé l'ajout et la suppression de fichiers dans le répertoire des téléchargements, et constaté aussi que la page publique n'est pas mise à jour avant l'enregistrement suivant de la config... qui appelle justement triggerBlog()

Or cette fonction ne semble pas appelée si on ajoute ou supprime un fichier dans le répertoire de téléchargements. Elle ne l'est pas a priori dans la médiathèque, et il faudrait chercher plus avant pour savoir si et comment le plugin intercepte l'évènement "fichier ajouté/supprimé avec succès dans le répertoire surveillé"

Pour le warning php, je ne parviens pas encore à le reproduire (en local avec php 7.2.6)...

Hors ligne

#8 2018-10-28 09:51:36

Philippe
Stagiaire
Lieu : Toulon
Inscription : 2004-06-13
Site Web

Re : [dlManager] Support du plugin

J'ai bien reçu un message d'erreur identique à celui en #1 de ce fil, en cliquant sur un lien de téléchargement côté public (je crois que le fichier avait été supprimé de la médiathèque, mais la page publique n'était pas actualisée)

À tester : dans le fichier public.php du plugin, remplacer les 4 occurrences de $_ctx->form_error = $e->getMessage(); par $core->error->add($e->getMessage());

De chez moi ça semble résoudre le warning

@nanart : après vérification, le plugin ne "surveille" pas le dossier de téléchargement. Seul l'enregistrement de la configuration vide le cache de template. C'est donc le comportement normal en l'état ;)

Hors ligne

#9 2018-10-28 11:07:24

nanart
Membre
Lieu : Roubaix
Inscription : 2007-08-19

Re : [dlManager] Support du plugin

Bonjour,
Merci de tes tests. Je vais prendre un peu de temps avant d'aller plus loin.

Dans ma démarche, j'ai remarqué qu'il semble que la liste des fichiers disponibles est effectuée à un moment donné et est accessible par les urls affichés dans la page publique ou le widget.
Dans mon premier test, la liste est mis à jour lorsqu'on enregistre la config depuis l'administration du plug, puisque en faisant cela et en réactualisant les page/widget coté interface publique, la liste est à jour.

Quant au traitement de l'erreur, je vois deux possibilités :
1) on ne traite que l'erreur occasionnée par un "objet" n'existant pas ou plus
2) on la traite avant qu'elle ne se déclenche, cad, avant affichage des fichiers dispos.

La première solution permet d'éviter l'erreur mais, à vérifier, ne devrait pas réactualiser la liste.
La seconde permet d'éviter les erreurs dûes à l'affichage (actualisation des urls), mais ne traite pas les erreurs autres (par exemple si la page publique n'est pas réactualisée - ctrl/f5)

Donc, amah, il y aurait deux problèmes à traiter :
1) interception des erreurs (quelqu'elles soient),
2) actualisation de la liste des fichiers dispos avant affichage


Dernière version stable Dotclear sur wampserver et chez ovh
Versions testing & unstable en local
https
php: 7.4  - 8 +

Hors ligne

#10 2018-10-29 13:41:00

nanart
Membre
Lieu : Roubaix
Inscription : 2007-08-19

Re : [dlManager] Support du plugin

Bonjour,

Remplacement suggéré

Philippe a écrit :

4 occurrences de $_ctx->form_error = $e->getMessage(); par $core->error->add($e->getMessage());

concerne les fonctions page, player, download et viewfile - partie catch (Exception $e).
Il permet, si je comprends bien, de capturer l'erreur pour (éventuellement) l'afficher "proprement".
Je n'ai pas testé dans les cas où les fichiers incriminés sont effacés ou renommé.

Problème:
Si je tente de télécharger un fichier marqué comme privé, une page blanche s'affiche (donc erreur php ?).
Cela me parait logique car le téléchargement s'effectue par la fonction download - qui générait l'erreur décrite et qui n'affiche aucun résultat et propose seulement le téléchargement s'il existe (ou l'erreur signalée, si erreur).

Donc, à priori, il ne suffit pas de capturer l'erreur, encore faut-il la traiter ????
Dans le cas de la fonction download, le try cherche si le fichier est accessible (is_readable).
Or, il l'est. Mais étant donné qu'il est en mode privé, il ne peut être chargé.
Cette autre condition (privé?) doit donc, amha, aussi être testée.
Là, je ne sais pas comment faire.
Va falloir que je creuse....

Remarque
Quand, sur la page publique, on modifie l'ordre d'affichage ou si on change de répertoire - quand un sous répertoire existe, la liste se met à jour, y compris dans le widget et y compris dans le cas d'un fichier mis en mode privé (pas accessible coté public)

Encore à creuser donc.
Mais on progresse :-)


Dernière version stable Dotclear sur wampserver et chez ovh
Versions testing & unstable en local
https
php: 7.4  - 8 +

Hors ligne

#11 2018-10-31 14:13:29

nanart
Membre
Lieu : Roubaix
Inscription : 2007-08-19

Re : [dlManager] Support du plugin

Bonjour,
Pour aller + loin, je fais, doucettement, un descriptif des actions et méthodes des différents scripts.
Donc, patience ;-)


Dernière version stable Dotclear sur wampserver et chez ovh
Versions testing & unstable en local
https
php: 7.4  - 8 +

Hors ligne

#12 2018-11-01 18:58:41

nanart
Membre
Lieu : Roubaix
Inscription : 2007-08-19

Re : [dlManager] Support du plugin

Remarques:
1) à confirmer, si le nom du fichier est modifié via l'interface admin/media, il semble que
(après simple rafraichissement de la page téléchargements du plug) :
- le titre/title du lien est modifié (cf code source)
- le fichier est téléchargé sous le nom 'non modifié'.

ce qui semblerait indiquer, sauf erreur de ma part, que seule une petite partie des infos concernant le fichier sont mis à jour par le plug.

2) concernant le lien vers le fichier dans admin/media, le fichier semble référencé par son id.
Ex:

http://dcforms/admin/media_item.php?popup=0&select=0&id=2&tab=media-details-tab

C'est, amha, sur cet id que s'appuie le plug

3) si on suit le lien ci-dessus, en modifiant l'id par un id qui n'existe pas: Dc renvoie un message d'erreur "fichier invalide".
Idem si on supprime le fichier directement dans le dossier public/media
(testé sous windows, pas testé via ftp, mais amha c'est équivalent)
sans rafraichissement de la page admin/media

4) dans le plug, pour un fichier supprimé, la prévisualisation renvoie une cadre sans infos ni erreur.
Le téléchargement génère l''erreur décrite en début de ce post.


C'est donc bien un pb du plug qui ne vérifie pas si le fichier correspondant à l'id existe bien.

[EDIT]
L'id généré par Dc correspond au champ 'media_id' de la table 'dc_media'... qui est une clé primaire.
Donc, il conviendrait peut-être :
1) de vérifier si l'id est dans la table media
2) de voir comment Dc gère media_item afin de déterminer l'erreur

[edit2]
erreur cache perçue après modif du répertoire racine et rafraichissement simple de la page téléchargement.
Indique absence vidage du cache ? (absence  triggerBlog() ?)

Dernière modification par nanart (2018-11-01 20:02:15)


Dernière version stable Dotclear sur wampserver et chez ovh
Versions testing & unstable en local
https
php: 7.4  - 8 +

Hors ligne

#13 2018-11-03 14:24:37

nanart
Membre
Lieu : Roubaix
Inscription : 2007-08-19

Re : [dlManager] Support du plugin

Bonjour,
Pas fini l'inspection du code mais, première remarque à propos de l'erreur citée, en réponse à un fichier supprimé.

En examinant les codes du script _public, les opérations (redondantes) effectuées par les différentes fonctions sont
1) appel à la fonction statique check() qui vérifie
   * si le plug est activé
  * si le répertoire 'racine' existe
si une de ces conditions n'est pas exacte, renvoie vers 404 et return

2) on traite l’argument passé à la fonction
pour la fonction download, on vérifie si l'argument est numérique (sinon 404, return)

3) ensuite on teste (try) :
   * en récupérant la liste du 'contenu' des fichiers en utilisant la méthode getFile de la librairie dlManager de Dotclear en lui envoyant l'argument qui est une id unique, issu de la table des medias
  - et on traite le résultat de la fonction Dc getFile

Pour ce qui concerne la suite, chaque fonction du plug traite ce résultat comme étant
  * ou vide ou 'non vide'  (empty)

Or, la fonction  getFile semble renvoyer :
   * soit un objet complet, dont l'état du statut private (bool)
   * soit 1 (true) même si le fichier n'existe pas

En conséquence, si on considère la méthode download du plug,
* si la réponse (files= return de la méthode de la méthode dlManager/getFile   de DC) n'est 'pas vide', on traite comme si le fichier existe !!!

[edit]
code.../code
la vérification proposée ne convient pas !
Notes:
* Il faudrait appliquer une vérification sur $file est objet + ? et, après contrôle du statut private à partie du résultat de la méthode getFile de Dc
renvoyant vers 404
[/edit]

Ceci dit, je trouve un peu léger de renvoyer systématiquement vers une page 404 en cas d'erreur.
Il faudrait, comme pour le traitement d'erreur après les try, renvoyer vers un message d'erreur qui s'affiche.

Par ailleurs, il faudrait améliorer:
* étant donné le nombre d'opérations redondantes dans les différents scripts, renvoi vers des méthodes de la classe dlManager du plug ?
* compléter la traduction, en virant aussi le fichier _public_l10n.php en racine inutilisé
* améliorer la possibilité de configuration du widget, par ex, en proposant une liste de propositions plutôt qu'un textarea 'Affichage d'un élément '
- par ailleurs sans indication du 'comment faire' !
* de même, dans la configuration du plug, lorsqu'il s'agit d'aller modifier "about:config (system)"...
* pourquoi pas un bouton 'actualiser' dans la page des téléchargements ?
* résoudre la contradiction qui existe dans le choix du dossier racine, qui se fait dans la config du plug et dans la config du widget;
ce d'autant plus, sauf erreur de ma part, que mettre, dans le widget, un dossier racine différent de celui de la config, ne semble rien changer: c'est le dossier de la config qui est affiché (?)
* plus, de même, activer/ou pas cacher les urls dans la config du plug, semble ne pas s'appliquer ???
* et... compléter la partie "Options avancées" dans la config du plug;

Bref, en résumé, amha, résoudre deux pbs (erreurs fichier manquant ET fichier private ne me parait pas suffisant.
Il faut aussi, amah, que l'utilisateur du plug soit informé directement des résultats en erreur et non pas redirigé vers une 404
et qu'il soit assisté lors de la configuration du plug et du widget.

à suivre, donc, au moins pour ce qui me concerne:
- le traitement de l'erreur en cas de fichier 'private'
- le traitement des visualisations vides
- le cas des erreurs à partir du widget

et, éventuellement proposition d'améliorations (par présentation de modifs du script)

Dernière modification par nanart (2018-11-03 16:12:41)


Dernière version stable Dotclear sur wampserver et chez ovh
Versions testing & unstable en local
https
php: 7.4  - 8 +

Hors ligne

#14 2018-11-03 16:05:34

nanart
Membre
Lieu : Roubaix
Inscription : 2007-08-19

Re : [dlManager] Support du plugin

Etourderie, fatigue ou distraction ?
Toujours est-il que ma proposition (supprimée du précédent post) ne semble pas correctement marcher.

Chez moi:
Les vérifications -et le renvoi vers 404, doivent se faire avant try.
Dans le cas contraire, affichage page blanche.

En résumé, j'ai testé autrement
- avant le try, on obtient l'objet avec la méthode getFile :

$file = $core->media->getFile($args);
 

pas besoin de tester car la méthode Dc gère

ensuite, on vérifie qu'on a bien un objet, sinon 404

if (!is_object($file))
{
	self::p404();
	return;
}
 

enfin on supprime la ligne inutile dans try - mais on peut conserver sans pb
$file = $core->media->getFile($args);

ça a l'air ok, au moins pour cette erreur, sachant que rediriger vers une 404 sans info sur l'erreur, c'est beurk

Sinon, tester si pour vous c'est ok avec la vérif dans try; chez moi page blanche...

 try
    {
        $file = $core->media->getFile($args);
        if (!is_object($file))
             {
                 self::p404();
                 return;
            }

Dernière version stable Dotclear sur wampserver et chez ovh
Versions testing & unstable en local
https
php: 7.4  - 8 +

Hors ligne

#15 2018-11-03 16:36:29

pierrevg
Membre
Inscription : 2005-04-13
Site Web

Re : [dlManager] Support du plugin

nanart a écrit :

Par ailleurs, il faudrait améliorer:
* compléter la traduction, en virant aussi le fichier _public_l10n.php en racine inutilisé
* améliorer la possibilité de configuration du widget, par ex, en proposant une liste de propositions plutôt qu'un textarea 'Affichage d'un élément '
- par ailleurs sans indication du 'comment faire' !

Pour la traduction, une fois que le reste aura été fait, je pourrais éventuellement m'en charger.
Pour la config du widget, l'aide est dans la page du plugin. D'après ce que j'en sais, il n'est pas possible d'avoir une aide spécifique de chaque plugin dans la page des widgets de présentation. Si l'aide déjà présente ne convient pas, toute proposition est bienvenue ;)

Hors ligne

#16 2018-11-03 16:58:57

nanart
Membre
Lieu : Roubaix
Inscription : 2007-08-19

Re : [dlManager] Support du plugin

Tant qu'à faire, correction proposée _public function download: on met (presque tout avant try)

		# create objet information with file'id
			$file = $core->media->getFile($args);

		# is not an object !
			if (empty($file) || !is_object($file))
			{
				self::p404();
				return;
			}
		# file in jail ?
			if (!dlManager::inJail($file->relname))
			{
				self::p404();
				return;
			}
		# file is private
			if ($file->media_priv)
			{
				self::p404();
				return;
			}

on pourrait tout mettre dans le test if (object?) ou empty ou injail ou private -> 404
mais je préfère séparer, ce qui permettra d'afficher des messages d'erreur personnalisés par la suite


note: solution temporaire qui :
- ne corrige pas les autres méthodes
- ne corrige pas (encore) le widget
- ne renseigne pas l'utilisateur sur la raison de ce renvoi vers une page 404

à suivre

[edit]
l'erreur non object signalée dans le 1er post de ce billet du forum, pointait vers le catch où :

catch (Exception $e)
    {
      $_ctx->form_error = $e->getMessage();
   }

or, dans la fonction download, l'objet $_ctx (qui est global) n'est pas défini.
Conclusion, une erreur a été interceptée dans catch, mais.... ne peut être appliqué à l'objet  (inexistant) $_ctx.

Il y aurait peut-être d'autres méthodes d'interception des erreurs à tenter qu'une série de if->404 ?

Dernière modification par nanart (2018-11-03 17:54:37)


Dernière version stable Dotclear sur wampserver et chez ovh
Versions testing & unstable en local
https
php: 7.4  - 8 +

Hors ligne

#17 2018-11-06 01:12:42

nanart
Membre
Lieu : Roubaix
Inscription : 2007-08-19

Re : [dlManager] Support du plugin

Bonjour,
toujours pas résolu la capture d'erreurs dans la fonction download.
J'ai pu capturer, mais pas afficher dans la page.
Ça va viendre.

En attendant deux fonctions qui peuvent être ajoutées à la librairie dlManager (ou ailleurs) pour
1) acquérir le pattern des media/public files exclus:
   génère un string de type '/\.(phps?|pht(ml)?|phl|.?html?|xml|js|htaccess)[0-9]*$/i'
2) constituer la liste des extensions exclues, filemanager->$exclude_list étant protected
  génère un array de type:
[0] => Array
        (   [extension] => phps
            [type_mime] => application/octet-stream
        )
[1] => Array
        (   [extension] => pht
            [type_mime] => application/octet-stream
        )
    [2] => Array
        (   [extension] => ml
            [type_mime] => application/octet-stream
        )
    [3] => Array
        (   [extension] => phl
            [type_mime] => application/octet-stream
        )
    [4] => Array
        (   [extension] => html
            [type_mime] => text/html
        )
    [5] => Array
        (   [extension] => xml
            [type_mime] => application/xml
        )
    [6] => Array
        (   [extension] => js
            [type_mime] => application/javascript
        )
    [7] => Array
        (   [extension] => htaccess
            [type_mime] => application/octet-stream
        )

à améliorer, amha.

	/**
	 * Returns media_exclusion
	 * @return	<b>string</b> pattern_exclude
	*/
	public static function getExcludePattern() {
		global $core;
		$pattern_exclude = $core->blog->settings->system->media_exclusion;
		return $pattern_exclude;
	}
	/**
	 * Returns exclude list files
	 * note: filemanager->$exclude_list is protected
	 * @return	<b>array</b> exclude_list : array('extension', 'type_mime')
	*/
	public static function getExcludeList() {
		# get pattern exclude
			$exclude_pattern = self::getExcludePattern();
		# clean pattern exclude
			$exclude_pattern = trim($exclude_pattern, "//\., [0-9], *$, /i");
		# split exclude in array
			$excluded = $returnValue = preg_split('#[\\(\\.(\\?|\\*\\[\\])$)]+#', $exclude_pattern, -1);
		# set exclude_list
			$exclude_list = array();
			foreach ($excluded as $reg => $extension) {
				if(!empty(trim($extension))) {
					$exclude_list[] = array( 'extension' => $extension,
										'type_mime' => files::getMimeType("toto.$extension"));
				}
		     }

		return $exclude_list;
	}

[EDIT]
on peut aussi remplacer $exclude_list[] =.... (boucle foreach(..))

$exclude_list[$extension] = files::getMimeType("toto.$extension");

qui donnera un array plus "propre"
    [phps] => application/octet-stream
    [pht] => application/octet-stream
    [ml] => application/octet-stream
    [phl] => application/octet-stream
    [html] => text/html
    [xml] => application/xml
    [js] => application/javascript
    [htaccess] => application/octet-stream

Dernière modification par nanart (2018-11-06 01:37:58)


Dernière version stable Dotclear sur wampserver et chez ovh
Versions testing & unstable en local
https
php: 7.4  - 8 +

Hors ligne

#18 2018-11-06 13:45:05

nanart
Membre
Lieu : Roubaix
Inscription : 2007-08-19

Re : [dlManager] Support du plugin

note à propos de l'extraction des extensions depuis le pattern
La regex donne une fausse réponse: cas 'pht(ml)'.
En effet, par ex, les extension pht et phtml peuvent exister.
Je vais revoir ça....


Dernière version stable Dotclear sur wampserver et chez ovh
Versions testing & unstable en local
https
php: 7.4  - 8 +

Hors ligne

#19 2018-11-06 16:12:02

pierrevg
Membre
Inscription : 2005-04-13
Site Web

Re : [dlManager] Support du plugin

En attendant que le plugin soit corrigé, je l'ai désactivé. Les liens vers mes ressources sont donc HS mais vous pouvez toujours les récupérer en suivant le lien en profil.

Hors ligne

#20 2018-11-06 16:18:12

nanart
Membre
Lieu : Roubaix
Inscription : 2007-08-19

Re : [dlManager] Support du plugin

Bon, correction, et plus simple

	/**
	 * Returns exclude list files
	 * note: filemanager->$exclude_list is protected
	 * @return	<b>array</b> exclude_list : array('extension', 'type_mime')
	*/
	public static function getExcludeList() {
		global $core;

		# get pattern exclude // /\.(phps?|pht(ml)?|phl|.?html?|xml|js|htaccess)[0-9]*$/i
			$exclude_pattern = $core->blog->settings->system->media_exclusion;
		# cut pattern
			#pattern begin
				$begin = stripos($exclude_pattern, '(') +1;
			#pattern end
				$end = strripos($exclude_pattern, ')');
			#len pattern
				$len = strlen($exclude_pattern);
			#len util
				$len_util = ($len - $begin) - ($len - $end);
			#util pattern
				$util_pattern = substr($exclude_pattern, $begin, $len_util);
			# split exclude in array
				$excluded = explode('|', $util_pattern);
		# set exclude_list
			$exclude_list = array();
			foreach ($excluded as $key => $extension) {
				#clean
					$extension = str_replace('.', '', $extension);
					$extension = str_replace('?', '', $extension);
					$extension = trim($extension);
				#search complement: ()
					$count_ext = 1;
					$plus = stripos($extension, '(', 1);
					if($plus) {
						# create ext complement
							$extension = trim($extension, ')');
							$ext = explode('(',$extension);
							$count_ext = count($ext);
						#create files list
							for ($i = 1; $i < $count_ext; $i++) {
									$old = $ext[$i-1];
									$exclude_list[$old] = files::getMimeType("toto.$old");
									$new = $old .$ext[$i];
									$exclude_list[$new] = files::getMimeType("toto.$new");
								}
					} else {
						$exclude_list[$extension] = files::getMimeType("toto.$extension");
					}
		}
		return $exclude_list;
	}

On pourrait réduire les lignes de code et supprimer les commentaires, mais j'aime bien quand c'est clair, même si on perd quelques millisecondes de calcul. Il y aurait peut-être une solution avec regex, mais chais pô faire.
[mode serious]
Bon, fini la récré, je continue l'analyse du code de ce plus plug!.
[/mode serious]

Dernière modification par nanart (2018-11-07 15:48:26)


Dernière version stable Dotclear sur wampserver et chez ovh
Versions testing & unstable en local
https
php: 7.4  - 8 +

Hors ligne

#21 2018-11-20 17:56:41

nanart
Membre
Lieu : Roubaix
Inscription : 2007-08-19

Re : [dlManager] Support du plugin

Petit résumé d'où j'en suis.

Mis à part quelques autres erreurs (et problèmes) trouvés dans le script, l'erreur posée au début (erreur si fichier n'existe plus) (+ fichier est en mode private) quand on tente de télécharger un fichier, dépend, je crois, du mode de fonctionnement du plug, à savoir :

- la liste des répertoires est basée sur un examen d'existence de dossiers (vides ou non, autorisés par le gestionnaire des medias ou non) dans le répertoire des medias 'public'

- alors que la liste des fichiers existant dans ce répertoire ('public') - ou un des subdirs choisi (root), est basée sur une fonction de Dotclear qui liste les fichiers enregistrés dans la table media; (la liste des fichiers repose sur l'id du fichier dans la table media)

En conséquence:
=> la liste des fichiers existant dans des dirs non répertoriés dans la table des medias sera forcément vide
=> un fichier non répertorié dans cette table n'apparaitra pas
=> tout fichier existant dans la table mais supprimé par ftp, génèrera forcément une erreur si une mise à jour de la table media n'a pas été effectuée

note: Il existe bien une fonction permettant de mettre à jour la table media, mais elle réservée au superadmin.

Conclusion (personnelle):
Il faut choisir entre :

- soit on liste tous les fichiers existant dans le répertoire choisi (root)/public
     => on ne s'occupe pas de la table media
     => on utilise des fonctions permettant de voir/télécharger ces fichiers s'ils existent

- soit on n'utilise que les fonctions Dotclear pour générer la liste des répertoires et des fichiers
    => en en vérifiant l'existence auparavant (en cas de suppression via ftp)
    => en vérifiant aussi que le mode 'private' n'ait pas été appliqué entretemps
    => et, en conséquence, on ne s'intéresse donc pas aux fichiers ajoutés via ftp si la table des medias n'a pas été mis à jour

La première solution me semble être un peu trop "ouverte" - tout comme l'est la possibilité de choisir un autre répertoire à partir de la configuration du widget si on ne contrôle pas les accès; par exemple tel dir ou fichier n'est pas autorisé, etc...

La seconde solution me parait plus "sûre" puisque contrôlée par des fonctions Dotclear.

En fait, pour savoir comment procéder, j'aurais besoin de savoir comment est utilisé ce plug:
- pour télécharger tout ce que contient le dir 'public' sans aucune restriction (autre que les exclude qui n'excluent que des type de fichiers)
- pour télécharger quelques fichiers mis à disposition publique (donc avec restrictions à construire)



-

Dernière modification par nanart (2018-11-20 18:03:44)


Dernière version stable Dotclear sur wampserver et chez ovh
Versions testing & unstable en local
https
php: 7.4  - 8 +

Hors ligne

Vous n'êtes pas identifié(e).

Pied de page des forums

Sites map