Update of composite image and color png layers

[numeroteca]

It's unclear to me when the composite image gets updated. Sometimes I just modify an area and "save and display", and it works. Others It just doesn't get updated.

[rahulbot]

The composite images are deleted by calling the @thread.remove_composite_images method. This happens right now in a few places (based on a find-in-files for that method):

• coding_controller->process_highlighted_areas: there is a new highlighted area
• images_controller->download: we successfully downloaded a missing image manually
• threads_controller->update: the topics or date or something about the thread has change
• threadx->after_save: the thread properties (ie. maybe the date) were updated
• threadx->scrape_all_images: we scraped some new images So those are the reasons we flush the cached composite images at each of those points in code. Are there any missing? Could be a bug in one of those maybe?

[numeroteca]

I've been making some tests. Here is what I've found for the moment.

Not working:

• coding_controller->process_highlighted_areas: there is a new highlighted area

It should be added to this list:

• coding_controller->process_highlighted_areas: A highlighted area is modified + An image is coded as "nothing to code" + An image is cleared from highlighted areas.

On Mon, Jul 1, 2013 at 4:46 PM, rahulbot notifications@github.com wrote:

The composite images are deleted by calling the @thread.remove_composite_images method. This happens right now in a few places (based on a find-in-files for that method):

• coding_controller->process_highlighted_areas: there is a new highlighted area
• images_controller->download: we successfully downloaded a missing image manually
• threads_controller->update: the topics or date or something about the thread has change
• threadx->after_save: the thread properties (ie. maybe the date) were updated
• threadx->scrape_all_images: we scraped some new images So those are the reasons we flush the cached composite images at each of those points in code. Are there any missing? Could be a bug in one of those maybe?

— Reply to this email directly or view it on GitHubhttps://github.com/numeroteca/pageonex/issues/165#issuecomment-20286360 .

[rahulbot]

All of those cases you mentioned go through the process_highlighted_areas method... the first thing that method does is call @thread.remove_composite_images.

To double check I tested each case and these worked locally:

• image is coded as "nothing to code"
• there is a new highlighted area
• a highlighted area is modified
• An image is cleared of highlighted areas I tested by:
• doing the action specified
• then clicking "save"
• verify the folder under app/assets/[user_id]/[thread_id] has been deleted
• click "display" and see the composite image and the folder created

But not on the server, where the image URLs have hashes on the end of them. So I think it has something to do with the production image asset caching Rails is doing.

[rahulbot]

Indeed, it was production mode fingerprinting the images that was the root of the problem (see the Asset Pipeline Rails Guide for more info). I turned it off for production and now it behaves right.

Probably the right answer is that the composite images shouldn't be in the app/assets dir, but rather in the public dir (because they are dynamically changing). However, that is a bigger fix that I'm not willing to tackle right now.

[numeroteca]

Thanks, it works good now. This should somehow mentioned in the to do list for the future. How did you turned it off?

[rahulbot]

See commit d8180b687e49b67f747db87b74c91533c908699d , changes to config/environments/production.rb