[drupal-devel] [feature] add inline functionaliy to uploads
salmons at sohodojo.com
Sat Jul 23 21:32:53 UTC 2005
Bèr Kessels wrote:
> Issue status update for http://drupal.org/node/26288
> Post a follow up: http://drupal.org/project/comments/add/26288
> Project: Drupal
> Version: cvs
> Component: upload.module
> Category: feature requests
> Priority: normal
> Assigned to: Anonymous
> Reported by: Bèr Kessels
> Updated by: Bèr Kessels
> Status: patch
> Sohodjo jim:
> " I hope it matters. A big -1 on enforcing over-simplification at the
> expense of important and existing functionality. If automatic,
> uncontrollable placement of images becomes the standard, it will mean
> fewer not more image-rich Drupal sites as site owners/developers get
> complaints about "Why can't I control my images!"
> I _strongly_ encourage Ber to provide a "have it both ways"
> solution. Why not have an admin configuration setting for "allow inline
> tags" with default off. Change it to on and you get an additional
> checkbox for 'inline at tag' to accommodate the current functionality
> the inline module while simultaneously allowing for default placement.
> NOOO. people; please; look at the PATCH.
> Again: and hopefully last time: Simplicity.
> This patch does NOT replace ANYTHING inline module or img_assist wants
> to do.
> This patch hands better data to such modules. It hands a variable over
> to these modules, $node->file[FID]->inline, which tells these sorts of
> modules if people wnat that file to appear inline.
> AND it CAN (by default will) render a file in the most simple way
Thanks for clarifying.
In prior comments, it sounded like this patch would hit core and
provide default functionality that superseded or perhaps would conflict
with such contributed modules as inline. As described above, it sounds
like this will make life easier for such enhanced feature modules.
> So really, if you want to -1 this patch, fine. But do not -1 it,
> because it does too little IYO. It still allows MUCH more than what you
> can do no, without that patch! And any solution, for core, that allows
> advanced handling of inline images will either require an enourmous
> amount of work, or it will simply no get in.
> So, unless you come up with a good core-worthy patch, this is still a
> big leap forward from what we have now.
If this patch and additional modules like inline can play happily
together, I have no problem and go 1+.
I have one current project and seven xmlrpc-related crisis upgrades
(some client sites going back to 4.2!) that have consumed all available
time at present. So I have not had the opportunity to speak from direct
I just know that I want inline graphic placement that works with the
attachment feature and did not want to lose this.
Thanks for the clarification,
Jim Salmons and Timlynn Babitsky
Founders and Research Directors
Sohodojo - http://sohodojo.com
More information about the drupal-devel