Topics produce blank pages

Get help with installation and running phpBB 3.3.x here. Please do not post bug reports, feature requests, or extension related questions here.
User avatar
scooterbird
Registered User
Posts: 56
Joined: Tue Jul 07, 2020 8:40 am
Location: Columbia
Name: Steve
Contact:

Re: Topics produce blank pages

Post by scooterbird »

Alright, changing the .htaccess in /forums seems to have enabled posting, both from New Topic and Post Reply. I am elbows-deep in another project right now, so I have not asked my employee what exactly was changed; I will provide a more detailed summary when I am able.

Again, the collective help I have received here has been invaluable and is tremendously appreciated. I really don't know what I would have done without the expertise and grace of this community.
THE SCOOTERBIRD

"No bird soars too high if he soars with his own wings."
User avatar
scooterbird
Registered User
Posts: 56
Joined: Tue Jul 07, 2020 8:40 am
Location: Columbia
Name: Steve
Contact:

Re: Topics produce blank pages

Post by scooterbird »

An update: I can see all forums, topics, etc., but now posting (Replies and New Topics) are intermittent. Sometimes they work, sometimes they branch to a blank page.

No extensions seem to work. They immediately render forums and topics blank.

I have asked my employee (who is working the .htaccess angle) to come on and provide answers which I can't.
THE SCOOTERBIRD

"No bird soars too high if he soars with his own wings."
BadCatMamma
Registered User
Posts: 1
Joined: Thu Jul 09, 2020 2:06 am

Re: Topics produce blank pages

Post by BadCatMamma »

EA117 wrote:
Wed Jul 08, 2020 5:13 pm

Hi, there,

I'm scooter's coder (or as close as we have to one...).

The last back up .htaccess I've found is from file reads

[code}
AddHandler application/x-httpd-eig-php52 .php
DirectoryIndex index.php
[/code]
rxu
Extensions Development Team
Posts: 3387
Joined: Wed Oct 25, 2006 12:46 pm
Location: Siberia, Russian Federation
Name: Ruslan
Contact:

Re: Topics produce blank pages

Post by rxu »

Do you have some server-side cache enabled? Like APC/Memcached/etc.
User avatar
scooterbird
Registered User
Posts: 56
Joined: Tue Jul 07, 2020 8:40 am
Location: Columbia
Name: Steve
Contact:

Re: Topics produce blank pages

Post by scooterbird »

rxu wrote:
Thu Jul 09, 2020 3:00 am
Do you have some server-side cache enabled? Like APC/Memcached/etc.
Not to my knowledge. I'll let BadCatMamma respond when we are back on business hours.
THE SCOOTERBIRD

"No bird soars too high if he soars with his own wings."
User avatar
scooterbird
Registered User
Posts: 56
Joined: Tue Jul 07, 2020 8:40 am
Location: Columbia
Name: Steve
Contact:

Re: Topics produce blank pages

Post by scooterbird »

BadCatMamma wrote:
Thu Jul 09, 2020 2:35 am
The last back up .htaccess I've found is from file reads

[code}
AddHandler application/x-httpd-eig-php52 .php
DirectoryIndex index.php
[/code]
Alright, let me see if I can clarify this.

The following is /public_html/.htaccess:

Code: Select all

#Alternate default index page
DirectoryIndex index.php

# php -- BEGIN cPanel-generated handler, do not edit
# Set the “ea-php72” package as the default “PHP” programming language.
<IfModule mime_module>
  AddHandler application/x-httpd-ea-php72 .php .php7 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit

#Force https
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE] 
The following is /public_html/htaccessold:

Code: Select all

# AddHandler application/x-httpd-eig-php52 .php
DirectoryIndex index.php

# BEGIN cPanel-generated php ini directives, do not edit
# Manual editing of this file may result in unexpected behavior.
# To make changes to this file, use the cPanel MultiPHP INI Editor (Home >> Software >> MultiPHP INI Editor)
# For more information, read our documentation (https://go.cpanel.net/EA4ModifyINI)
<IfModule php7_module>
   php_flag display_errors On
   php_value max_execution_time 600
   php_value max_input_time 600
   php_value max_input_vars 5000
   php_value memory_limit 256M
   php_value post_max_size 260M
   php_value session.gc_maxlifetime 1440
   php_value session.save_path "/var/cpanel/php/sessions/ea-php73"
   php_value upload_max_filesize 256M
   php_flag zlib.output_compression Off
</IfModule>
<IfModule lsapi_module>
   php_flag display_errors On
   php_value max_execution_time 600
   php_value max_input_time 600
   php_value max_input_vars 5000
   php_value memory_limit 256M
   php_value post_max_size 260M
   php_value session.gc_maxlifetime 1440
   php_value session.save_path "/var/cpanel/php/sessions/ea-php73"
   php_value upload_max_filesize 256M
   php_flag zlib.output_compression Off
</IfModule>
# END cPanel-generated php ini directives, do not edit

# php -- BEGIN cPanel-generated handler, do not edit
# Set the “ea-php73” package as the default “PHP” programming language.
<IfModule mime_module>
  AddHandler application/x-httpd-ea-php73 .php .php7 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit
This is /public_html/forums/.htaccess:

Code: Select all

#Force https
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE] 

<IfModule mod_rewrite.c>
RewriteEngine on

# Uncomment the statement below if URL rewriting doesn't
# work properly. If you installed phpBB in a subdirectory
# of your site, properly set the argument for the statement.
# e.g.: if your domain is test.com and you installed phpBB
# in http://www.test.com/phpBB/index.php you have to set
# the statement RewriteBase /phpBB/
#
#RewriteBase /

#
# Uncomment the statement below if you want to make use of
# HTTP authentication and it does not already work.
# This could be required if you are for example using PHP via Apache CGI.
#
#RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]

#
# The following 3 lines will rewrite URLs passed through the front controller
# to not require app.php in the actual URL. In other words, a controller is
# by default accessed at /app.php/my/controller, but can also be accessed at
# /my/controller
#
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ app.php [QSA,L]

#
# If symbolic links are not already being followed,
# uncomment the line below.
# http://anothersysadmin.wordpress.com/2008/06/10/mod_rewrite-forbidden-403-with-apache-228/
#
#Options +FollowSymLinks
</IfModule>

# Apache content negotation tries to interpret non-existent paths as files if
# MultiViews is enabled. This will however cause issues with paths containg
# dots, e.g. for the cron tasks
<IfModule mod_negotiation.c>
	Options -MultiViews
</IfModule>

# With Apache 2.4 the "Order, Deny" syntax has been deprecated and moved from
# module mod_authz_host to a new module called mod_access_compat (which may be
# disabled) and a new "Require" syntax has been introduced to mod_authz_host.
# We could just conditionally provide both versions, but unfortunately Apache
# does not explicitly tell us its version if the module mod_version is not
# available. In this case, we check for the availability of module
# mod_authz_core (which should be on 2.4 or higher only) as a best guess.
<IfModule php7_module>
   php_flag display_errors Off
   php_value max_execution_time 600
   php_value max_input_time 600
   php_value max_input_vars 5000
   php_value memory_limit 256M
   php_value post_max_size 260M
   php_value session.gc_maxlifetime 1440
   php_value session.save_path "/var/cpanel/php/sessions/ea-php73"
   php_value upload_max_filesize 256M
   php_flag zlib.output_compression Off
</IfModule>
<IfModule lsapi_module>
   php_flag display_errors Off
   php_value max_execution_time 600
   php_value max_input_time 600
   php_value max_input_vars 5000
   php_value memory_limit 256M
   php_value post_max_size 260M
   php_value session.gc_maxlifetime 1440
   php_value session.save_path "/var/cpanel/php/sessions/ea-php73"
   php_value upload_max_filesize 256M
   php_flag zlib.output_compression Off
</IfModule>
# END cPanel-generated php ini directives, do not edit
And this is /public_html/forums/.htaccess123 - apparently an old version. Interestingly, this file was last touched at 5:20am on July 6, which is about the time that the issues with this forum began:

Code: Select all

<IfModule mod_rewrite.c>
RewriteEngine on

#
# Uncomment the statement below if URL rewriting doesn't
# work properly. If you installed phpBB in a subdirectory
# of your site, properly set the argument for the statement.
# e.g.: if your domain is test.com and you installed phpBB
# in http://www.test.com/phpBB/index.php you have to set
# the statement RewriteBase /phpBB/
#
#RewriteBase /

#
# Uncomment the statement below if you want to make use of
# HTTP authentication and it does not already work.
# This could be required if you are for example using PHP via Apache CGI.
#
#RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]

#
# The following 3 lines will rewrite URLs passed through the front controller
# to not require app.php in the actual URL. In other words, a controller is
# by default accessed at /app.php/my/controller, but can also be accessed at
# /my/controller
#
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ app.php [QSA,L]

#
# If symbolic links are not already being followed,
# uncomment the line below.
# http://anothersysadmin.wordpress.com/2008/06/10/mod_rewrite-forbidden-403-with-apache-228/
#
#Options +FollowSymLinks
</IfModule>

# Apache content negotation tries to interpret non-existent paths as files if
# MultiViews is enabled. This will however cause issues with paths containg
# dots, e.g. for the cron tasks
<IfModule mod_negotiation.c>
	Options -MultiViews
</IfModule>

# With Apache 2.4 the "Order, Deny" syntax has been deprecated and moved from
# module mod_authz_host to a new module called mod_access_compat (which may be
# disabled) and a new "Require" syntax has been introduced to mod_authz_host.
# We could just conditionally provide both versions, but unfortunately Apache
# does not explicitly tell us its version if the module mod_version is not
# available. In this case, we check for the availability of module
# mod_authz_core (which should be on 2.4 or higher only) as a best guess.
<IfModule mod_version.c>
	<IfVersion < 2.4>
		<Files "config.php">
			Order Allow,Deny
			Deny from All
		</Files>
		<Files "common.php">
			Order Allow,Deny
			Deny from All
		</Files>
	</IfVersion>
	<IfVersion >= 2.4>
		<Files "config.php">
			Require all denied
		</Files>
		<Files "common.php">
			Require all denied
		</Files>
	</IfVersion>
</IfModule>
<IfModule !mod_version.c>
	<IfModule !mod_authz_core.c>
		<Files "config.php">
			Order Allow,Deny
			Deny from All
		</Files>
		<Files "common.php">
			Order Allow,Deny
			Deny from All
		</Files>
	</IfModule>
	<IfModule mod_authz_core.c>
		<Files "config.php">
			Require all denied
		</Files>
		<Files "common.php">
			Require all denied
		</Files>
	</IfModule>
</IfModule>
Again, thanks in advance for any insights.
THE SCOOTERBIRD

"No bird soars too high if he soars with his own wings."
User avatar
scooterbird
Registered User
Posts: 56
Joined: Tue Jul 07, 2020 8:40 am
Location: Columbia
Name: Steve
Contact:

Re: Topics produce blank pages

Post by scooterbird »

Current Status:
  • Posting and Replying seems to be working.
  • UCP and MCP seems to be working.
  • Private Messages do not work. Blank page displayed immediately.
  • Some tabs in ACP display blank pages intermittently.
  • Enabling any extensions at all causes all forums to stop working and return a blank page on click.
  • Some users having problems with passwords not working - probably because of the PHP 7.2 switch. I'm getting them in with changed passwords.
THE SCOOTERBIRD

"No bird soars too high if he soars with his own wings."
User avatar
EA117
Registered User
Posts: 1805
Joined: Wed Aug 15, 2018 3:23 am
Contact:

Re: Topics produce blank pages

Post by EA117 »

scooterbird wrote:
Thu Jul 09, 2020 4:13 pm
The following is /public_html/.htaccess:
So at the root of the site, it does appear they switched from PHP 7.3 to PHP 7.2. The PHP configuration doesn't always end up "in the .htaccess file", but its certainly one place in which it can be done.

Something I don't have a direct explanation for is why the HTTPS redirect rule shown in this root-level .htaccess wasn't already having an effect on the http://atlantic-computing.com/forums/ path. The rule looks correct to me, and I would have expected this root-level rule to have already been redirecting access attempts to http://atlantic-computing.com/forums/, too. It's as though the way this host has Apache configured, the http://atlantic-computing.com/-level folder rules don't come into play when accessing http://atlantic-computing.com/forums/?

I'm not familiar with that happening, and would not know how to explain it. But it does make me want to also consider "Does this mean the PHP changes we're seeing in the root-level .htaccess aren't having an effect at the http://atlantic-computing.com/forums/ level, either?" So although PHP 7.2 has been set at the root folder, it's not clear whether we can expect this will be inherited into http://atlantic-computing.com/forums/.

In this configuration shown by the .htaccess files you posted, what is showing in the phpBB ACP General tab's "PHP Information" now regarding PHP version? Is it still PHP 7.2.x as was seen earlier (which implies maybe the AddHandler in the root .htaccess is coming into play, even though the HTTPS redirect rule did not), or is it actually showing PHP 7.3.x again now. Just as extra evidence for whether those directives we see in the root-level /public_html/.htaccess are in effect for the /public_html/forums/ folder or not.

scooterbird wrote:
Thu Jul 09, 2020 4:13 pm
This is /public_html/forums/.htaccess:
The "old" version is just a straight copy of what ships in phpBB 3.3.0, so there is nothing unusual there.

In the current version, besides the "seems like this should not have been necessary" HTTPS redirect rule (as discussed above) which was duplicated to this directory level too, something that seems unusual is that the PHP 7.3 configuration -- but not the actual PHP 7.2 or PHP 7.3 handler -- has been introduced here.

The PHP 7.3 configuration shown is the same configuration block which used to be in the "old" .htaccess at the root of the site, except this current example has "php_flag display_errors Off" instead of "php_flag display_errors On". The more unusual part to me though is that the php_value session.save_path "/var/cpanel/php/sessions/ea-php73" implies this is still configuration intended for PHP 7.3. Yet the root-level PHP handler has been set to PHP 7.2, and no explicit PHP handler has been set in this .htaccess file at all.

The other thing to note is that the manner in which these <IfModule php7_module> and <IfModule lsapi_module> blocks have been added at the http://atlantic-computing.com/forums/ level actually overwrote / removed the phpBB-supplied <IfModule mod_version.c> blocks which denied web-based access to your config.php. That seems unintentional, and should be corrected by putting the phpBB-supplied rules back. But ultimately not the explanation of any error.



The main "suspicious" thing to me is just why the PHP 7.3-related path still seems to be cited in the <IfModule php7_module> and <IfModule lsapi_module> blocks when PHP 7.2 has been set as the PHP version. Your hosting provider may end up having some intentional reason for that, but it's something I would ask them about.

The only "clearly wrong" thing is just the missing phpBB-supplied <IfModule mod_version.c> blocks which should be added back to /public_html/forums/.htaccess; but that's not the cause of any current issues.
User avatar
scooterbird
Registered User
Posts: 56
Joined: Tue Jul 07, 2020 8:40 am
Location: Columbia
Name: Steve
Contact:

Re: Topics produce blank pages

Post by scooterbird »

EA117 wrote:
Thu Jul 09, 2020 6:43 pm
In this configuration shown by the .htaccess files you posted, what is showing in the phpBB ACP General tab's "PHP Information" now regarding PHP version? Is it still PHP 7.2.x as was seen earlier (which implies maybe the AddHandler in the root .htaccess is coming into play, even though the HTTPS redirect rule did not), or is it actually showing PHP 7.3.x again now. Just as extra evidence for whether those directives we see in the root-level /public_html/.htaccess are in effect for the /public_html/forums/ folder or not.
Under Core in "PHP Information" in the General tab, the PHP version reads 7.2.31.

My coder is not working today, so I'll handle this myself. For now, I am going to forward the rest of your observations to the hosting company. I have previously asked why the PHP version was changed when it was known to be working under 7.3, but I haven't yet gotten a response. I've also asked for the location of the PHP error log, with no response.

I'm not sure if this is relevant or not, but Bluehost also seems to be doing a great deal of unannounced activity of late. Logging into their CP gives a variety of redirects and other notices which seem to change on a daily-to-weekly basis, and for a period of about 15 minutes yesterday, all access to my account was completely locked out, returning a "Login failed". At the same time, and during that period, their overall status page returned an error. Doesn't exactly inspire a lot of confidence.
THE SCOOTERBIRD

"No bird soars too high if he soars with his own wings."
User avatar
janus_zonstraal
Registered User
Posts: 4799
Joined: Sat Aug 30, 2014 1:30 pm

Re: Topics produce blank pages

Post by janus_zonstraal »

Did you read this
https://my.bluehost.com/hosting/help/562

And https://www.youtube.com/watch?v=FfZ8fzy1ZgU 12min and 50sec (for the error logs)
Sorry! My English is bat ;) !!!
User avatar
scooterbird
Registered User
Posts: 56
Joined: Tue Jul 07, 2020 8:40 am
Location: Columbia
Name: Steve
Contact:

Re: Topics produce blank pages

Post by scooterbird »

janus_zonstraal wrote:
Thu Jul 09, 2020 7:39 pm
Did you read this
https://my.bluehost.com/hosting/help/562
Yes, I have. They are not present.
THE SCOOTERBIRD

"No bird soars too high if he soars with his own wings."
User avatar
janus_zonstraal
Registered User
Posts: 4799
Joined: Sat Aug 30, 2014 1:30 pm

Re: Topics produce blank pages

Post by janus_zonstraal »

Most of the time you can enable the show-error on the page of the php version in cpanel (php options)
Sorry! My English is bat ;) !!!
User avatar
P_I
Registered User
Posts: 1226
Joined: Tue Mar 01, 2011 8:35 pm
Location: Staying home - Calgary
Contact:

Re: Topics produce blank pages

Post by P_I »

I haven't read through the complete topic (yet) so please take the following with a grain of salt.

Bluehost supports a variety of PHP configurations and settings. Their Help article How To Add Handlers To Change PHP Version - PHP Version Setup - Bluehost provides some guidance but is outdated. How To Change Your PHP Version - PHP Config Guide - Bluehost covers the current versions they support on shared hosting plans.

Bottom line, trying to figure out which PHP version can be a bit challenging if you have fiddled around with the .htaccess configuration(s).

For one of my sites hosted there we've got phpBB, MediaWiki and WordPress as part of the site and at various times due to the applications we've had to configure the PHP version in each directory via .htaccess.

Our phpBB 3.3.0 directory .htaccess contains:

Code: Select all

<IfModule mime_module>
  AddHandler application/x-httpd-ea-php73 .php .php7 .phtml
</IfModule>
We've always found the error_log in the applications directory.
Normal people… believe that if it ain’t broke, don’t fix it. Engineers believe that if it ain’t broke, it doesn’t have enough features yet. – Scott Adams
User avatar
P_I
Registered User
Posts: 1226
Joined: Tue Mar 01, 2011 8:35 pm
Location: Staying home - Calgary
Contact:

Re: Topics produce blank pages

Post by P_I »

EA117 wrote:
Thu Jul 09, 2020 6:43 pm
Something I don't have a direct explanation for is why the HTTPS redirect rule shown in this root-level .htaccess wasn't already having an effect on the http://atlantic-computing.com/forums/ path. The rule looks correct to me, and I would have expected this root-level rule to have already been redirecting access attempts to http://atlantic-computing.com/forums/, too. It's as though the way this host has Apache configured, the http://atlantic-computing.com/-level folder rules don't come into play when accessing http://atlantic-computing.com/forums/?
I haven't looked at the specific details in this particular case but Apache HTTP Server Tutorial: .htaccess files might offer a clue when multiple directories contain .htaccess files and how they applied.
The configuration directives found in a .htaccess file are applied to the directory in which the .htaccess file is found, and to all subdirectories thereof. However, it is important to also remember that there may have been .htaccess files in directories higher up. Directives are applied in the order that they are found. Therefore, a .htaccess file in a particular directory may override directives found in .htaccess files found higher up in the directory tree. And those, in turn, may have overridden directives found yet higher up, or in the main server configuration file itself.
Normal people… believe that if it ain’t broke, don’t fix it. Engineers believe that if it ain’t broke, it doesn’t have enough features yet. – Scott Adams
User avatar
scooterbird
Registered User
Posts: 56
Joined: Tue Jul 07, 2020 8:40 am
Location: Columbia
Name: Steve
Contact:

Re: Topics produce blank pages

Post by scooterbird »

Right now, I'm dealing with Bluehost ignoring what I am presenting to them and instead suggesting that I change my administrator account passwords - saying essentially that I've been hacked rather than admit there is something wrong with their PHP. The level of service I'm receiving from them is completely inadequate.

Right now, I have reset PHP for the domain to 7.3 (it's still 7.2 for the server overall, which I have insisted they now change; they are still saying phpBB 3.3.0 will not work with PHP 7.3.x). I've tried a number of configurations with .htaccess, both in /public_html and /public_html/forums. (Right now, they're the same...I've combined .htaccess from Bluehost's utility and the default .htaccess with the phpBB distro, and put it in both locations.) The problems remain the same under what is now (as verified in the General tab) PHP 7.3.19: Forums visible, topics visible, posting works, reply works...but Private Messages returns a blank page, some tabs in ACP intermittently return blank pages, Members from front page returns a blank page, and enabling any extensions at all causes posting and reply to stop working and instead return blank pages.

At the very least, this would indicate that the underlying issue is out of my control. I do know that the forums were running originally under 7.3.6 - enabling 7.3 now gives 7.3.19. I don't know if that has anything to do with it...it shouldn't, but I'm now considering improbable causes.

PHP error log is not available in any of the places described above. The one in cPanel is for Apache server; it does not accrue PHP errors. The only one I have seen with PHP errors is in the domain root and has no errors in it since 2019.
THE SCOOTERBIRD

"No bird soars too high if he soars with his own wings."
Post Reply

Return to “[3.3.x] Support Forum”