Served path to plugin's static/img files...?


#1

I've got a plugin now and have an image in its static/img folder. I'd like to use OctoPrint-Themeify to adjust the CSS to point to this image but I can't figure out the path to it.

It doesn't appear to be ../img/whatever or ../../img/whatever, each turning into something like http://octopi.local/img/whatever and just ignoring the relative attempts.

What is the expected mechanism for including an image in a plugin and then referring to it by a path?

I've tried /plugins/plugin-name/img/whatever and this also didn't work. I tried adding static in there as well.


#2

I found this...

which is probably what you mean, but, probably not what ya really need, so, I also found this...

which would probably better suit yer needs


#3

I know where the file(s) are. What I need to know is whether OctoPrint actually serves them up by name and if so, from what URL path.

For example, if you're in your browser in OctoPrint, right-mouse click on the tentacle and choose Inspect Element (Safari), then in the stylesheet information you get a path of url(../img/tentacle-20x20.png). Still in that Inspect Element (Development) screen area, choose the Resources tab you see an Images subfolder in what was pulled down from the server. Hovering over the tentacle graphic, you see http://octopi.local/static/img/tentacle-20x20.png.

If I place my image file in that same ~/oprint/lib/python2.7/site-packages/octoprint/static/img folder, I may then refer to it as http://octopi.local/static/img/whatever and it will work. But this doesn't seem very clean since plugins shouldn't put their assets into the main OctoPrint area. There should be a way for the image asset to remain in its place and still be downloadable, I would think.


#4

possibly cause octoprint uses lazy load images and in that

that your looking at its showing a placeholder? Its just a guess


#5

I have a feeling that all the existing images in OctoPrint are packed and served up that way. I've not been able to serve any image assets yet.


#6

If you added the image to static/img/ in your plugin setup, the path to the image would be...

/plugin/<plugin_identifier>/static/img/<filename>


#7

Nice try, but that's a 404. :frowning:


#8

Are you bundling the plugin and installing via pip/plugin manager? This worked for me with the wizard template I was working on the other day. May also require the assetplugin mixin.


#9

Er, no. I'm installing via its github archive address. So presumably, bundling pushes it somewhere under ~/.octoprint/plugin or similar during the setup?


#10

Yeah, that's what I meant. If you're installing from github zip it should bundle the assets. What's the address?


#11

Here's the github fork and the README.md indicates:

https://github.com/OutsourcedGuru/OctoPrint-Themeify/archive/master.zip

...as the manual path. This version just points to the raw github-hosted path for the background graphic but I'd like it to use the as-included file.


#12

So /plugin/themeify/static/img/graph-davy-jones.png didn't work?


#13

Just tested and that does work....

Here is my copy of your code, with alterations...

https://github.com/jneilliii/OctoPrint-Themeify/archive/TEST.zip

There were a lot of odd characters in your source code that I did a quick replace on in _init.py, something specific to the editor you're using. Not sure if that was the source of your problems or not. Also when I pushed the commit to my TEST branch there were multiple errors in reference to line feeds being replaced with CRLF upon upload. Another indicator that your editor may be causing some issues, or just my machine didn't like it.


#14

Good catch, there. VS Code would be the culprit, methinks. It's made by Microsoft and the Windows world is full of CR+LF antiquities like that.

Did you install from the archive URL or from some other method?

I'll do a side-by-side compare to see what you've changed other than line endings. Thanks.

UPDATE: This is weird. I've just confirmed that my VS Code is set to use LF already. (Come to think of it, I would have known during my own numerous git push activities if it had been otherwise.) The LF in the bottom/right indicates that it's set correctly.


#15

The line feeds do show LF for me as well when I downloaded your code, but I think my issue with linefeeds was during the commit process. To be honest, I don't think this was causing an issue, but all my plugins are developed with CRLF and I haven't run into an issue related to that.

These however were what I was referring to about being weird to me...the apostrophe that is in there is a back tick in lieu of a single quote character...


#16

I'm guessing this comes from the original repository of Themeify itself. I certainly would have noticed backticks (since I often scold my students about same). I teach at a coding academy, btw.


#17

So did that url work? I think it's the correct answer to your original question...

I may have not been clear in my original post when using the tokens but to explain what I meant...

<plugin_identifier> = themeify
<filename> = graph-davy-jones.png

So
/plugin/<plugin_identifier>/static/img/<filename>
Becomes
/plugin/themeify/static/img/graph-davy-jones.png


#18

Sweet. Without any changes whatsoever to my code, that last URL appears to serve up the image file.

Thanks!