DC image issue after upgrade to 23.01

[gegeny]

First of all, big thank you for all the effort for releasing the long-awaited new version!

I successfully upgraded from 19.01 except for getting the DC images work. Drawing of Zones within the DCs get rendered without any issue.

• I rebuilt the image cache and all devices (from assets/pictures/ ) get correctly rendered as well:
  

• For DCs, I get something like seen below:
  

• Looking at the browser debug, the image is not found:
  

I can see proper URLs for all other objects (including zones within the same DC):

The same issue exist in the demo instance: No background images for DC1 or DC2 but works well for the zones within the DC.

Best,
Zoltan

[pawsey-kbuckley]

Have just noticed exactly the same.

Seems to have arisen because of commit a942c238 which places a urlencode()
around the path to the images in the drawings directory, at Line 96

If I look at the generated HTML without the urlencode I see

<div class="canvas" style="background-image: url(&quot;drawings/AN_BK-05-30_cabs_walls_vents-P2.png&quot;); width: 835px;">

but with the urlencode I see

<div class="canvas" style="background-image: url(&quot;drawings%2FAN_BJ-05-27_cabs_walls_vents.png&quot;); width: 770px;">

Note that the forward-slash directory separator has been replaced by "%2F"
and that gets presented to the browser to load the image.

If you are in a Firefox tools inspector mode and you click on the former, you'll
get the image displayed, but if you click on the latter, you won'r.

It only appears to have affected dc_stats.php, as images displayed via
container_stats.php, are fine

[pawsey-kbuckley]

And just to add, in case those with very sharp eyes look at the above,
that the slight change in the names of the two images results from my 
inspecting two different instances of openDCIM.

The actual issue remans the introduction of that "%2F"

[pawsey-kbuckley]

The commit comment for a942c238 talks about

"... the one place it seems that we used a straight path to an image ..."

although that's not completely true, in that in the case of container_stats.php,
whch presents an image/map to the browser, there's a function, MakeContainerImage,
down at the Container class level that constructs the path from these components,
and it is the output of that class-level function that gets injected into the stream sent
to the browser, vis:

 $mapfile = $config->ParameterArray['drawingpath'] . $this->DrawingFileName;

Maybe if the DataCentre class had a similar function, then the need to have the
urlencode in dc_stats.php go away - or at least sees encoding edge cases get 
handled away from the code that injects the HTML?

[samilliken]

See the FAQ for the fix on this - it isn't in the openDCIM code, it's a server configuration directive.

[gegeny]

Perfect, it worked.

What puzzled me was that it was working for all objects except DC and the demo instance had the same issue.

[samilliken]

Ah, thanks for that reminder that I hadn't applied it to the demo site... it has been fixed, now.

[pawsey-kbuckley]

Is that "fixed", as in, applied the urlencode wholesale to the demo site?

Wondering because, I have a test 23.01 instance, and, as menrioned above,
 I have no issues with the display of images from within container_stats.php.

And to corroborate that, here's the rendered HTML from my 23.01 instance,
as seen vis Firefox's inspector tool:

<img src="drawings/AA_BN-01-70_cabs_walls_vents.png" alt="Container Image" width="601" height="350">

Note the lack of a "%2F" in place of the forward-slash there.

[wilpig]

It's not changing, you have the correction needed above. Make it or don't, that injection point isn't coming back in. Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: pawsey-kbuckley ***@***.***> Sent: Thursday, June 1, 2023 7:04:59 PM To: opendcim/openDCIM ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [opendcim/openDCIM] DC image issue after upgrade to 23.01 (Discussion #1364) Is that "fixed", as in, applied the urlencode wholesale to the demo site? Wondering because, I have a test 23.01 instance, and, as menrioned above, I have no issues with the display of images from within container_stats.php. And to corroborate that, here's the rendered HTML from my 23.01 instance, as seen vis Firefox's inspector tool: <img src="drawings/AA_BN-01-70_cabs_walls_vents.png" alt="Container Image" width="601" height="350"> Note the lack of a "%2F" in place of the forward-slash there. — Reply to this email directly, view it on GitHub<#1364 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAMTY6RYHADJUIBFYWICTNDXJFC4XANCNFSM6AAAAAAYWOIILA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#1364 (reply in thread)", "url": "#1364 (reply in thread)", "name": "View Discussion" }, "description": "View this Discussion on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[mfenton01]

Related to this issue I having same issue. However when applying the AllowEncodeSlashes On in the FAQ only fixed some of the maps not all of them .

[wilpig]

What is the name of your file that is getting mangled. i don't believe i've ever seen +-+ as an escape pattern

[mfenton01]

The maps I am having issues with are using this format. B4_.... I updated using underscores but that did not work . B4_FRA3_C_E2-403_Cage Layout_Version-1.4.png B3 - FRA3 - B-E1-121 - Cage Layout - Version 1.8.png

…

On Fri, Aug 25, 2023 at 12:56 PM Wilbur Longwisch ***@***.***> wrote: What is the name of your file that is getting mangled. i don't believe i've ever seen +-+ as an escape pattern — Reply to this email directly, view it on GitHub <#1364 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVY4IO3SBJKTNV42R47MDDXXDRMZANCNFSM6AAAAAAYWOIILA> . You are receiving this because you commented.Message ID: ***@***.***>

[wilpig]

It's gotta be an encoding issue in your DB or something. I've used both of those file names with the dev instance at https://dev.opendcim.org/container_stats.php?container=18 and it loads fine.

https://dev.opendcim.org/nest1/nest2/dra'ings/B3%20-%20FRA3%20-%20B-E1-121%20-%20Cage%20Layout%20-%20Version%201.8.jpg

What I do see on yours that is different is that the path has the slash encoded. That makes me think that the path in your configuration was likely saved without a trailing slash and your image was added with a leading slash somehow.

[mfenton01]

I agree .. I cleaned up name and with the FAQ Scott provided resolved the issue.