Plain text whole forum. Latest 3.3

Get help with installation and running phpBB 3.3.x here. Please do not post bug reports, feature requests, or extension related questions here.
Nick_2020
Registered User
Posts: 13
Joined: Wed May 06, 2020 6:26 am

Plain text whole forum. Latest 3.3

Post by Nick_2020 »

Hello gents

Support Request Template
What version of phpBB are you using? phpBB 3.3.0
What is your board's URL? https://dynoinsight.com/phpBB3/
Who do you host your board with? HostDime
How did you install your board? I used the download package from phpBB.com
What is the most recent action performed on your board? Update from a previous version of phpBB3
Is registration required to reproduce this issue? No
Do you have any MODs installed? No
Do you have any extensions installed? No
What version of phpBB3 did you update from? phpBB 3.0-B1
What styles do you currently have installed? prosilver only
What language(s) is your board currently using? English british
Which database type/version are you using? MS SQL Server
What is your level of experience? New to PHP and phpBB
What actions did you take (updating your board; installing a MOD, style or extension; etc.) prior to this problem becoming noticeable? This was noticeable in v3.0 also. Not it became worse, possibly because of increased traffic.
Please describe your problem. I often get a plain text view of the whole board. A white background with bullets. Mostly after I login or log out. It is random. Sometimes it works fine for hours. Sometimes I can not use it at all
Generated by SRT Generator

I have updated from 3.0 to 3.3 two weeks ago using the current download. No extensions not mods. All is the default from the installation package.

The problem: Often when I login or logout I get a plain text view of the whole board. See the attachment. Sometimes it works if I reopen browser or wait.
It seams to be random. And looks performance-related to my uneducated view. Our traffic has significantly increased lately.

This was happening in v3.0 also and was the main reason for updating.

I have searched similar threads but the main point I got out was: It is a server problem. So I have contacted today my HostDime. They have great support. This is what they have answered:

"
We've looked through your sites error logs and found that the following PHP Warning noted below is being supplied by the interpreter. What this warning is informing you of is that PHP is unable to properly change the headers for your site, which may be causing the issue that you are running into. This error can commonly result in the improper status codes and headers being applied to your PHP files including the CSS, which would manifest as the issue that you are encountering.

PHP Warning
[20-May-2020 04:11:48 UTC] PHP Warning: Cannot modify header information - headers already sent by (output started at C:\Inetpub\vhosts\thesite.com\httpdocs\phpBB3\vendor\symfony\http-foundation\Response.php:361) in C:\Inetpub\vhosts\thesite.com\httpdocs\phpBB3\includes\functions.php on line 1937
[20-May-2020 04:12:01 UTC] PHP Warning: Cannot modify header information - headers already sent by (output started at C:\Inetpub\vhosts\thesite.com\httpdocs\phpBB3\vendor\symfony\http-foundation\Response.php:361) in C:\Inetpub\vhosts\thesite.com\httpdocs\phpBB3\includes\functions.php on line 1937
[20-May-2020 04:20:42 UTC] PHP Warning: Cannot modify header information - headers already sent by (output started at C:\Inetpub\vhosts\thesite.com\httpdocs\phpBB3\vendor\symfony\http-foundation\Response.php:361) in C:\Inetpub\vhosts\thesite.com\httpdocs\phpBB3\includes\functions.php on line 1937

From what we were able to find, this is being caused by the following file having its "sendContent" function being used prematurely, before phpBB is able to properly send its status line:
[ROOT]\phpBB3\vendor\symfony\http-foundation\Response.php

If you would like, we can continue to look into this to further confirm this and attempt to affect a solution, however this would require the usage of on-demand support time (at least 30 minutes, but far more likely up to 1-2 hours) and we can also provide no guarantees whatsoever that we will be able to resolve this in the first place. As such, we strongly recommend that you instead reach out to the phpBB team either directly or on their forum as they would be far better able to provide assistance in this matter.

Furthermore, we recommend that you peruse the following StackOverflow response, as it quite clearly explains this warning and some possible resolutions:
https://stackoverflow.com/questions/802 ... ror-in-php
"

I am clueless with php so the stack overflow thread is not much help for me.

I would greatly appreciate any suggestions
Nick
Attachments
ForumBad.jpg

User avatar
david63
Registered User
Posts: 17755
Joined: Thu Dec 19, 2002 8:08 am
Location: Lancashire, UK
Contact:

Re: Plain text whole forum. Latest 3.3

Post by david63 »

There are no problems at the moment with your board loading correctly.

The image that you have posted shows that the css has not been rendered. This may be a browser issue (have you tried another browser?) or it could be server related (not having enough available resources)
David
Remember: You only know what you know and - you don't know what you don't know!
My CDB Contributions | How to install an extension
I will not be accepting translations for any of my extensions in Github - please post any translations in the appropriate topic.
No support requests via PM or email as they will be ignored

Nick_2020
Registered User
Posts: 13
Joined: Wed May 06, 2020 6:26 am

Re: Plain text whole forum. Latest 3.3

Post by Nick_2020 »

Thank you, David

I have sent you a pm with credentials. Please share them with anybody who needs it. Could you repeat the test with login in please? It just happened for me after log out (happens nearly always). Every third time I get plain text after login. Sometimes it happens without login just by clicking the forum link or clicking links on the first page.

It would not be good if phpBB did not work with the latest Microsoft Edge. I had this issue with the previous version of Edge also on a different PC for years.

As per server issue: The answer from HostDime looks like pretty good info. It looks like there is an old tricky bug in phpBB and some developer needs to look at the stack and what they are writing.

I have disabled all spam counter measures so it is a minute to register. Or ask me for credentials.

This bug is still there because it is not so easy to reproduce. It might also be dependent on time of the day. Working hours in US are the heaviest

Let's fix it, gents
Thank you

Nick_2020
Registered User
Posts: 13
Joined: Wed May 06, 2020 6:26 am

Re: Plain text whole forum. Latest 3.3

Post by Nick_2020 »

Might help with reproducing: It looks like it is happening more often if I leave one forum open and open another one or more instances of it in new tabs or another browser instance

User avatar
EA117
Registered User
Posts: 1601
Joined: Wed Aug 15, 2018 3:23 am
Contact:

Re: Plain text whole forum. Latest 3.3

Post by EA117 »

For what it's worth, the site loaded fine for me on my very first visit, same as it did for David. Chrome 81.0.4044.138 on Windows.

So I opened the F12 Network view to do a refresh, and my very first refresh showed the failure you described.

What the F12 Network view showed was that all the links for board assets (phpBB Javascript, style-based stylesheets, phpBB fonts) all failed because the server returned HTTP 404 for those assets.

But the reason the server correctly returned HTTP 404 is because all the requests were for the wrong path. The page had been rendered to include these assets from a phpBB root path of https://dynoinsight.com/, instead of from a phpBB root path of https://dynoinsight.com/phpBB3/.

Normally this path is taken from the inbound request. i.e. When the GET request for index.php arrives, the URL in that request shows a specific host and a specific path for the GET request of index.php. And phpBB "repeats those back to you" as the base path for any URLs that needs to be written for the page being rendered.

Seeing this path "wrong" implies "it's as though by the time phpBB received the request for index.php, it had been re-written to be https://dynoinsight.com/index.php instead of https://dynoinsight.com/phpBB3/index.php as expected."

Without knowing the reason that's happening, a workaround does exist which might help in the short-term for making the site more reliable. In the phpBB ACP Server Settings section, set "Force server URL settings:" to "Yes", set "Server protocol:" to "https://", set "Domain name:" to "dynoinsight.com" (or to "www.dynoinsight.com" if that's your preference, since your site and your cookies currently allow for both), set "Server port:" to just a blank value, and set "Script path:" to "/phpBB3" (the upper-case letters are important here).

The intention of those workaround settings is to force phpBB to declare "it doesn't matter what path appears to be in the incoming GET request, I'm going to always write any links using https://dynoinsight.com/phpBB3/ regardless." Changing this setting probably doesn't already flush the cache, so perhaps go ahead and use the phpBB ACP General tab's "Purge cache" button too, after making the change.

That still leaves unresolved "why is this behavior appearing to be variable within your server hosting environment." Maybe your hosting support would have an informed opinion on that aspect, too.

wrongpath.png


Nick_2020 wrote: ↑
Wed May 20, 2020 10:15 am
[20-May-2020 04:11:48 UTC] PHP Warning: Cannot modify header information - headers already sent by (output started at C:\Inetpub\vhosts\thesite.com\httpdocs\phpBB3\vendor\symfony\http-foundation\Response.php:361) in C:\Inetpub\vhosts\thesite.com\httpdocs\phpBB3\includes\functions.php on line 1937
Without a call stack of what led up to this warning, it's hard to say what phpBB might have been in the middle of. The functions.php 1937 line reference does happen to be a special case where phpBB says "we're using a CGI-based PHP SAPI, and the PHP implementation should have already set this status code for us, but we've seen some CGI-based implementations which don't go that, and so we're going to attempt setting that header ourselves."

But yes, it happened at a moment in time where content had already started being output, and so "let's add some more headers" was no longer an option. Hence the warning. One typical scenario in which such a situation occurs is when an error is detected after output has already started, but the error handler tries to report the error as though he's the first output. But again, without a call stack, we have no idea if that's actually the case here.

Maybe your hosting provider would have additional information on that too, and either could modify the PHP configuration to more verbosely log these warnings with an included call stack, or tell you how control of that configuration is already available to you in your hosting control panel or similar.

User avatar
david63
Registered User
Posts: 17755
Joined: Thu Dec 19, 2002 8:08 am
Location: Lancashire, UK
Contact:

Re: Plain text whole forum. Latest 3.3

Post by david63 »

I tried to access your board earlier this morning and was getting the css not rendered.

I have tried again just now and all is fine. Same PC, same browser. This would lead me to suspect that it is a server problem.

The login details you sent via PM do not work.
David
Remember: You only know what you know and - you don't know what you don't know!
My CDB Contributions | How to install an extension
I will not be accepting translations for any of my extensions in Github - please post any translations in the appropriate topic.
No support requests via PM or email as they will be ignored

Nick_2020
Registered User
Posts: 13
Joined: Wed May 06, 2020 6:26 am

Re: Plain text whole forum. Latest 3.3

Post by Nick_2020 »

Thank you, EA117
That is great (again) info.

I have asked my host (HostDime) support to read this. The technician had nothing to add and suggested to go ahead.
So I have made the changes, purged the cache and, sorry to say, the problem is still there :( .

I have rebooted, pressed ctrl+F5 hard. Right now after logging in if I click 'Board index' link I get the hated plain text screen.

I suspect there could be issues with the host or my ISP, but it is probably a common problem, judging by the few unresolved threads about this and the number of views of this thread. If it is a server issue, the board should have given a warning or handled it.

Not sure how much this worth, but I wanted to suggest in any case:

When we get a problem we cannot reproduce or debug, we compile a special debugging version which logs in a number of key places steps executed OK, with minimal info. We send this to the customer and ask to reproduce and send the log back.

It might take a number of iterations, but in my experience it converges very quickly. After two or three iterations I had the stack and the reason was clear.

I would be happy to do whatever is needed. When there is a reproduceable case it is an opportunity to catch a tricky problem

Also:
It might be good to add somewhere a quick check that the path is valid (exists on the disk). I guess a checked path should be in memory already. This would not affect performance. This is what we often do: Quick check>not so quick check>deeper analysis>Log>notify user>Try to recover. When checks fail performance does not matter anymore. I the case recovering could mean checking parent folder for config.php or searching subfolders.

Another thing:
I think randomness often comes from synchronization problems if there some concurrent execution. It is so to forget that a value can be different for another thread

Regards
Nick

User avatar
EA117
Registered User
Posts: 1601
Joined: Wed Aug 15, 2018 3:23 am
Contact:

Re: Plain text whole forum. Latest 3.3

Post by EA117 »

The observation that the path used for the assets was still "variable" for you even after setting "Force server URL settings: Yes" made me realize there must be more going on there that I understood. And indeed, although generate_board_url() is involved in the calculation (and is the function whose output is now non-variable once "Force server URL settings: Yes" is set), for a normal page view that's not the path that ultimately gets used for these assets like stylesheet.css.

Instead path_helper::get_web_root_path() is calculating a relative path, effectively "always based on the path received in the request." So I was wrong, and setting "Force server URL settings: Yes" does not potentially mitigate behavior in the short term, against the still-unknown root cause of why the path is variable at all when "simply refreshing the same page."

The biggest unknown for me is the involvement of IIS here, and whether there is something in the PHP installation, or the web.config configuration which could be the root cause of why this request path appears to somehow vary. I see the open issue https://tracker.phpbb.com/browse/PHPBB3-15168 hits a couple of related notes, but ultimately doesn't seem to have an obvious explanation for "variable" behavior.

I certainly agree that there have been other "I get a plain text site because the CSS didn't load" issues reported. But "because the generated path was wrong" doesn't immediately resonate as the reason being investigated. More like "I found my web server is blocking access to those files", or "the files truly didn't exist", etc. If you had been seeing a "plain text site" discussion where this specific "the path is wrong for those assets" was being pursued, if you can link to that I would be interested to take a look at what they were investigating, too.


The behavior your site is showing indicates this web root path is sometimes calculated as "./../.." in the failure cases, instead of simply "." like in the success cases. As though the request passed in to PHP from the web server had been for a path like /phpBB3/app.php/route/name/ instead of just /phpBB3/viewtopic.php or /phpBB3/index.php as expected.

I don't know the smart way to debug that... I just know the way I would use. 😜 Putting something like the following lines right before the garbage_collection() call at the end of page_footer() in /includes/functions.php would reveal some request info for both successfully rendered pages and also in the plain-text failure case:

Code: Select all

echo '<br><pre>' . htmlspecialchars_decode($request->server('REQUEST_URI')) . '</pre><br>';
Depending on the type of page being presented, you might find this output at the end of the page, or as the very first thing at the top of the page. But it's just going to be a basic confirmation of the URI that the request is considered to be for, such as "/phpBB3/" or "/phpBB3/index.php", etc. And the question is "did anything about that change", between the successfully-rendered page and a failed refresh of that same page.

If you can do it while the site isn't publicly accessible, I would actually just dump the entire request structure looking for clues. But there is a lot of information disclosure there, and probably not something you want on publicly visible pages while you're debugging:

Code: Select all

	echo '<br><pre>';
	var_dump( $request );
	echo '</pre><br>';
My gut feeling is that you're looking for clues that are going to lead you back towards IIS and path handling that was done prior to the request being handed down to PHP. But I've been wrong as recently as "at the beginning of this very post." 😁


If none of that sounds like something you want to chase, or want some better information for chasing it, if you don't get any additional input here in this discussion, you might want to just go ahead and create your own bug against this "randomly wrong phpBB web root path calculation on our IIS server" in the tracker, to see what conclusions might be reached there.

Nick_2020
Registered User
Posts: 13
Joined: Wed May 06, 2020 6:26 am

Re: Plain text whole forum. Latest 3.3

Post by Nick_2020 »

Thank you for the valuable advice.

I might do it myself eventually if I do not get any other help.

One question: Would it work if I just copy whole phpBB3 folder side by side into something like phpBB3debug to mess with your suggestions? I mean do two side by site installations work?

Nick_2020
Registered User
Posts: 13
Joined: Wed May 06, 2020 6:26 am

Re: Plain text whole forum. Latest 3.3

Post by Nick_2020 »

Just in case for other looking into the same problem: I believe at currently there are exactly three other topics about this:
viewtopic.php?t=1637015
viewtopic.php?t=2149405
viewtopic.php?t=2125787

User avatar
3Di
Former Team Member
Posts: 15415
Joined: Mon Apr 04, 2005 11:09 pm
Location: Milan (IT) Frankfurt (DE)
Name: Marco
Contact:

Re: Plain text whole forum. Latest 3.3

Post by 3Di »

Are you still in troubles or what?
Please PM me only to request paid works. Thx.
Want to compensate me for my interest? Donate
My development's activity º PhpStorm's proud user
Extensions, Scripts, MOD porting, Update/Upgrades
:studio_microphone: Premium extensions @ The Studio

Nick_2020
Registered User
Posts: 13
Joined: Wed May 06, 2020 6:26 am

Re: Plain text whole forum. Latest 3.3

Post by Nick_2020 »

Thank you for asking, 3Di
I might get back to you a bit later.

This was a break to try on-demand support from my host. I have a thread there also and they are checking this one as well.
Their answer was:
After sifting around through the database for your installation, I was able to address the issue by modifying the site's URL via the database. The "site_home_url" key in the under `nikdi_2013`.`phpbb_config` table has been changed from "https://dynoinsight.com" to "https://dynoinsight.com/phpBB3/".

This appears to have caused the forum to now load the scripts from the correct location. While going through the database, there also appeared to be a "script_path" option, which did not seem to have any overall effect on the page when modified. This was likely what determined where scripts were loaded from before but may have changed in recent versions of phpBB, could be a result of a bug, or is simply utilized an a location of the forum that is not-so-obvious. As I was unable to determine the consequences of modifying the variable, I have opted to leave it at its value of "/phpBB3".

As I unable to 100% determine the consequences of modifying the variable, it is doubtful that anything more than 404 errors in some obscure locations would occur. I do, however, recommend you continue to remain in contact in the phpBB forums to receive further guidance in regards to the modification to ensure that this does not need to be updated in any additional locations, or to determine if there is a better way to do this using the script_path option instead.
In the morning the forum looked nearly fine. Definitely better. I decided to wait a bit to see if stays that way. I was googling a lot with many tabs open. Then decided to look why favicon disappeared. The only thing I found to do was to purge the cache. This staffed the forum completely. Plain text and I could not get it going. Rebooting helped. Now all looks good again and I am scared to touch it.

To me it looks like it is a performance issue happening when you come back to it after heavy browsing. I think it should be OK for me. As the main issue is to stop it happening for majority of our users, which normally do only quick look. So, I will leave it for now until it become intolerable again.

For now it remains a mystery

Thank you all for your help

User avatar
3Di
Former Team Member
Posts: 15415
Joined: Mon Apr 04, 2005 11:09 pm
Location: Milan (IT) Frankfurt (DE)
Name: Marco
Contact:

Re: Plain text whole forum. Latest 3.3

Post by 3Di »

To me it seems your installation is not looking at the right folder when it comes to assets

That's now https://dynoinsight.com/assets/ instead of https://dynoinsight.com/phpBB3/assets/.

Thus all of those 404s
2020-05-26 07_27_19-Strumenti di sviluppo - DInsight - Index page - https___dynoinsight.com_phpBB3_.png

which means File or directory not found.


2020-05-26 07_32_13-Strumenti di sviluppo - DInsight - Index page - https___dynoinsight.com_phpBB3_.png
2020-05-26 07_32_13-Strumenti di sviluppo - DInsight - Index page - https___dynoinsight.com_phpBB3_.png (8.08 KiB) Viewed 69 times
Nick_2020 wrote: ↑
Tue May 26, 2020 3:23 am
After sifting around through the database for your installation, I was able to address the issue by modifying the site's URL via the database. The "site_home_url" key in the under `nikdi_2013`.`phpbb_config` table has been changed from "https://dynoinsight.com" to "https://dynoinsight.com/phpBB3/".
That's wrong, site_home_url it was correct to be https://dynoinsight.com or nothing at all, depends on your ACP settings for breadcrumbs.
Nick_2020 wrote: ↑
Tue May 26, 2020 3:23 am
This appears to have caused the forum to now load the scripts from the correct location. While going through the database, there also appeared to be a "script_path" option, which did not seem to have any overall effect on the page when modified. This was likely what determined where scripts were loaded from before but may have changed in recent versions of phpBB, could be a result of a bug, or is simply utilized an a location of the forum that is not-so-obvious. As I was unable to determine the consequences of modifying the variable, I have opted to leave it at its value of "/phpBB3".
script_path should be /phpBB3/ notice the appended slash "/".

More than that make sure all of your files are correctly located in https://dynoinsight.com/phpBB3/
and there are not .htaccess rules or redirects which can cause conflicts.

Btw the favicon is correctly loaded. HTTP 200.
Please PM me only to request paid works. Thx.
Want to compensate me for my interest? Donate
My development's activity º PhpStorm's proud user
Extensions, Scripts, MOD porting, Update/Upgrades
:studio_microphone: Premium extensions @ The Studio

User avatar
EA117
Registered User
Posts: 1601
Joined: Wed Aug 15, 2018 3:23 am
Contact:

Re: Plain text whole forum. Latest 3.3

Post by EA117 »

Nick_2020 wrote: ↑
Tue May 26, 2020 3:23 am
The "site_home_url" key in the under `nikdi_2013`.`phpbb_config` table has been changed from "https://dynoinsight.com" to "https://dynoinsight.com/phpBB3/".
...
While going through the database, there also appeared to be a "script_path" option, which did not seem to have any overall effect on the page when modified.
Agreed that "site_home_url" exists, but it's just what causes the "DInsight home" link to go to a different URL of your choosing instead of just having "Board Index" which goes to index.php. That value isn't involved in how stylesheet or other links are generated.

The "script_path" is what's being set by the values you had put under "Force server URL settings: Yes", which do intend to have an effect on how links are generated, but as clarified earlier actually does not affect specifically the "web root" path used for generating the stylesheet links in the case of index.php and other "normal" pages being displayed.

So while they definitely looked in the database for "intuitively relevant things", I don't think they addressed anything or tested anything we weren't already testing.

And indeed, the problem still happens for me as easily and in the same way as it happened before.

Nick_2020 wrote: ↑
Mon May 25, 2020 5:48 am
One question: Would it work if I just copy whole phpBB3 folder side by side into something like phpBB3debug to mess with your suggestions? I mean do two side by site installations work?
I would only be comfortable doing that if I also duplicated my database. i.e. Make a backup of your current database tables, then change the backup so the table names have unique prefixes like "phpbbdebug_" instead of "phpbb_", and then re-import the backup so that now you have an independent set of tables unrelated to the production site. And then in the copy of your site you put into a /phpBB3debug folder, change the config.php there to reference the "phpbbdebug_" table prefix instead of the production site's "phpbb_" prefix. That way you truly have two independent sites, despite running in separate folders of the same domain.

Maybe 3Di has an even smarter solution, but if you were willing just test with .php file changes on the production site, perhaps we could wrap that logging in a "only if founder account" conditional or similar, so that it's not appearing except for you.

Nick_2020 wrote: ↑
Mon May 25, 2020 5:50 am
Just in case for other looking into the same problem: I believe at currently there are exactly three other topics about this...
Understood. Yes, those referenced "plain text", but I think you'll also find there are others which simply say their style isn't showing or similar, without keywords "plain text". Regardless, reviewing the three listed confirmed none of them were specifically chasing a "the stylesheet doesn't load because the path rendered by phpBB is wrong." So nothing to help us in this case.

3Di wrote: ↑
Tue May 26, 2020 5:40 am
To me it seems your installation is not looking at the right folder when it comes to assets

That's now https://dynoinsight.com/assets/ instead of https://dynoinsight.com/phpBB3/assets/.
You're correct, although the issue is that this only happens conditionally, not "every time." A page will load correctly and pull it's assets from https://dynoinsight.com/phpBB3/assets/ as expected. But then simply an F5 refresh of that same page can either correctly display again, or will fail because suddenly the assets path is now https://dynoinsight.com/assets/. Even though we were loading the exact same page from the exact same path.

3Di wrote: ↑
Tue May 26, 2020 5:40 am
script_path should be /phpBB3/ notice the appended slash "/".
Agree this won't hurt, but generate_board_url() pulls that trailing slash off if its provided.

3Di wrote: ↑
Tue May 26, 2020 5:40 am
More than that make sure all of your files are correctly located in https://dynoinsight.com/phpBB3/
and there are not .htaccess rules or redirects which can cause conflicts.
Also agreed, although it's IIS configuration in play here rather than .htaccess, and wondering if it's involved in why there is a variable outcome.

User avatar
3Di
Former Team Member
Posts: 15415
Joined: Mon Apr 04, 2005 11:09 pm
Location: Milan (IT) Frankfurt (DE)
Name: Marco
Contact:

Re: Plain text whole forum. Latest 3.3

Post by 3Di »

It is always the same here no matter how many time I do refresh that page, it is just plain text.
My browser's inspection tool (FF) has the cache disabled as per default if that matters.

Being a IIS configuration - as I can see ofcourse - it should have in its phpBB3 folder the file web.config
which should superseed the .htaccess one, not a big expert of IIS here though.

Curios to see a screenshot of the FTP side of things here.
Please PM me only to request paid works. Thx.
Want to compensate me for my interest? Donate
My development's activity º PhpStorm's proud user
Extensions, Scripts, MOD porting, Update/Upgrades
:studio_microphone: Premium extensions @ The Studio

Post Reply

Return to “[3.3.x] Support Forum”