Jump to content

ProcessWire Blank page issue!


VirtuallyCreative
 Share

Recommended Posts

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

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

 

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. 

Link to comment
Share on other sites

@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

 

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

@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?

Link to comment
Share on other sites

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!

  • Like 2
  • Thanks 2
Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...