ProcessWire Blank page issue!

[VirtuallyCreative]

Hello!

I was working on my website on Friday with what appears everything to be fine, and I come back today and now I can't access any page, I just get a white page with no information and no logs are logging what the issue is and I'm quite stumped frankly as to the cause.

Going to http://138.197.146.76/ just brings up a blank page and no error logs and it's driving me crazy trying to troubleshoot.

If you go to any other non-processwire page it works fine, like the php info page: http://138.197.146.76/info.php

At first I thought it was an .htaccess issue (UTF-8 BOM info being parsed by Apache2 a the head of the file) but in re-uploading it that didn't solve it.

Then I thought it was a php error from the index page being loaded but no PHP errors appear anywhere that I can see with a timestamp near to today, nor does the Processwire log update. It hasn't updated since the 10th and I'm not sure why.

After 10 years of WordPress development, I'm pretty decent at troubleshooting server issues but this just has me for a loop, I'm not sure what's going on here so if anyone has any insight or wouldn't mind taking a look to troubleshoot I can provide you with root access to the server (it's a Ubuntu 16 LTS droplet on Digital Ocean).

I've included dumps of my most recent logs, maybe I'm missing a detail? Any insight would be appreciated!

Regards,

Virtually(Creative)

errors.txt

access.log

error.log

[adrian]

Do you have debug mode turned on in site/config.php ?

That .htaccess error in your log looks suspicious.

[VirtuallyCreative]

@adrian Yup, I have

$config->debug = true;

inside my config.php.

I'm thinking it might still be an .htaccess issue, but at this point I'm unable to isolate it. If I rename .htaccess to htaccess.txt I then get a 500 internal server error going to any URL within processwire.

I thought it was to do with the UTF-BOM encoding issue but I believe I corrected it by uploading a UTF-8 only encoded .htaccess file.

[matjazp]

 

38 minutes ago, VirtuallyCreative said:

I thought it was to do with the UTF-BOM encoding issue but I believe I corrected it by uploading a UTF-8 only encoded .htaccess file.

Double check your .htacces file as it looks like UTF-8 BOM issue. 

[VirtuallyCreative]

@matjazp Ok I nuked my .htaccess file using the default one within processwire-master and re-uploaded it.

Now I no longer get a blank page, but a 500 Server error screen.

Progress!

I'm still getting the .htaccess error in the error.log now but I'm not sure why it's not fixed... I opened the .htaccess file in notepad and make sure to save as "all files" type and with only UTF-8 but I'm still getting the same error it appears.

If I touch the file using nano on the server via command line I don't see the "\exf\xbb\xbf" characters either.

Is there something I'm missing to correct this issue??

[Tue Feb 14 21:23:40.284736 2017] [core:alert] [pid 2797] [client 67.211.127.12:14112] /var/www/html/.htaccess: Invalid command '\xef\xbb\xbf###...', perhaps misspelled or defined by a module not included in the server configuration

 

[matjazp]

Just to be sure:

head -c 3 .htaccess | hexdump -C

doesn't show ef bb bf? Did you restart apache after change?

[VirtuallyCreative]

29 minutes ago, matjazp said:

Just to be sure:

head -c 3 .htaccess | hexdump -C

doesn't show ef bb bf? Did you restart apache after change?

@matjazp the result of that command is:

00000000   23 20 2d
00000003

Does that mean the characters are still there?

I'm not sure how to get rid of them if that's the case. I restarted Apache each time and I've open and saved the .htaccess file using Sublime Text, Notepad, Notepad++, VS Code. All of them say UTF-8 (no BOM)  yet I still can't fix the file or get those characters to appear to erase them from the head of the .htaccess file.

I appreciate your help.

Regards,

V(C)

[matjazp]

23 20 2d are "# -" so it looks like .htacces is ok, but the first line of htaccess.txt from the latest dev contains ####### ... just comments. No idea from my side but if apache is logging those BOM charaters than it must read them from somewhere. Are you editing the right file /var/www/html/.htaccess ? Caching? Also, setup locale.

[VirtuallyCreative]

Yup I'm editing the correct .htaccess file. I suppose caching could be on.. but it shouldn't be caching a .htaccess file, only .php pages? There are some .php pages in the /site/assets/cache/FileCompiler/site/ folder but I don't see any cached .htaccess file.

I've just been scratching my head at this and I've lost a full day of development now because of it and I'm starting to get frustrated that I can't troubleshoot this better.

 

[matjazp]

Hm... how about simple test: create a new .htaccess file with the following:

ErrorDocument 404 http://www.google.com/

and then pointing your browser to http://yoursite.com/foobar/ shoud redirect you to google.

[VirtuallyCreative]

@matjazp

You are correct. I created a fresh .htaccess with just that and in trying to visit a bad url it forwards me to google.

Still have a blank homepage however, and I can't access the /admin/ area at all.

[matjazp]

This test just confirms that your .htaccess in picked up and parsed by apache, so the real problem still has to be in your original .htacces. The mistery for me is how it could work on friday and then suddenly cease to work on monday. Maybe you could post your .htacces file (zipped)? What PW version are you running?

[VirtuallyCreative]

@matjazp Indeed, that is the puzzling question as I'm not sure what changed between Friday and Tuesday (was off Monday). The .htaccess file I was using is the default one from the /master/ branch of Github, nothing special no changes. And I'm running the latest version of PW (v3).

The one non-default setting was I changed admin backend URL from default "/pw/" to "/admin/". So I suppose that would be reflected in the .htaccess file and not the default one so that's updated during install process?

[matjazp]

How did you change that? .htacces has nothing to do with that. You might consider reinstalling all from scratch, but that would not solve the mistery and would not satisfy my brain's grey cells (what's left)  

[VirtuallyCreative]

@matjazp During the install process, you're asked if you want to change the URL for the ProcessWire backend, which in doing so I assumed would update a rewrite rule inside the .htaccess. I suppose it doesn't now that I look at the default .htaccess file...

 

[VirtuallyCreative]

Solved by @flydev!

Turns out I had the wrong permissions set for the top-level directory. Nothing to do with .htaccess as it turns out! 

All content of /var/www/html was attached to root's group. So a simple chown -R www-data:www-data /var/www/html did the trick.

I just want to say that I'm so thankful for how helpful the ProcessWire dev community is and will make sure to pay it forward!

[kongondo]

Glad you sorted it out. Question is, were those permissions changed between Friday and Tuesday? If yes, how and by whom? Hmm..

[flydev]

11 hours ago, kongondo said:

how and by whom? Hmm..

This is a good question, my bet go on an upload with a regular user and the files moved by root user..

[VirtuallyCreative]

@kongondo, @flydev upon further review, I think the culprit was... myself.

I also installed yoURLs in a sub-folder and I remembering messing with permissions during that script's install, and I thought I put them back to default probably not realizing the larger implications of doing so for ProcessWire as I was logged in as root rather then a sudo-enabled user.

Noob moment. Few lessons learned for sure.