vstemen's picture

Posted by vstemen on Sun, Apr 29, 2018 - 10:56pm --- Updated: Apr 30 '18 - 10:12pm

I cannot seem to get the insert module to work. I added an image field to the page content type, enabled the insert button, and set it to be hidden under "Manage display".

When I edit a page, upload an image to the insert field, select the style, and click the Insert button, it inserts a broken link. For example, if I select the thumbnail style, it adds an img tag to the content with src="/files/styles/thumbnail/public/pictures/image-name.jpg", but the files/styles/ directory on the site is empty. The image style is never getting generated.

I thought I would try here, in case I am doing something wrong, before posting an issue for the insert module.

Accepted answer

Oh, you're on Nginx! Do you have a line like this in your configuration?

# To override the above rule, match more specifically against the image styles directory.
    location ^~ /files/styles/ {
        try_files $uri @rewrite;
    }

Comments

vstemen's picture

Mon, Apr 30, 2018 - 9:06pm by vstemen

In further testing, I disabled the insert module and have the same problem.

The problem seems to be with the image field. I unhid it under manage display and it still has the same problem as I mentioned. The styles/ directory is empty so it displays the alt text.

drop's picture

Mon, Apr 30, 2018 - 10:26pm by drop

It sounds like something about your setup is preventing the derivative images from being generated. Here are some things to check:

  • Check your status report (admin/reports/status)
    • Do you have the proper permissions on the /files directory?
    • Are the necessary GD libraries present?
  • Are you using the GD image toolkit? (see admin/config/media/image-toolkit)
    • If not, is your alternative (usually ImageMagick) properly installed?
  • Can you see a Preview (derivative image) on the image style page, admin/config/media/image-styles/configure/thumbnail?
  • Are your CSS and JS files aggregating properly, into the public files directory?
  • If you are running Apache...
    • Make sure your .htaccess file is present and contains the necessary rewrite rules.
  • If you are running NginX...
    • Make sure your configuration file contains the necessary rewrite rules.

Note: this post has been edited to include everything we tried in this thread.

vstemen's picture

Tue, May 01, 2018 - 11:33am by vstemen

> Check your status report (admin/reports/status)
Yes all looks good.

> Are you using the GD image toolkit?
Yes

> Can you see a Preview (derivative image) on the image style page
Yes, and the styles for the style previews are being generated.
i.e. styles/medium/public/core/modules/image/images/sample.png

Tue, May 01, 2018 - 9:22am by laryn

If your original image is extremely large, your server may be running out of memory when trying to generate the image styles. As a test, try uploading a small image and see if that makes any difference.

vstemen's picture

Tue, May 01, 2018 - 11:40am by vstemen

I wonder if something in my nginx configuration could be causing it.  I am using the same configuration as I use with Drupal 7.

But if that were the case, it seems like the style previews would not be generated either.

vstemen's picture

Wed, May 02, 2018 - 2:40pm by vstemen

Since previewing the styles generates the images in the styles/ directory, like it's supposed to, and saving a page with an image field does not, I put print statements in a bunch of the functions in /core/includes/image.inc and core/modules/image/image.module and core/modules/image/image.effects.inc to get a trace to try to discover the differences between what each one is doing.

I notice that when I view the image style, for example
admin/config/media/image-styles/configure/medium
It calls image_save(), which seems to be responsible for saving the new image style.

    image_style_load() 
    image_styles() 
    image_style_path() 
    image_style_create_derivative() 
    image_effect_apply() 
    image_scale_effect() 
    image_scale() 
    image_save() dest=public://styles/medium/public/core/modules/image/images/sample.png 
    image_effect_definitions() 
    image_style_load() 
    image_styles() 
    image_style_load() 
    image_styles() 
    image_style_load() 
    image_styles()

However, when I load and save the Edit Page screen image_save() never gets called.
Loading the edit page:

    image_style_transform_dimensions() 
    image_style_load() 
    image_styles() 
    image_scale_dimensions() 
    image_style_url(thumbnail, public://pictures/atx12v-adapter_1.jpg) 
        image_style_path() 
    >>image_style_url(thumbnail, public://styles/thumbnail/public/pictures/atx12v-adapter_1.jpg) 
    image_style_add_allowed_uri()

Also note that I am not seeing the image thumbnail on the edit page either.
When I click save:

    image_style_transform_dimensions() 
    image_style_load() 
    image_styles() 
    image_scale_dimensions() 
    image_style_url(medium, public://pictures/atx12v-adapter_1.jpg) 
        image_style_path() 
    >>image_style_url(medium, public://styles/medium/public/pictures/atx12v-adapter_1.jpg) 
    image_style_add_allowed_uri()

Again, image_save() is never called.

Could this be a clue as to what the problem is?
 

Wed, May 02, 2018 - 2:49pm by laryn

Is the image file actually saved on the server or not? Do you have any errors in the server's error log or the Backdrop watchdog logs?

vstemen's picture

Wed, May 02, 2018 - 4:36pm by vstemen

I looked again and do not see any errors in the nginx log except for the 404 results from the missing files.
e.g.

10.0.0.11 - - [02/May/2018:18:23:23 -0500] "GET /files/styles/thumbnail/public/pictures/atx12v-adapter_1.jpg HTTP/1.1" 404 169 "http://test1.test/node/3/edit" "Mozilla/5.0 (X11; FreeBSD amd64; rv:54.0) Gecko/20100101 Firefox/54.0"

drop's picture

Wed, May 02, 2018 - 4:50pm by drop

Oh, you're on Nginx! Do you have a line like this in your configuration?

# To override the above rule, match more specifically against the image styles directory.
    location ^~ /files/styles/ {
        try_files $uri @rewrite;
    }
vstemen's picture

Wed, May 02, 2018 - 5:48pm by vstemen

Shazam!!!  You solved it!  That was it.

Thank you very much drop.  That was why I posted earlier that I was running my Drupal configuration of nginx.  In case anybody knew of any backdrop specific changes I might need to make.

I had this in my config for Drupal,

    location ~ ^/sites/.*/files/styles/ {
            try_files $uri @rewrite;
    }

But I hadn't caught the path difference yet.

I was really starting to suspect it may be an nginx config issue when you said nobody else has been having such a problem.

Thanks again, and thanks to everybody else who attempted to help.

drop's picture

Sun, May 06, 2018 - 6:50pm by drop

Hooray!!!

Sorry I'd overlooked your earlier mention of nginx. This exact same problem caught me once too, I should have thought of it sooner!  Well, I'm glad it's resolved now, and hopefully this post will save the next person! :)

vstemen's picture

Mon, May 07, 2018 - 10:04am by vstemen

What initially threw me off the trail of thinking it was an nginx configuration problem was that the style previews were created and displayed back from the styles directory just fine. If that had the same problem, I would immediately have been looking closer at nginx.

I didn't expect an nginx configuration, to try directly accessing a file prior to passing the request to Backdrop, to prevent Backdrop code from generating it in the first place. I still don't have a clear understanding of why it affected it that way. The code to generate the styled images when saving or viewing a page of content seems a lot more abstract than the code that generates the style previews under the media configuration. In the style previews, the code checks if the file already exists, and if not, simply calls image_save() to create it.

Fri, Mar 08, 2019 - 8:10pm by stpaultim

I had a similar problem and this solved it. Because I'm very new to NGINX I was not clear what configuration file I had to change. I found it here on my server:

 - /etc/nginx/sites-available

drop's picture

Wed, May 02, 2018 - 3:50pm by drop

Since you are experiencing this problem but no one else running Backdrop is experiencing this problem, it's not likely to be something like a missing call to `image_save()` as that would affect everyone else, too. This is most likely a problem with your specific site, configuration, or environment.

The way image derivatives are supposed to work, is that a path to the image is built first. When an image is requested from that path, it is generated (if it does not exist already). You can see that at work in `image_style_url()`. You can follow this through to `image_style_save_allowed_uris()` where both a locking mechanism and a tempstore are used, I wonder of your site or environment might be having trouble with either of those systems?

Do you have the `database logging` module enabled? And was there anything of value in the logs? It seems very strange that you'd be having a problem this major without setting off alarm bells all over!

vstemen's picture

Wed, May 02, 2018 - 5:32pm by vstemen

Yes, the database logging module is enabled.  As I mentioned earlier, there are no errors in the recent log messages, unless there is somewhere else I should also be looking that I don't know about.

You mentioned image_style_save_allowed_uris().  I notice that that function is apparently never being called. I do have a print statement in it.  The last function called in my trace output from the print statements is image_style_add_allowed_uri().  Perhaps this is a clue, that the save function is not being called.

In image_style_add_allowed_uri(), there is

    if ($style_uri && empty($added_uris)) {
        register_shutdown_function('image_style_save_allowed_uris');
    }

I guess I will try to trace that out further.

vstemen's picture

Wed, May 02, 2018 - 3:12pm by vstemen

No the styled version of the image file is not being saved in the styles/ directory and there are no errors in the recent log messages.  I didn't notice any errors in the nginx web server log but I will take a closer look again.