Jump to content

ProcessWire Blank page issue!


Recommended Posts


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 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:

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!






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.


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] /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

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.



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

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Similar Content

    • By MarkE
      I have a selector:
      $pageArray = $pages->find("template=basic-page, length.magnitude>0, include=all"); I would like an array of each of the 'length' fields. However, the field is an object and $pageArray->each('length') returns the formatted values; I want the unformatted objects.
      I thought perhaps I could use a callable like:
      $pageArray = $pages->find("template=basic-page, length.magnitude>0, include=all"); $lengths = $pageArray->each(function($p) { $length = $p->getUnformatted('length'); return $length; }); but it seems that only strings can be returned and those are concatenated.
      So it looks like I have to use a foreach() loop - which works, but I was expecting some neater shorthand. Any thoughts?
    • By JeevanisM
      I have installed 1 year old project backup into the new latest PW version. I used an earlier backup(taken in August 2020) and installed such as :
      1. I downloaded the latest (ProcessWire 3.0.185 dev © 2021) then extracted into htdocs 2. copy pasted the site-profile from my backup. (this has the files/folders same as other site profiles, classic, beginner etc) 3. I chose my backup site profile and installed 4. I am able to login the admin panel  5. My fronted home page shows error as below  Error: Exception: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'page_path_history.language_id' in 'field list' (in wire/modules/PagePathHistory.module line 752) #0 wire/modules/PagePathHistory.module (752): PDOStatement->execute() #1 wire/core/PagesPathFinder.php (1014): PagePathHistory->getPathInfo('/', Array) #2 wire/core/PagesPathFinder.php (222): PagesPathFinder->getPathHistory('/') #3 wire/core/PagesRequest.php (255): PagesPathFinder->get('/', Array) #4 wire/core/Wire.php (414): PagesRequest->___getPage() #5 wire/core/WireHooks.php (951): Wire->_callMethod('___getPage', Array) #6 wire/core/Wire.php (485): WireHooks->runHooks(Object(PagesRequest), 'getPage', Array) #7 wire/modules/Process/ProcessPageView.module (10 This error message was shown because: you are logged in as a Superuser. Error has been logged.
      so I removed the line where its selecting language_id from the file wire/modules/PagePathHistory.module line 752
      But this is an ugly fix, so is there any other proper fix for this issue ? Does any one experience same issue when trying to install from a backup site profile ? 


    • By Webrocker
      I updated to the currently latest master (3.0.184) and now a lister (listerPro 1.1.3) preset shows the info cited in the title.
      According to this closed issue this is supposed to work <del>in 3.0.184</del>

      or is this a lister(pro) issue?

    • By sebr
      I'm using Processwire 3.0.180.
      When I edit a page in admin, Tracy Debugger count between 50 and 100 pages loaded, depending on the templates. All pages open in less than a second.
      But when I edited pages from a certain template, this pages opened in more than 40 seconds and Tracy Debugger count more than 14000 pages loaded.
      When I look in the pages loaded list, I find a very large amount of lines that look like this:
      1247 /sc_admin/repeaters/for-field-182/for-page-1246/ Page 1248 /sc_admin/repeaters/for-field-158/for-page-1246/ Page 1249 /sc_admin/repeaters/for-field-159/for-page-1246/ Page 1250 /sc_admin/repeaters/for-field-169/for-page-1246/ Page 1251 /sc_admin/repeaters/for-field-170/for-page-1246/ Page 1252 /sc_admin/repeaters/for-field-180/for-page-1246/ Page 1254 /sc_admin/repeaters/for-field-137/for-page-1253/ Page 1256 /sc_admin/repeaters/for-field-182/for-page-1255/ Page 1258 /sc_admin/repeaters/for-field-170/for-page-1195/ Page 1261 /sc_admin/repeaters/for-field-182/for-page-1132/ Page 1262 /sc_admin/repeaters/for-field-159/for-page-1132/ Page 1263 /sc_admin/repeaters/for-field-169/for-page-1132/ Page 1264 /sc_admin/repeaters/for-field-170/for-page-1132/ Page 1265 /sc_admin/repeaters/for-field-180/for-page-1132/ Page Or other like :
      10222 /sc_admin/repeaters/for-field-138/for-page-5710/1623420295-8678-1/ RepeaterMatrixPage 10232 /sc_admin/repeaters/for-field-138/for-page-5710/1623420316-7346-1/ RepeaterMatrixPage 10242 /sc_admin/repeaters/for-field-138/for-page-5708/1623482402-7605-1/ RepeaterMatrixPage 10256 /sc_admin/repeaters/for-field-138/for-page-10254/1624257169-0968-1/ RepeaterMatrixPage 10266 /sc_admin/repeaters/for-field-138/for-page-10254/1624257191-2937-1/ RepeaterMatrixPage 10278 /sc_admin/repeaters/for-field-138/for-page-10254/1624257284-3093-1/ RepeaterMatrixPage 10289 /sc_admin/repeaters/for-field-138/for-page-10254/1624258816-4716-1/ RepeaterMatrixPage 10302 /sc_admin/repeaters/for-field-138/for-page-10254/1624259001-0062-1/ RepeaterMatrixPage 10312 /sc_admin/repeaters/for-field-138/for-page-10254/1624259056-5808-1/ RepeaterMatrixPage 10326 /sc_admin/repeaters/for-field-138/for-page-10254/1624259204-4337-1/ RepeaterMatrixPage 10336 /sc_admin/repeaters/for-field-138/for-page-10254/1624259240-545-1/ RepeaterMatrixPage 10347 /sc_admin/repeaters/for-field-138/for-page-10254/1624259280-7777-1/ RepeaterMatrixPage 10357 /sc_admin/repeaters/for-field-138/for-page-10254/1624259299-317-1/ RepeaterMatrixPage 10369 /sc_admin/repeaters/for-field-138/for-page-6006/1624259684-8705-1/ RepeaterMatrixPage 10381 /sc_admin/repeaters/for-field-138/for-page-10379/1624259765-4187-1/ RepeaterMatrixPage More than 10000...
      This template doesn't contain repeaterMatrix.
      How can I understand what's happened ?
      Thanks for your help
    • By Guy Incognito
      We have a client's Processwire site where the Pageimage::size() method has stopped working. It's creating small white PNGs in the assets folder instead of the resized image as usual.
      Their hosting was recently upgraded and switched to PHP 7.4 and I'm wondering if a they've removed a PHP package or changed a server config to cause this.
      Does anyone know if the image resizing functionality requires specific PHP modules I need to check for?
      I've checked the folder permissions on the server - this all looks fine.
  • Create New...