Latest GIT version of OMERO.figure fails during export

[Sethur]

Hi again,

thanks for the help. Just wanted to post the steps to resolve the problem here, as parts of it went via private messages:

The issue was, that the folder lib/python/omeroweb/static was still serving the old version of the figure.css template. After deleting the whole static folder and refreshing the browser cache once again, the correct version was loaded.

Is there a reason why the old figure.css in static was not replaced by the one in figure/static ?

Cheers,

Tristan

[wmoore]

Hi Tristan,

Glad this is working now.

When you run

$ bin/omero web start

This calls Django's collectstatic command
http://django-staticfiles.readthedocs.o ... lectstatic
to gather all static files from installed apps into omeroweb/static.

This should handle updating of modified files.
I don't know exactly how these are being checked but when I just tried it locally,
modifying figure.css, then restarting web, it seems to work...

Code: Select all

$ bin/omero web stop
$ bin/omero web start
...
Copying '/Users/wmoore/Desktop/FIGURE/figure/static/figure/css/figure.css'
...
1 static file copied, 681 unmodified, 2 post-processed.


Does that help at-all?

Cheers,

Will.

[Sethur]

Hi Will,

so Django should update the static directory with files from the respective subdirs no matter what? I had assumed that figure.css did not get "downgraded" with the 1.0.0 version precisely because I was performing a downgrade, i.e. the figure.css in the figure/static directory had an older timestamp than the figure.css that originally came from the HEAD version of OMERO.figure.

If updates always happen, I am not sure why this was not the case at our environment. I definitely restarted OMERO.web several times along the way.

Cheers,

Tristan

[sbesson]

Hi Tristan,

it seems you are right and that Django is updating static content based on timestamps. See for instance this thread on similar issues with time zones.

I was able to reproduce the issues by setting the timestamp on a static file, i.e.:

Code: Select all

$ touch -t 03100000 lib/python/omeroweb/webclient/static/webclient/css/layout.css
$ bin/omero web syncmedia
Copying '/Users/sebastien/code/ome/openmicroscopy/dist/lib/python/omeroweb/webclient/static/webclient/css/layout.css'
Post-processed 'omeroweb.viewer.min.css' as 'omeroweb.viewer.min.css'
Post-processed 'omeroweb.viewer.min.js' as 'omeroweb.viewer.min.js'

1 static file copied, 604 unmodified, 2 post-processed.
$ touch -t 03110000 lib/python/omeroweb/webclient/static/webclient/css/layout.css
$ bin/omero web syncmedia
Copying '/Users/sebastien/code/ome/openmicroscopy/dist/lib/python/omeroweb/webclient/static/webclient/css/layout.css'
Post-processed 'omeroweb.viewer.min.css' as 'omeroweb.viewer.min.css'
Post-processed 'omeroweb.viewer.min.js' as 'omeroweb.viewer.min.js'

1 static file copied, 604 unmodified, 2 post-processed.
$ touch -t 03060000 lib/python/omeroweb/webclient/static/webclient/css/layout.css
$ bin/omero web syncmedia
Post-processed 'omeroweb.viewer.min.css' as 'omeroweb.viewer.min.css'
Post-processed 'omeroweb.viewer.min.js' as 'omeroweb.viewer.min.js'

0 static files copied, 605 unmodified, 2 post-processed.


In general this hints towards some caution while downgrading an OMERO.web application deployed from a source control repository as you suggest. Downloading a release distributed source and unpacking it locally should set the current time as the timestamp and thus protect downgrading from this static issue.

Thanks for notifying us of this. Best,
Sebastien