Deployed FTP version totally broken compared to local one

hello I am quite desperate.
see screenshot…

this is a local example of a working home page

following are screens in which css seems broken.

no background-images are loaded in any case and upper menu is standard with no style applied

same issue happens for inner pages in which NO images are loaded.
in home page JS to be loaded when main title THINK DIGITAL… is showing up, is broken.
no errors anywhere…

what the hell is going on?!!?!?
shall I RE-DEVELOP ANYTHING in old way from scratch!?!?!? :cry::cry::cry::cry::cry::cry:

Open the Dev Tools in Chrome and first check for failed or missing stylesheet downloads.
For Sage 10 this should be the app.css.

no errors. on sage 9 :frowning:

What is the href of

<link rel='stylesheet' id='sage/main.css-css'  href='

what you mean?
the header should have it own _headers.scss file. but the menu on the right is broken.
but some other items, like the logo are working fine…

also the WISYWIG editor looks weird…

here you go, sorry, I got you just now.

<link rel="stylesheet" id="sage/main.css-css" href="" type="text/css" media="all">

Well, does that stylesheet URL indeed lead to the stylesheet or to something else, like a HTTP 404 or blank file?

When I request it myself I get a non-CSS response:



So it seems that something is off with the htaccess/VHost configuration.

why there is a double slash after the .com//

and JS is not working properly as well :frowning:

It appears that you have fixed the style URL issue now.
It was probably the same issue with the script file, too.

nope, some JS are not loading nor working online… :frowning:
splitting.js is one of those…

I can’t figure it out how the heck is that possibile that a JS is working off, but NOT online…
just parts of scripts…

there’s also some sort of spilling in the code, which seems to broke the DOM.

Schermata 2021-03-30 alle 23.08.33

I am quite upset as nothing is going as it was meant to :frowning:

Does the issue still persist?
Are you sure this only happens on production (on that server) and not also on development (your workstation/dev setup)?

seems connected to something in application.php

since I moved .env outside the public folder, I var_dumped the path to debug the access to the root directory.

the vardmpu code was icstring(14) /mypath/ but now it is still there that “ic”… don’t know why

Some ideas:

  1. Proper FTP transfer mode used (text vs binary) for the PHP files?
  2. Proper encoding (UTF-8) and line endings (UNIX style LF) used for the PHP files?


I am using pHPstorm don’t think it is breaking encoding:

getting sick to find where this is coming from…
bizzarre it is not present in staging, on localhost AND UPDATE: NOT PRESENT IN ADMIN!!!

So this issue is visible only on that VHost on the frontend.

  1. Any kind of cache in use, e.g. PHP opcache, object cache like Redis or memcache(d)?
  2. Have you reloaded the frontend site with caches disabled/purged (Chrome hard reload)?
  3. Are you sure that all these PHP files have been successfully overwritten with their last version that you got on development?


YES: this happens also on Safari


This topic was automatically closed after 42 days. New replies are no longer allowed.