css load error migrating from 2.7.8 to 2.7.10

[Sergi]

Hi,
We are upgrading from 2.7.8 to 2.7.10 and we have an error loading some css.

We have it defined like this:

<module_design id="itop-portal"  xsi:type="portal" _delta='merge'>
      <properties>   
        <themes>
              <theme id="company_portal" _delta="define">company-portal-extension/css/company_portal.css</theme>

it is working fine in 2.7.8, but when we are upgrading to 2.7.10 we get this error in the browser:
http://localhost/itop/pages/exec.php/env-production/company-portal-extension/css/company_portal.css?itopversion=2.7.10 was not loaded because its MIME type, “text/html”, is not “text/css”.

Any help would be appreciated,
Thanks

[Guillaume Lajarige]

Hello Sergi,

This might be related to something we did in 2.7.10 indeed with this commit.

If you have a test instance, could you try to apply changes from this commit on the specified files?
Then run iTop setup again and tell us if it works again.

Guillaume

[Sergi]

Hi Guillaume,

Yes, that fixed my issue, thanks a lot!
I had to reverse the changes in both files and not only in the layout.html.twig as the regression fix suggested, but yeah, I got it working again.

Thanks!!

[Guillaume Lajarige]

Do you mean that you first tried to apply the second fix first, but it wasn't enough and you had to revert both commits to make it work?

Thanks for the feedback :)

[Sergi]

Hi Guillaume,

Yes, exactly.

That fixed my custom css for the user portal.

But I still have an issue on the agent backend, we have Calendar View extension 2.0.1. and some of the js are not loading and seems the same problem:
“https://company.com/iTop/env-production//fullcalendar/fullcalendar.min.js?t=1713874660.6421” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).

Any hint on this one?

Thanks!

[Guillaume Lajarige]

It might be due to your Apache server configuration, check this page.

[Sergi]

Hi Guillaume,

Thanks for the hint.
The issue actually was in the dashlet-calendar and I fixed it by removing the GetCurrentModuleDir(0) in the dashletcalendar.class.php and hardcoding 'dashlet-calendar' after seen this in the definition of GetCurrentModuleDir on utils.inc.php:
* Warning : returned result can be invalid as we're using backtrace to find the module dir name

Seems GetCurrentModuleDir changed from 2.7.8 to 2.7.10, but I didn´t go deeper on that as harcoding the name of the module worked :)

Thanks a lot for your help!