XF 1.5 newlines appearing on pages after site move and cache rebuild

[Andrew Matheson]

Hey everyone,

I've recently moved a production site into a test environment to do some enhancements. As part of that move, I changed the boardURL and tried rebuilding the add-on caches. However, after the rebuild completes, the screen is littered with '\n' newlines (See screenshot). I also tried a rebuild from master on the '/install' screen, but no difference.

If I check the templates in the admin UI (/admin.php?appearance/), I can see the '\n's in the code, rather than the proper formatting. On the server, the formatting is also fine (e.g in install/data/*). This leads me to believe something in the rebuild is mis-interpreting something and throwing out the newlines.

In terms of differences between production and test, there are only two: the url (domain.com vs test.domain.com) and the server (centos to ubuntu). I don't see how the server could affect things as both are *nix based and use the same concept of a line ending. I could see it being an issue if one of the two was a Windows server.

There are no errors reported in the server log, and I see no other warnings in any other log.

I feel like I must be missing something obvious with this. I appreciate any guidance you might have to offer.

XF v1.5.10
Ubuntu 16.04
PHP 5.6 (see PHPInfo in attached PDF)
Addons (See attached PDF)

 

[Mike]

It'd potentially be helpful to be able to see the test site directly. There's no CSS either, but I'm not totally clear on what that's returning.

But this really looks like it could be some sort of output filter somewhere. It might be PHP related or it might be somewhere "above" it in the stack.

 

[Andrew Matheson]

Thanks, Mike - I have the site behind a password control so it's not accessible at the moment.

I've done more digging and it seems to be the data is already screwed up in the xf_template table. If I look at the template in DB in the live site, the newlines are displayed normally. I dump the xf_template table and I can see the '\n's in the dump file, properly escaped with a leading '\'. Then I import the table into the new DB and the leading '\' is stripped but the '\n' remains. So now I'm down to my export/import tools, rather than it being XF.

So weird - I've done this hundreds of times and never have I seen this kind of problem with exporting and importing.

 

[Mike]

If possible, I'd recommend the mysqldump/mysql command line tools for export/import. They're the official ones so hopefully there won't be any problems with that.

 

[Andrew Matheson]

Yes, those are the tools I used and they are the ones causing the issue. The other difference is that the production DB is MariaDB 10.1 and the test system is on MySQL 5.7. There is nothing anywhere about the dump/import having this kind of problem between these two (since they are supposed to be compatible), but I've ruled that out by re-importing part of the xf_template table into the live system (renamed the table to xf_template1). So, it is nothing to do with the difference in DB, just something about the dump output and how that is then interpreted during insertion.

 

[Andrew Matheson]

Apologies, I lied... i forgot i made the dump using PHPMyAdmin... I started out with mysqldump, but I needed to exclude some tables, so I used PHPMyAdmin... so perhaps that is the root cause. I'll report back.

 

[Andrew Matheson]

*sigh* yup - that was it. For some reason, PHPMyAdmin was double escaping the newline characters and throwing everything off. Thanks for your input, Mike.

 

[TPerry]

Friends don't let friends use PhpMyAdmin for full DB exports.