Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

osTicket v1.10 (stable) and Maintenance Release v1.9.15 are now available! Go get it now

1.9.3 on Plesk: CSS issue

Upgraded from 1.8.n.
Accessing from URL or email "ticket has been assigned" displays the web page but lacks CSS

access_log shows access to web page(s) and all seem to be 200
error_log is empty doesn't have any ini_set lines (per debug advice)

What have I fumble-fingered?
Please advise,


  • Have you tried clearing your browsers cache?

  • edited October 2014
    I'm on Plesk without issues. Are you on a windows or Linux install of Plesk?

  • MH-60, Linux.
  • @ntozier, did that, and tried from separate machine. Same result.

    1 do you expect the CSS URLs to contain an argument, eg from View Source:
        <link rel="stylesheet" href="/css/thread.css?bba9ccc" media="all">
        <link rel="stylesheet" href="./css/scp.css?bba9ccc" media="all">
    2 system is public-facing at is it possible that being a sub-domain (cf sub-directory only) is causing an issue? Are you able to view cleanly?

    Plesk Hosting settings: SSI support, PHP 5.4.32, CGI support
    include/ost-config.php > ROOT_PATH, "/" (file retained from previous version's implementation)

  • I'm presuming that its a server configuration issue because it works fine for me.  
    My current test bed is ost194.domain.ext and it works, so it does not appear to be a sub domain issue.

    What does this mean?
    "include/ost-config.php > ROOT_PATH, "/" (file retained from previous version's implementation)"

    I get that you may have kept your /include/ost-config.php file.  I'm using the same config file from circa 2009.. I'm not sure what the relevance of the rest of the statement is.
  • @ntozier,

    "relevance" you and me both. Included in case it was useful to you.
    Yes, I retained the ost-config.php file from the previous version.
    The command as I understand it starts the paths at the sub-domain's root directory cf a sub-directory.
    Mentioned only because some people implement sub-domains as sub-directories of the primary domain's root. Such is NOT the case here and the Plesk settings are separate (and can be different) for domain and sub-domains.

    "fine for me" means that you tested the URL provided earlier and the CSS works happily?

    Any comment on observation 1?

    Thanks for your help,
  • I can see your website cleanly, but it is clean like a 1990s website--not really any layout or markup beyond very basic minimalist--looks like it was made with "Visual Notepad". But the source shows lots of CSS calls

    Are all of your files there, and available to your webserver?

    I started looking at stylesheets, and couldn't see most of them. For example, when I try to get to, I get a 404 error.  Likewise with /scp/css/typeahead.css and /css/ui-lightness/jquery-ui-1.10.3.custom.min.css .
    However I could get /assets/default/css/print.css .

    When I try it on my install, they all come up.

    If it were my system, I'd figure I needed to change ownership or permissions on the install folders so apache could read them.  I've never used plesk, though, so YMMV.

  • @CharlesB,
    Yes the web pages display with no background and appear to have 'lost' my logo (both of which were working previously). NB I have not altered the HTML or CSS code in any way. I think the only change to stock-standard has been to add my logo.
    Yes there are files in the root and sub-directories, with >0KB, can be viewed, and privileges are all the same (so if login.php can be read, so should everything else).
    I've just tried to access osticket.css URL directly, through the browser, and it 404s on me too - but when I look at the access_log is reports 200 and error_log is clear. Logs also show you doing exactly that from Firefox32/WinNT6.1. Same for others you mentioned.
    With print.css I could indeed see the style sheet code. However the privileges on all of these files are exactly the same, as are all the sub-directories.
    Given the access_log entries I'm wondering if there's something like caching getting in there way here?
    Will contact the web host in the morning...
    Thank you for your help!

  • @CharlesB,
    When using your implementation, if you inspect the source code of a web page, eg a problem ticket, do the CSS links contain an argument or are their file names 'clean', eg thread.css and scp.css? This is what mine look like:
        <link rel="stylesheet" href="/css/thread.css?bba9ccc" media="all">
        <link rel="stylesheet" href="./css/scp.css?bba9ccc" media="all">
    I'm wondering why the ?bba9ccc - and if that's not come from osTicket then we likely have bigger problems!
    Please advise,
  • edited October 2014
    Mine look about like that, including the ?bba9ccc
    One difference that may or may not be the same is the location path.  If you have yours installed in your web root (whatever that is on your system) then your path looks ok.  If you have it in a subdirectory of your web root then manbe not.  For example, my web root is /var/www and my osTicket install is in /var/www/ost/basedir

    so on the source of a web page (a ticket) my stylesheet path looks like :

    <link rel="stylesheet" href="/ost/basedir/css/thread.css?bba9ccc" media="all">
    <link rel="stylesheet" href="./css/scp.css?bba9ccc" media="all">
    It still sounds like, for whatever reason, your css files are not available to your web clients. As long as you are getting a 404 when trying to access them in a browser, they won't be available to make your pages pretty.
  • Q: "fine for me" means that you tested the URL provided earlier and the CSS works happily?
    A: No.  It means that the the code runs fine on my installations.  multiple.

    Q: Any comment on observation 1?
    A: No comment.  It looks fine and how mine is.

  • 1 assuming it might be a hosting issue I raised the matter with my service provider. Nothing seemed obvious however one of their techs built a new sub-domain and copied the s/w across. He seemed to have the CSS working for the login page.

    2 when I tried to use the system, it wouldn't let me log in. Neither would the new password system work. We messed about with the DB to ensure that the domainNMs were correct and the system's config. Nothing worked.

    3 I rebuilt the original sub-domain, exactly per the tech's specifications. Again, the system refused to work, and the CSS was lost again.

    My conclusion is that the DB was corrupted during the 'upgrade'. However restoring my earlier copy, whilst it contained 'more data', did not bring the beastie back to life.

    Have decided not to sink any more time or effort into the issue - or the software.

    Hacked the SQL and migrated the lot to FreshDesk, about which the users have actually been complimentary.


Sign In or Register to comment.