Help with non docker LAMP install of xibo

Long time user of xibo since 1.4.2. Updating to newer server hardware. Stats according to info.php OS Ubuntu LTS, PHP 5.6.33-3, Apache 2.4.29, mysql 5.0.11 (Ver 14.14 Distrib 5.6.16 from terminal ), ZMQ 1.1.3.
Virtualhost *:4081
DocumentRoot /var/www/html/xibo-cms/web
xibo is located at /var/www/html/xibo-cms/web
When I go to localhost:4081 the screen is blank address is http://localhost:4081/install/.
I have been looking at url rewriting and .htaccess. What else should I be looking at?

Perhaps try dropping the ServerName line? I’m not sure if Apache isn’t matching your request to the vhost because of that. It’ll be expecting a Host header for from the browser, and won’t be receiving one.

I commented out the server name lines. Restarted and check status of apache. No change in function. I feel like it has something to do with the url rewrite. The other web site on this server does not utilize url rewrite and is working fine.

attached are the conf files and htaccess file.



Any help would be greatly appreciated.

Not sure what I am missing. It shouldn’t be that hard. I have always been able to search through the forum and find a solution. I have read and re-read for hours tried countless settings to no avail. Guess I’ll just use the old version and old server, just not worth the hours invested in trying to get this up and going.

This is the Apache conf we include inside the docker container:

Perhaps some insight in there?

Maybe your Apache hasn’t got rewrite enabled? You might need to load the rewrite module?

Alias /xibo /var/www/html/xibo-cms/web

I see you’re using an alias - so you’ll need to adjust your rewritebase to /xibo/ in the.htaccess`

To be completely honest, this is why we’ve invested so much of our time getting a recommended web container working with Docker. It can be used as the absolute reference for how things should be set up.

To be honest. I have setup xibo and other php applications over the course of several years. Have been using xibo since 1.4.2, and updated to every stable release and currently use 1.7.9 in the production server. I am running multiple web sites and php apps on the current server. I never thought it would be so complicated to get this going. I did not want to have to learn to setup docker and then try and run everything else with it. I felt like how hard can it be to add url rewrite.

Well it shouldn’t be that hard to add url rewrite - what is hard is knowing how to add url rewrite in every potential configuration - its literally impossible for us to do, although we do try.

I think you’re basically nearly there - it will be your alias causing an issue because the URL re-writer doesn’t understand that is in play.

After looking at things I have commented out the alias in the sites-enabled, and in the htaccess files. This matches your information provided. Verified the rewrite module is loaded. Found some info on-line about how to test the rewrite engine. Using the test procedures I was able to verify that rewrite engine is installed, enabled and functioning. In doing so confirmed that the htaccess file is being used.

Then I downloaded the xibo version 1.8.6 and extracted those files to the server document root.

After all of that testing xibo will not load. No matter what I put in the browser ie: “localhost:4081”, “localhost:4081/index.php”, or even “localhost:4081/xyz123” the browser address is rewritten to “localhost:4081/install/” and the page is blank.

Just to be clear after any change to files apache2 is restarted and the status checked. Then before trying to load the web-page, the cache is cleared and the browser restarted.

After tracing my steps through the entire process I have found the problem. As always it is the little things. Some where in this whole process the file permissions got changed back to root. After chown -R for the document root to www-data everything works.

So even after doing things step by step and making notes of what has been done, always recheck each and every step.

Its really good to hear you managed to get this working in the end!! Thanks for the perseverance and for reporting back the final solution.

its interesting that file permissions on their own caused this, i’ll run some tests and see if we can throw up a “your file permissions are wrong” message somehow.