Images no longer getting lightboxed part 3

docker

(Ben M) #1

Continuing the discussion from Images no longer getting lightboxed part 2:

I’m seeing the same problem here. Regardless of how they are added images are not lightbox’ed (they have no lightbox markup on the client side) when the post is submitted (I waited 24 hours to ensure any sidekiq tasks have had a chance to process the images).

I’m on docker version 1.2.0, Ubuntu 14.04.1 and Discourse version 1.2.0.beta5 and I used the guide here discourse/INSTALL-digital-ocean.md at master · discourse/discourse · GitHub to set it up.

I don’t see any jobs in my sidekiq named anything like PullHotlinkedImages in case that is important.


Discobot assets certificate.svg
Images no longer getting lightboxed part 4
(Régis Hanol) #2

Is your Discourse instance public? If so, can we get the URL?


(Ben M) #3

I’m afraid it isn’t public. Is there any other information I can give you?


(Régis Hanol) #4

Are you seeing anything that might be related in the /logs?


(Ben M) #5

In fact yes. :slight_smile: I just posted a large image and got this in the /logs

Uncaught TypeError: Cannot read property 'html' of undefined
Url: http://mysite/assets/application-081e28bec7c27ed6615906288bd7e375.js
Line: 2
Column: 69

And the stack-trace is

TypeError: Cannot read property 'html' of undefined
    at e.default.Ember.Mixin.create._rerenderString (http://mysite/assets/application-081e28bec7c27ed6615906288bd7e375.js:2:18551)
    at n.invoke (http://mysite/assets/vendor-dbbeea175424f8d4311b1fa7f19bb6c1.js:5:14081)
    at Object.n.flush (http://mysite/assets/vendor-dbbeea175424f8d4311b1fa7f19bb6c1.js:5:14604)
    at Object.r.flush (http://mysite/assets/vendor-dbbeea175424f8d4311b1fa7f19bb6c1.js:5:12761)
    at Object.s.end (http://mysite/assets/vendor-dbbeea175424f8d4311b1fa7f19bb6c1.js:5:7960)
    at http://mysite/assets/vendor-dbbeea175424f8d4311b1fa7f19bb6c1.js:5:6786

Could this be my problem?


(Kane York) #6

Nope, that’s a JS error, not a server error.

Hmm, are you getting emails sent at all? That’s a possible symptom of Sidekiq not actually running.


(Ben M) #7

Emails are being sent and Sidekiq jobs are running. Here’s what I see at `/sidekiq’


(Kane York) #8

And, of course, we can’t see what those 157 failures are. :confused:


(Ben M) #9

@riking do you mean that there’s no way to ever see those failures or just that I haven’t screen-grabbed them? If the latter, how can I access the sidekiq failure log?


(Régis Hanol) #10

There’s unfortunately no way to ever see those failures :frowning:


(Ben M) #11

Wow. Am I right in thinking there is a particular Sidekiq job that needs to run for the light-boxing to work?


(Ben M) #12

Ok, I added the sidekiq-failures gem to my Discourse bundle temporarily, restarted the docker container and now I see the Failures tab in my sidekiq dashboard. I tried add a large image again and there are no further errors reported

I watched the jobs created when I made the post and saw PullHotlinkedImages and NotifyMailingListSubscribers in the Scheduled tab. These both seemed to complete successfully (the Sidekiq Failed number didn’t go up and nothing in /logs). Looking at the Discourse source it looks like the ProcessPost job is the only one that can cause my image to get lightboxed. Any tips on how to debug that? Right now I don’t even know if that job executed.


#13

@benito_m, @zogstrip I had the same issue. The problem was in access to the server by proccess which generates the previews. It tries to determine image size by downloading it from itself but I have frontend proxy with basic auth on my server. So, it couldn’t download the image to make the preview until I added docker container’s ip to allowed list to get access without authorization. Maybe, It will help someone.


(Øyvind Hansen) #14

I’m wondering if I too has a similar issue. The discourse is a recently installed docker install (1. april 2015 aprox, running Discourse 1.3.0.beta6 now), followed the simple Digital Ocean recipe, except for CentOS instead of Ubuntu. The CentOS is running on a VMware VM, and is not available on the Internet, but the Discourse docker and CentOS do have Internet access.

Images linked from external sites does get a lightbox, but images uploaded from disk does not get a lightbox.
Have looked in /logs and also tried the logs inside docker but does not know what to look for.

As with:

We also get emails sent and PullHotlinkedImages seems to complete successfully.
I’m a new user; so I could not upload image showing that there is 14,992 processed and 46 failed jobs. I tried to upload images and follow what happened, but as far as I can see the PullHotlinkedImages-job ain’t the job that goes into “failed” category.

I’m not quite sure what @skyeagle did to troubleshoot their issue? But any feedback or help would be truly awsome to this awsome product :smile:


(Ben M) #15

Interesting…

I think I may have a more deep-rooted issue here though. You know this page…

Well, in that list of Recurring Jobs I see no entry for PullHotlinkedImages. Can anyone clear up which sidekiq jobs, if any, are required to make lightboxed images happen?


(Jens Maier) #16

It’s in /app/jobs/regular/pull_hotlinked_images.rb; but see also /app/jobs/regular/process_post.rb. Both of these are not run through the scheduler, they are enqueued explicitly when a post is created or edited and will only handle that one post.

But you have 6 pending scheduled jobs… and a lot of failed jobs. That seems to be a more interesting thing to check out. :slight_smile:


(Ben M) #17

I agree it would be nice to check them out but as you can see in my earlier post in this topic, I also don’t have any failures. :confused:


(Ben M) #18

Maybe this information might help someone diagnose this.

Say I paste this link to a large image https://static2.egu.eu/media/filer_public/2012/07/14/karymsky-3c438e544cb046916800fcbd69724d0f.jpg into a topic on my Discourse site. When I submit, the HTML that it generates is:

<div class="cooked">
    <p>More testing.</p>
    <a href="https://static2.egu.eu/media/filer_public/2012/07/14/karymsky-3c438e544cb046916800fcbd69724d0f.jpg" target="_blank">
        <img src="https://static2.egu.eu/media/filer_public/2012/07/14/karymsky-c438e544cb046916800fcbd69724d0f.jpg" width="690" height="435"></a>
</div>

So the image has been resized down to 690 x 435 but since the original image is 3328 x 2096 I would have expected the HTML above to include some lightbox markup, but it doesn’t.


(Jacob Chapel) #19

So the way the lightbox logic works is only if you have an image without a link. Like so:

<img src="https://static2.egu.eu/media/filer_public/2012/07/14/karymsky-c438e544cb046916800fcbd69724d0f.jpg">

If you just paste in an image link, it will convert it to a link around the image and the lightbox won’t show.

https://static2.egu.eu/media/filer_public/2012/07/14/karymsky-c438e544cb046916800fcbd69724d0f.jpg

Turns into:

<a href="https://static2.egu.eu/media/filer_public/2012/07/14/karymsky-3c438e544cb046916800fcbd69724d0f.jpg" target="_blank">
        <img src="https://static2.egu.eu/media/filer_public/2012/07/14/karymsky-c438e544cb046916800fcbd69724d0f.jpg" width="690" height="435"></a>

(Jacob Chapel) #20

@codinghorror @sam With the above said, I don’t think it should be that way. In my experience (and my own preference) users paste images to have them show and don’t care about the link to the original. Specially since we have the lightbox experience, a link to the original is not that valuable. I also hate the link tracker being next to images.

I really believe that image links should be treated just the same as any other image you’d insert with ![]() or <img> without a wrapping link. It would make the experience consistent, and those users that want to link can wrap it themselves.