After upgrading to version 1.8.3, the statistics displayed in the console disappeared, and selecting the screens / statistics option causes an error.
Log:
End of script output before headers: bootstrap-datetimepicker.pl.js,
Did you try clearing your web browser cache?
If it’s not that, please tell us more about your environment. Docker or not? If not, how did you do the upgrade? Did you remove all the old files, or just overwrite?
CMS web version, I was following the instructions included. The browser’s cache is cleared, I actually overwritten the files, and I did not delete them. After re-logging into the panel, the upgrade process passed without any errors. Everything works fine except for statistics (in the main panel) and error (Unexpected Error, please contact support.) After selecting Statistics from the right panel. Not a docker
Overwriting might leave behind files that cause these kinds of errors.
You need to move your old CMS installation files, and extract the new CMS files freshly from the archive in their place, replacing your settings.php file back in the “web” folder.
Well, it seemed to me that I was wiser and what I would not be able to do was try the old version. Like the writers, that’s how you have to do it, you have to do it. Everything works perfectly. Thank you very much for your help and I apologize for noob 
Hello Alex,
I have the same issue here. I upgraded from 1.8.2 to 1.8.3, the Docker 
version. And I tried to reproduce what for me is a bug. You can reproduce it too if you follow these steps:
I have a custom theme that I put in:
/home/docker/xibodocker/shared/cms/web/theme/custom/mytheme
I opened a bash in the container:
docker exec -ti xibodocker_cms-web_1 bash
And once in the container I compressed the views,css and img folders to transfer them into my theme:
cd /var/www/cms tar -czf /var/www/cms/web/views.tar.gz views cd web/theme/default/ tar -czf /var/www/cms/web/css.tar.gz css tar -czf /var/www/cms/web/img.tar.gz img
I quit the container and download the three archives through http://myxiboadress/views.tar.gz and do the same with css and img
Then I extract the three files to three folders (css, img and views) under home/docker/xibodocker/shared/cms/web/theme/custom/mytheme
That way I can modify the files and adapt them to the colors of my company.
Once I do this, I change the file config.php and add the line at the end:
‘view_path’ => PROJECT_ROOT . ‘/web/theme/custom/mytheme/views’
Once I do this, the statistics menu doesn’t work anymore and I have the message like the user d3fect:
Unexpected Error, please contact support.
If I comment the view path line, it works again.
Also I noticed something: the statistics menu isn’t at the same place whether I comment or uncomment the view path line. There is a new topic: REPORTING. Maybe it has something to do with the problem ?
Can you help me please ?
That’s absolutely not the way to make a theme.
The manual tells you exactly what you need to do to make a theme. If you don’t want to make your own, then Spring Signage offer a theme builder which you can use to generate a theme that will work.
To be clear, if it’s working without your theme applied, then the issue is with your theme and you will need to resolve that yourself.
Thanks for replying Alex.
I appreciate your spending time to work on Xibo and bring your help to users like me.
Nonetheless the thing is I read the manual and especially the theme part. More than once.
In the Advanced Theme page, you say:
To provide a new link it is necessary to override one of the Twig views the CMS uses to render its content.
You can then add Twig views to override the default views provided by the CMS, for example take a copy of /views/authed-sidebar.twig, save it in your view_path and add a new link at the appropriate place in the html.
Maybe I scarred you with my method for overriding the default files (views, css and img). I “overrid” them all with a copy of themselves 
If fact, you can override all the files with a copy of themselves and it works. But if you try to override the statistics page, it won’t work.
In your example, you override the authed-sidebar.twig file : it works !
But if you try to override the statistics-page.twig file : it doesn’t work.
You can try it by yourself. Don’t override anything but the statistics-page.twig file, you’ll get the error.
I’m sorry to bother you if I’m doing something wrong but that’s how I understand the manual.
Once again, thank you for your work, help and patience. 
By definition, if you override the statistics-page.twig file with itself it can’t be generating an error - because they’re the exact same page?
It’s likely to be whatever modification you’ve made to that file that is causing the issue.
What did you change in that file?
Nothing Alex. I just overrid the file with a copy of itself that is originally in the views directory at the root of the cms.
A word of warning - by overriding the entire contents of the theme folder with copies of itself you are effectively ensuring that you can never upgrade - any changes in an upgrade that effect the theme layer won’t be applied to your CMS in the future (because you’ve overridden them all). I’d argue that there isn’t a good reason to do that, but If that is what you want to do, then sure!
Themes are really intended for selectively overriding twig templates in exceptional circumstances.
Back on topic i’ve run a test and taken statistics-page.twig from /views and copied it into /theme/custom/dan/views which is my view path in /theme/custom/dan/config.php and it works.
It might be permissions on your /cache folder, as the new theme will try to modify cached copies of the twig templates.
I did that test now too, also without problems, with just a copy of the statistics-page.twig in my /theme/custom/myTheme/views/ and then with some changes made to it, at all times it loaded it correctly.
Other than that I do share Dan’s concerns about this approach, unless you’re about to make more changes to the source code, I’d suggest overriding the CSS if you’re after changes to overall look of the CMS.
Hello guys,
So sorry… 
You are right Dan, it was a permissions problem !!!
Thank you Alex, Dan and Peter. Your work is AMAZING !