[ewiki] Re: ewiki_binary() patch, ewiki_control_links()refactor

On Thu, 2004-03-11 at 16:06, Mario Salzer wrote:
> > My team member, Jeff added error logging for binary file errors.  Also, I
> > would like to add a meta data field to cached images.  The perm_liveuser
> > functions use this to set cached images to have different rights than
> > uploaded ones.
> 
> Yo, but there are rarely errors on fclose(), after fopen() it would
> make far more sense. And then you simply could reduce it to one total
> error_log call ("readin/writing failed for...").
> 
> (Btw, wouldn't copy() do it here?)

So track the status and then make one log call?  I suppose we could.  
Copy() does indeed look like the way to go, I'll try to get that set
done.

> > also, can we add a set of binary_handlers?   These would run in
> > binary_save_image() as follows:
> 
> The _binary_save_image() could need such a general plugin hook, of
> course (and a new name also). But what plugins do you have in mind,
> and is the hook applicable to other uses?

It probably won't surprise you that I need it for my security stuff. 
Specifically I needed a way to set default rights.  Other uses might
include changes to the meta data.

> >         if ($pf_a = @$ewiki_plugins['binary_handler']) {
> >   //xxx     ksort($pf_a);
> >             foreach ($pf_a as $pf) {
> >                 $pf($id, $data, 'save');
> 
> Also the hook should get a different name (_store or _save or so).
> The existing ["binary_store"] appears to cannot be moved down any
> further. But if your plugins would work with $data being filled
> except for the {content} field, there was a way to reduce it to
> one plugin hook here.

Binary_store would have been possible for me except that I needed to
know the $id that the file would be stored under the existance check was
just an added plus once I knew I'd have to add the hook.  I do not need
the $data and in fact do not necessarily get it in this call.(because a
binary_store plugin might have intercepted it)

Andy

Other related posts: