Inline Images

Dom W.

@language-problem: I had the same problem with the Deutsch (German) language file. At least I figured out, that the crucial difference is the "newline": the file English/definitions.php has Unix-like CR, the Deutsch/definitions.php has DOS-like CRLF at the end of each line. If you remove the LF (e.g. with recode), Inline Images works fine. But I have no idea, why this happens.

RusCom

This Extension DOESN'T WORK WITH UTF encoding.
You can see screenshot:

My database encoding is UTF8, language file is too.. When i re-save language file in ANSI (cp 1251), all work.
I am add the line $Configuration['DATABASE_CHARACTER_ENCODING'] = 'utf8'; in settings.php file, but it not help me.

SCHIZO

Great add-on. But you don't respect translators and use poor coding. Every time i want to correct YOURS CODE!!! Because translation for my language dont't works if in default.php used $Context->Dictionary.

PLEASE! Use $Context->SetDefenition instead $Context->Dictionary and be hero.

Wanderer

Mate give it a rest with the "...you don't respect translators..." crap, it's getting a bit tedious and tiresome.   (*yawn*)

ericcarl

I'm having some trouble getting the inline images to display. When I only have have the Attachments add-on installed, the images are linked from the post as normal. But when I activate the Inline Images add-on, I get a broken image. When I try and view the URL of the image, I am given this error: --------------------------------- A fatal, non-recoverable error has occurred Technical information (for support personel): Error Message The "AttachmentManager" class referenced by "AttachmentManager" does not appear to exist. Affected Elements ObjectFactory.NewObject(); For additional support documentation, visit the Lussumo Documentation website at: lussumo.com/docs --------------------------------- Any idea why this would be happening? Thanks!

ericcarl

WELL there you go, of course I figure it out right after posting for help. I had the Attachments add-on folder named "attachments" and not "Attachments", so the Inline Images code that references "Attachments" would break. Fixed it by naming the add-on folder correctly.

bwaje

Very strange…I have been using this extension for months, and suddenly (maybe going from php4 to php5) the same problem asRuscom; so what happened ?
What is the solution ?
I tried re-encoding in Windows Latin, but is even worst because UTF8 characters are not recognized; anyone got an idea ?

Stash

I've updated Inline Images to a proposed 1.4. Here's a changelog, if it's liked hopefully it can be updated.
Version 1.4 - 2007-09-04, [-Stash-] - Added support for text-only (worksafe) mode as described by itchy http://lussumo.com/community/?CommentID=74185 - Added LightBox support using the LightBox extension from AlexL http://lussumo.com/addons/index.php?PostBackAction=AddOn&AddOnID=309 - Added support for other image opening options and defaulted to thumbnail of 125px and opening in the current window. - Now using SetList for the extension options page. - Added readme.

gertb

What's the maximum jpg picture size that's supported by Inline Images (1.3) ? There seems to be a limit. I tried to upload a 10 megapixel photo (3648 x 2736 pixels) and the result was that there was no thumbnail generated. The filesize was not the problem, I brought that down with compression to 200kB. After I resized the original image to half the size (1824 x 1368) all went well even though the filesize at that point was 600kB.

Stash

I would image this has something to do with either the ZenPhoto code used by this extension or a PHP memory limit on your webserver... Might be worth trying the latest release of ZenPhoto and seeing if you can do it with that.

gertb

Could it have something to do with code that calls the resizing for the thumbnail ? The upload is always ok, it's the creation of the thumbnail that sometimes fails (no thumbnail file in the uploads folder). The image link is always present beneath the comment but the thumbnail is not there. Could you maybe give me a hint were to look for that code so I can take a look myself ?

Stash

I don't know exactly, but I'm betting it's in the image PHP files in the extension...

Spliffster

@gertb: for creating thumbnails, the image will have to be decompressed in memmroy (gd most probably) then resized and recompressed. This means something like xpixel*ypixel*(3*24bit)/8 = bytes ... most probably you are hitting the mem limit of php (i had this problem once too, even ini_set("reporting_level", E_ALL); did not display an error message, php quietly dieing, gnnn). instead of using a filesize limit it would be a better idea to set a x/y limit, then use getimagesize() first to detirmine the actual image size before processing. I am not sure if getimagesize() can extract these infos from the image's header (probably depending on the image format) but if not you are probably pwnd.

Spliffster

I have a problem with this extension (stash's update). Whenever i use it the image will be sent without a Content-Type header. Therefore the image cannot be displayed inline. I have added a print_r(); die(); before the output starts to verify that the content type is detected/sent ... and the result array/object has an empty content-type in it (response headers show the same). is this a known issue ? (using php 5.1.x ... where mime_content_type() is available and working.) Cheers, -S

Spliffster

After not hearing about any known problems i have investigated further. Some includes in image*php have probably whitespaces before <?php or after ?>, threfore resulting in a corrupt image file. The solution to this problem is as follwos (hack): ob_start(); // <-- adding output buffer include('../../appg/settings.php'); include('../../appg/init_ajax.php'); // Load the core attachment extension include($Context->Configuration['EXTENSIONS_PATH'].'Attachments/default.php'); ob_end_clean(); // <-- adding output buffer the above hack will also prevent you from seeing any potential errors between ob_start and ob_end_clena .. .so be carefull. Then the content type cannot be detected propperly. here another hack (hell, call me McGuyver ... i did it all with duct tape and a swiss army knife!): Somewhere before streaming the file's content, do the following: header("Content-Type: ".mime_content_type($ImagePath)); Cheers, -S

wigrocks

Hi all, New user. I've been reading through this and I'm not seeing the issue I'm having. I installed the latest attachments add-on. Everything was fine, click on the link to the file and it opened. I installed the inline image add-on, and it now shows a rectangle with the red X where the image should be. It seems like it's unaware of where the attachments reside? Is there somewhere aside from where I designated the path to store the attachments in the attachments add-on, that tells the inline image add-on where to find them?

wigrocks

It took some hunting around in the community threads, but I "think" changing the definitions.php file from ANSI to UTF-8 resolved my issue, and/or installing the 1.4 version of the InlineImages add-on. I was only able to find this in the community area, not the add-ons directory. Would be great if it was added/updated over to the add-ons list. Thanks to Stash for supplying it. Cheers, Wig

judgej

I've noticed that this Plugin does not apply any category-based security to the images. The URL for an inline image is accessible to users who do not have permission to view the category the discussion is in.

The Attachments download script manages to handle the security well, so perhaps there is some code that can be cribbed from that.

-- Jason

kelvin

possible e.g flash?? attachement upload with flash (not like link)??

andi_levinge

I am trying to float my image to the left of the discussion, but my comment body text always appears AFTER the image. Somehow it always inserts the image after the text. Is there any way of putting the image before the text?