Image not inserted when using image 5.x-1.5

The same issue. Please, fix it, please!

Its not just the filter input that is broken its the HTML insert mode too

I think most of the problems are to do with the _image_get_sizes() function in 1.3 changing..
Its going to require quite a bit of a rewrite i think.

Ok, I made up a patch to fix this.
Changed quite a bit. Someone who knows the module better than I do should check it over.

Note that the patched code will only work with image 1.3

Had an error in the patch. Heres a new version.

Could you please provide your (fixed) version of the .module file?
I cannot apply the patch to the latest version of the .module:

> patch < img_assist_v2.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: img_assist.module
|===================================================================
|RCS file: /cvs/drupal-contrib/contributions/modules/img_assist/Attic/img_assist.module,v
|retrieving revision 1.68.2.14
|diff -u -r1.68.2.14 img_assist.module
|--- img_assist.module	17 Jun 2007 22:07:47 -0000	1.68.2.14
|+++ img_assist.module	6 Jul 2007 04:05:13 -0000
--------------------------
Patching file img_assist.module using Plan A...
Hunk #1 failed at 255.
Hunk #2 failed at 673.
Hunk #3 failed at 730.
Hunk #4 failed at 764.
Hunk #5 failed at 799.
Hunk #6 failed at 1044.
Hunk #7 failed at 1077.
Hunk #8 failed at 1096.
Hunk #9 failed at 1142.
Hunk #10 failed at 1172.
Hunk #11 failed at 1200.
Hunk #12 failed at 1260.
Hunk #13 failed at 1320.
Hunk #14 failed at 1335.
Hunk #15 failed at 1347.
Hunk #16 failed at 1623.
Hunk #17 failed at 1632.
Hunk #18 failed at 1681.
Hunk #19 failed at 1697.
19 out of 19 hunks failed--saving rejects to img_assist.module.rej
done

It may have been the windows line endings that were causing the problem, try this one

Heres the patched file

It works, thank you!

I can confirm that the attached img_assist.module (#9) works with image-5.x-1.3. I don't have a good knowledge of the inner workings of img_assist, so I can't comment on the correctness of the patch, but it works for me.

Thanks!

/me too ! Thanks you very much for the patch, you saved my day.

The patched module as offered under #9 above also seems to work with image.module version 5.x-1.4 when it comes to getting the images being displayed again (after some browser cache clearing). It looks good, however, I have not yet performed thorough testing of all the functionalities.

jaredwiltshire, as the person who committed the image.module changes that broke img_assist, your patch looks good. i don't use img_assist so i can't test it properly. i'll try to do a better job of announcing changes to the image.module api on the image group.

Hope the patch at #9 makes it into a release soon, just had a feeling of horror seeing my site break by upgrading some modules - image being one.

Adding myself, so I can track this.

It doesn't work for me. I have a clean install with the newest image and image assist. I only got the tag, with no pic. I've checked the filter and it's checked. I've worked with the older version on my other site. I installed the new version for my new site but it doesn't work. I tried the patches here but nothing.

More information about my last post. After tampering with it some more, I finally got the image to show when I'm logged in by using html codes and using full html setting. But it will not show the pic when i'm logged off the site. The frame for the picture is there, but the picture is missing

nm, i just forgot about access. html does work.

Guess what, it doesn't work. I have no clue anymore. It worked for that one image, and then it doesn't work anymore. I'm completely lost.

@krystalepic

make sure to empty the cache_filter table.

and upgrade to the 1.4 release of the image module. it's much more stable.

Does the patch work with earlier versions of Image? If not, would that be possible to do? If not we have to be very clear about what versions work with what version of Image.

Granted, most users will probably update both Image and img_assist at the same time, but for the rare cases where someone is using an old version of Image I think it would be good to keep backward compatibility.

I agree that backwards compatibility would be nice, but I think working with current versions of the image module is more important than working with old ones.

See post #4
It only works with image 1.3 upwards.

Backwards compatibility might be possible but It would require a bit of trickery. I dont think we should bother.

We just need to make it clear that image 1.3 or higher is required.

there was a comment in the image queue indicating that this might not work with the new image -dev release. i've asked the user for a bit more detail but it made it clear to me that i need to proactivly work with other image* module developers to coordinate our releases. i'm going to post a message to the image group to start that conversation.

The problem is that inside the same major version a module shouldn't break it's API for other modules.
Let's hope this was an accident and we don't get those problems again.

ray007, img_assist was calling _image_get_sizes(). The leading underscore is a convention to indicate the functions is a private method and not part of the public API. Since other modules were treating it as a public API I've committed #159767 which renames _image_get_sizes() to image_get_sizes() but adds a wrapper to preserve backwards compatibility.

I think the best place to continue this discussion would be on my post in the image group. I'd love some help in reworking the public API that other modules interact with. And, yes, the DRUPAL-5-2 branch will be the place this is done.

The replacement module file in post #9 worked for me as well. THANKS!

I looked through the patch and in general it looks very good. I didn't realize it was such a large patch though, and I agree that keeping backward compatibility wouldn't be worth the trouble.

I do have two other things to consider though:

– The naming of 'label' and 'name' is a bit confusing to me. I can see that you're being consistent about it and I agree that 'label' should be the human-readable name like in image.module. But 'name' doesn't really sound like a machine-readable name to me. Maybe 'key' would be better, or 'label_key'?

– Can you explain why we no longer need the second argument in _img_assist_build_derivatives()? (Or why we didn't need it in the first place...)

I'll be happy to commit this after I get some kind of response on these two issues!

The replacement file for image.moduel listed in post 9 worked for me as well, THANKS. For the image module I'm using the latest 5.x.1.x-dev: $Id: image.module,v 1.209.2.39 2007/07/16 16:23:39.

Shai

As reported in #32 I've had success with the patched file in #9.

But like krystalepic as reported in #18, I have another Drupal site where it wasn't working. Exact same files installed, running off the same server.

Resetting Img_Assist to the default settings at /admin/settings/img_assist did the trick. Yippee!

If I figure out which setting is the culprit I'll report back. Pheww, what a relief.

Shai

That seemed to work for me too, thanks! Somehow the title of the image was printed out as well though-- did I do something wrong?

@zoo33
1. Yeah, go ahead and change 'name' to whatever you prefer. There was no particular reason I choose 'name'
2. The other argument was never needed. I checked to make sure the argument wasn't used anywhere in the module. The function is an internal function so it shouldn't be called from outside the module. The function was derived from the _image_build_derivatives() function in image.module so I'd say the argument was carried over even though it wasnt needed.

With regard to having to set the settings to default, its probably the "Default size for inline images" and "Popup size" settings that are having problems.

We probably should make a update function that updates those settings for example from '_original' to 'Original' etc

@jaredwiltshire: Wouldn't it be better if we could keep the size settings stored as the machine-readable labels: '_original' etc.? 'Original' will be translated into other languages and that will probably break things if the admin decides to change into a different language. Right?

I don't have time right now to look into where those settings are read, but that shouldn't be too hard to find out. Did you touch upon that in any way in your patch?

I installed the module included in this thread and now my image is being inserted into the tinymce textarea. The problem I have is that the image isn't aligned properly in the tinymce textarea.

The image is surrounded by this class:

and yet it is being aligned to the left. Is this an issue with the module included in this thread or is it a general issue? I've tried using both 'tinymce default' and 'use theme css' style options but neither work.

I'm running 5.1 release + the latest image module 5.x-1.4 + the patch in #9.

The patch fixes the problem of the missing image which I found I had with v1.4 but I've noticed two, possibly related problems:

1. My image module is set up to create 3 versions of each image: original (normally 640x480), midnail (320x240) and thumbnail. Image assist doesn't recognize that midnail exists as a size when using it to insert images. It does recognize it in the administration screen.

2. If I choose to insert an 'other' image size, and choose a size - say 499x277, Image assist ignores the change and inserts the wrong sized image. It uses the original size

3. And probably non-related. It shows the text '%count image sizes are not being shown because they exceed the the maximum inline image size setting.' in the settings for image asssist. My maximum is set way bigger than 640x480.

This is just working on a plain html input text area. No TinyMCE.

Does anyone else see this behaviour?

Jeff

@zoo33
Yeah that should be how it works. I'll have another look at the patch.

This patch seems to have solved our major issue.

I can't vouch for any of the other issues that were mentioned here though.

From what I understand, what changed was that image module no longer creates derivatives, if the original is smaller than the required size for any of the derivatives.

So basically, if you have a 320x320 preview derivative, and you upload a 200x200 image, Image no longer creates myimage.preview.jpg (as it would just be a copy of the original, and would be wasteful).

This meanns that the dropdown list used to select which derivative to use, got out of whack. What this patch does, is to only generate list items for derivatives which actually exist.

There seems to be a special case for "Preview" though (in our case, it might just be due to a default setting in image for instance), that lets it use whichever is closest to the preview derivative (ie: the original images in smaller images, and the actual generated preview derivative), but surround that image with a div.

Otherwise, everything works as it should, and the above is probably by design.

The http://drupal.org/files/issues/img_assist_v2_0.patch file in #8 worked for me (against 5.x-1.4). Thanks!

Thanks, the module attached in #9 solved it for me too :)

Found the problem described in #39 and it's unrelated. Patch works as advertised for me now.

However it does have a bug in that it looks like it's generating class names with spaces in them. I don't think CSS identifiers are allowed spaces. It's happening in the class for the image e.g. 'class="image thumbnail"'

smoothstr, they're actually two different classes: 'image' and 'thumbnail'.

I have the same problem as metioned in #39 after patching... My added formats can't be found!

Doh! Yes, Drewish, I just figured it out and came to say that it's not a bug. You got here before me.

But there is a bug with inserting goto URLs. Patched version inserts "/" as the URL when you choose to make a link of the image, and choose Goto URL. There's a good chance that this is a bug unrelated to the patch.

Snobojohan, the problem in #39 was down to me misunderstanding what the setting for maximum size of uploads in the image_assist settings should be. It's meant to be filled in as something like "640x480". Exactly like that. Without the quotes. It's not meant to be a number of bytes. Changing this meant that my other formats were found.

i also have same problem as in #19, i have img_assist 1.4, and i applied the patch, i also tried emptying the cash_filter table, but nothing helps, does anyone have some other idea.

Thanks smoothstr , I already had set that correctly but my problem were somewhat related.

The problems for me were caused when an image derivative had been created (admin/settings/image) with just the width parameter. I have a derivative called block that was set to 180px width but with no height restriction. Setting a height restriction solves this and now the patch #6 works for me. This still is a bug though, if I have time I'll try and look at the code!

Is it possible that this patch does not work together with the patch http://drupal.org/node/124346? I have combined both patches (here #8). But the size drop down does not include anymore the "Wiki options".

I installed a new site using 5.2 and the 1.4 versions of image and image assist. I've been going through and working on setting up the site and all was working fine.

Then I went to create a new page and when I attempted to use image assist it simply didn't work. The photo gets uploaded correctly, but when I try to insert the code all i get is this:
<span class="inline left"></span>

I can't imagine why it would stop working when I made no changes to the site other then adding content.

Just one clarification. It seems to work if I click 'open in popup window', but not for either of the other 3 methods.

Thanks,
David
http://www.FloridaPets.org

Well nevermind, the new mod in #9 seems to have worked for me too.

Regarding #51:
I was wrong. I've tried it with a user who had not enough rights. I've edited the user access rights and now all my users can change the "Insert mode". You just have to make sure that users are allowed to access the advanced options of the img_assist module.

Are there any released/tagged versions of the image and img_assist modules that work together without exhibiting this problem?

This issue is kind of getting out of hand with reports of new problems constantly appearing. I decided to commit this so that we can start testing and filing new issues against the -dev version instead.

I made a few changes to the patch and tested it quickly. I couldn't find any problems on my testing server running Image 5.x-1.4. And I couldn't find any settings being incorrectly saved.

Please try the -dev version as of today/tomorrow (when the packaging script has made a new version of the tarball).

Marking as 'fixed'. If there are problems or errors with this patch itself, feel free to reopen the issue.

Thanks jaredwiltshire for your efforts with this patch!

i tried:

img_assist 5.x-1.x-dev dated Aug 16
image 5.x-1.x-dev dated Aug 9

and images do not show.

I also tried the various combinations of the dev image/img_assist with latest release of img_assist/image and these also do not work.

As with earlier comments the page shows something like:

 [img_assist|nid=122|title=|desc=|link=none|align=undefined|width=120|height=80]

and the html looks like:

  <span class="inline undefined"></span>

Peter Lindstrom
LiquidCMS - Content Management Solution Experts

np zoo33

Hi,

just a note from someone who tried to get this working for some hours. After a several experiments I could get it working for my installations. I am currently running Image 1.4 and the Image Assist development version 1.68.2.16 (dfrom 2007-08-15).

The reason for the error was simplly a conflict with the input format filters. For unknown reason the HTML filter had the same weight than Image Assist filter. And so the HTML filter just removed the correctly generated images.

BTW: Thanks for the work!

well that didnt quite work for me.. but possibly on the right track.

I have a page with 3 images on it - none of which showed up once converting my site over from Dr 4.7 to 5.2. The page content input format was rich text which didn't have html filtering on it - but based on above post i thought i would change input format to full html. Now i have 1 of the 3 images working - very odd.

a couple things seemed to be busted with this:

- full html filter works; but rich text doesn't

although both are defined the same??? each has line break converter and inline images and both with same weightings

also, i think that the image module doesn't work properly when updating from dr 4.7 to 5 - went through their issue list but didnt see this listed; but image nodes don't show up as having an image with them; when i re upload the image the node is fine (and then flip input format to full html and images now show in other nodes where they have been added with img_assist)

While using image module 1.4 and the version of img_assist that that had the fix committed, I'm seeing a new problem;
"had missing derivative image which has been regenerated" is appearing on every page, and no images are visible.
http://drupal.org/node/162901

Sorry, I can't reproduce any of these problems.

Is this related?

http://drupal.org/node/162383

just following up.

Image 5.x-1.4 plus Img_assist 5.x-1.x-dev (dated 2007/08/22) solved my problem.

Thanks everyone for all the work on this update!

Jen

following up again...
the dev snapshot I thought fixed my problem, only works part of the time. See #60 above, and I'm in the same boat. Help much appreciated!
Jen

I still need help on this one, is anyone else making any progress?
Jen

Make sure that you're using both the newest img_assist 5.x-1.x-dev and the newest image 5.x-1.x-dev. I'm running image 5.x-1.x-dev and img_assist 5.x-1.x-dev from 2007-08-27, and everything is working just fine.

Image 5.x-1.4 isn't even the newest release anymore!

Image 5.x-1.x-dev (2007-Aug-28) plus Img_assist 5.x-1.x-dev (2007-Aug-28) do not change the behavior of my site. I still get pages with 1 of 2 images displaying, and pages with no images at all. It doesn't matter now weather I use filtered HMTL or full HTML input type, nothing changes. This is the code img_assist inserts:

<p>
[img_assist|nid=1602|title=Figure 1 Emotion curves|desc=|link=none|align=left|width=640|height=402]</p>
<p>
<p>
[img_assist|nid=1208|title=Emotion Curve - China Mobile vs China Telecom|desc=|link=none|align=left|width=640|height=399]
</p

and this is the code that is output:

<p><span class="inline left"><img src="http://sandbox.customerthink.com/files2/images/033007_sampson_lee_figure1_emotion_curves.jpg" alt="Figure 1 Emotion curves" title="Figure 1 Emotion curves"  class="image preview" width="454" height="285" /><span class="caption" style="width: 452px;"><strong>Figure 1 Emotion curves</strong></span></span></p>

<p><span class="inline left"><span class="caption" style="width: -2px;"><strong>Emotion Curve - China Mobile vs China Telecom</strong></span></span></p>

I have updated to image-5.x-1.x-dev.tar.gz and img_assist-5.x-1.x-dev.tar.gz as of today and I'm still seeing the missing derivative image issue I described in comment #62
:-(

I've been doing lots of testing with Image 5.x-1.x-dev (2007-Aug-28) plus Img_assist 5.x-1.x-dev (2007-Aug-28). Because the new version of img_assist is NOT backwards compatible with previous versions of the filters, and doesn't always display images from pre-existing filters as it should, i started going back through my site's content and re-inserting images via img_assist. I've found that it also seems to have issues when I try to add an image that's already been uploaded, and it spits out the error "unable to create Properties image". I checked the image folder, and the image with the extension .img_assist_properties.jpg already exists... I don't know if this is causing the error or not, but it shouldn't be creating that image if it already exists anyway. Ok so, the end result, is that the image shows up, but as a thumbnail instead of the size I specify (and it doesn't seem to matter what else I choose), so what's up with this thumbnail... here's the output HTML code:

<p><span class="inline "><img src="http://sandbox.customerthink.com/files2/images/China Mobile Vs. China Telecom.thumbnail.jpg" alt="Figure 2 Emotion Curves of China Mobile (love) and China Telecom (hate)" title="Figure 2 Emotion Curves of China Mobile (love) and China Telecom (hate)"  class="image thumbnail" width="100" height="62" /><span class="caption" style="width: 98px;"><strong>Figure 2 Emotion Curves of China Mobile (love) and China Telecom (hate)</strong></span></span>|desc=|link=none|align=left|width=480|height=299]
</p>

I think the dev version needs too much work, I'm going to try to go back to the previous official release and see if I can't get some combination of image and img_assist in some state where my site will show the images from the 4.7 version.

I found a bug in _img_assist_build_derivatives() which seems to have prevented images from being rebuilt if for example an image derivative was missing. I think this may have caused images to disappear like you describe. It only happend to me after I added a new test size and tried to add old images in that size. I'll committ this now, so the -dev version should be updated soon. Please try and see if it fixes your problems.

I'm experience the following issue while using the image and img_assist modules;
http://drupal.org/node/171524

ok, now the previous example is working. Both images are now showing where before there was only one, but it doesn't seem to be working across the whole site... Here is another example of a page where the images display in Drupal 4.7, but not in Drupal 5.2 with Image 5.x-1.x-dev (2007-Aug-28) plus Img_assist 5.x-1.x-dev (2007-Aug-28).

Here are two pieces of the filter code created by Img_assist 4.7.x-1.x-dev:

[img_assist|nid=2098|title=SEplanit Circle of Influence|desc=|link=none|align=left|width=640|height=546]

and

[img_assist|nid=2097|title=SEplanit Dashboard|desc=|link=none|align=left|width=640|height=463]

and here is the code they generate...

<span class="inline left"><span class="caption" style="width: -2px;"><strong>SEplanit Dashboard</strong></span></span>

and

<span class="inline left"><span class="caption" style="width: -2px;"><strong>SEplanit Circle of Influence</strong></span></span>

No error messages?

If you view the image nodes 2097 and 2098, do they look normal?

Have you tried resaving the node that has the inline images?

some of this might be due to bugs in the image module. i'm working on a fix over at http://drupal.org/node/160671#comment-297969 and i'd love some testing and feedback.

I just commented to that issue.

There is an old issue (which I haven't been aware of before) where images may disappear from a "parent" node, such as a story node, if the image paths for some reason have changed. This will happen if you edit you image node and upload a new image file to it.

The problem is that the old paths are kept in the filter cache as a cached copy of the parsed node – although the nodes themselves don't store the paths, only the node IDs (assuming that you use [img_assist] filter tags).

The good news is that it's easy to fix this. You need to empty the cache_filter table in your database or use the Devel module to wipe the whole cache.

In the long run we should think about how to avoid this. I'm thinking of adding a check to img_assist_nodeapi() and wipe the cache whenever an image is updated.

I fixed my problem, here's what I did:

Since all my images were working in my 4.7 version, and some were missing on my 5.2 version, I compared the files table on each, and found about 30 missing rows on the 5.2 table. After assuring that the table schema had not changed, I imported the 4.7 files table into my 5.2 database, and after about 24 hours, all my images showed up in 5.2.

Do you think something is wrong with the update script, that might have removed data from the files table during the upgrade? (I'll have to updgrade my live DB again this thursday night, I'll comment here after about the state of my files table before & after.)

The images on my site are back (thank goodness), but why did it take them so long to show up? I don't have any cacheing turned on under "performance", is there somewhere else I should look to get rid of the image cache issue?

Thanks,
Jen

P.S. to answer your questions... No, there were no error messages. Yes, the image nodes, when viewed on their own, looked normal. Yes, I tried re-saving the nodes with missing images, in both Filtered and Full HTML mode, no change.

Take a look at image_update_4() in image.install. It removes file records from the database if it can't find the file in the filesystem. I'm a little concerned about that, I think I lost some images on a testing server before, though I can't really find anything wrong with the code, except that it might be a bit risky to delete files without informing the user. You should probably look for issues about this in Image's issue queue and if you don't find one, submit one yourself. If you're worried about this, you could just comment out that code in image.install before you run update.php with your real data. (And always make sure you have backups!)

Your images may have reappeared when the filter cache was reset. This happens on every cron run, but I guess you may not have that running since you're working on testing installs. It probably gets cleared in other situations too. I'll add a new issue to Image assist about clearing the filter cache when images are changed.

Let's consider this issue "fixed" now.

I am having another occurrence of this problem with image-5.x-1.6 and img_assist-5.x-1.5. I had to upgrade from image 1.4 to image 1.6 because after upgrading from Drupal 5.2 to Drupal 5.3+5.4patch+5.5patch, the image upload (1.4) was not submitting all images properly (previews were fine). I was not able to submit an image that was 1025x769, but I was able to submit an image that was 128x128. Based on simple log examination, it looked like the script was running out of memory, but increasing the php memory limit didn't help, plus it had worked previously. Upgrading to 1.6 solved the submit problem, but then this problem of inline images not displaying showed up again.

The current configuration that seems to work for displaying inline images is image 1.4 with 1.6 database update and img_assist 5.x-1.x-dev ($Id: img_assist.module,v 1.68.2.18 2007/08/28 08:54:26 zoo33 Exp $). But, as I stated above, image 1.4 will not submit all images properly.

As the later comments hinted, I took a look at the drupal database. One thing I noticed is that the images submitted with newer image module has the filepath listed in full, i.e. /web/drupal5_private/images/SomeImage.png. These images tend to display properly when you view its nodes. But, for the images that weren't showing up inline, the filepath was relative, i.e. images/SomeOtherImage.png. Not only did these images not show up properly inline, but when I view its node, the image did not show up properly either. If I then click on edit, the thumbnail displays. Incidentally, the filepath for the thumbnail is also full, i.e. /web/drupal5_private/images/SomeOtherImage.thumbnail.png. So, I tried the obvious thing and set the filepath for the original to full. The only thing this seemed to have solved was when you view the node, the image finally displayed properly, but it did nothing for the inline problem.

FYI, the inline html snippet that doesn't work looks like this:

   <h3 align="center">[img_assist|nid=125|title=|desc=|link=url,SomeOtherImage|align=left|width=128|height=128] </h3>

This half working/half broken state is kind of annoying. I'm willing to give any more debugging info that may help get this to a fully working state. Thanks for any help.

Changed to bug report. Sorry.

So there are two things here:

1) Image nodes stored with full paths work – relative paths don't.
2) Image nodes that are working still don't show up as inline images.

1) must be considered an issue with Image module if I'm not mistaken. 2) could possibly be solved by clearing the filter cache. This is done on each cron run. If you don't have cron setup, run www.yoursite.com/cron.php and see if that solves it. If not, could you please show us the html, if any, that is being output where the image should be?

I don't know much about the latest changes to Image module. I someone else does and has some ideas about what's happening here, please chime in!

My cron runs regularly and correctly, but it did not fix the problem. The html snippet I pasted previously:

 <h3 align="center">[img_assist|nid=125|title=|desc=|link=url,MyLink|align=left|width=128|height=128] </h3>

Renders as:

  <h3 align="center"><span class="inline inline-left"><a href="/drupal5/MyLink"><img src="/drupal5//web/drupal5_private/images/MyLink2.png" alt="" title=""  class="image image-_original" width="128" height="128" /></a></span> </h3>

The baseurl for my site is http://mysite.bogus/drupal5. My filesystem path is "/web/drupal5_private" and the download method is set to private. Please let me know if you need more info. Thanks for looking into this.

I'm having exactly the same problem: it looks like img_assist isn't paying any attention to the public/private setting. I'm just going to have a poke around to see if there's an easy fix (I do C++ and C#, not PHP, but I'll give it a go).

I'm using public files method and latest image and img_assist 1.x-dev. For several versions now i have the problem that all image derivates are only generated after running update.php (!) - running the cron doesn't help and also they don't get generated just after saving the node though the message "Derviate images for.... have been generated" implies this.

Probably the problem is the image filter rendering as there's no path to the image within the page after saving the node.

Any idea?

js1, Roger: Take a look at issue #176196 which deals with private files and absolute paths. It's probably better to move this discussion there unless there's something else is going on here.

flemschrott: Image derivatives are handled by the Image module. If they aren't generated when you add image nodes the usual way (Add content >> Image) then the problem is not with Image assist. Either way, this issue is about inline images now showing, not about missing derivative images. Please let's stay on topic here and discuss other problems in other issues. Thanks!

Reverting title and status. If someone still encounters this bug after upgrading from a previous version, please create a new issue and include all information about module versions and performed upgrade steps, thanks.