Thank you Z-Man, I finally got it working with the new url like I wanted =)

of course I had updated the dns records when I first tried, but I reverted them when it didn't work. I believe the problem in this case was that my site was using caching and I did not clear my cache after changing the url and attempting to reload my site. Once I turned off caching, reset the DNS records appropriately, and updated the url in ossn.config.site.php, everything worked like a charm. Thank you for all your help in the process. (As an aside, the reason I had soulg.ngrok.io and www.soulfulgathering.com pointing to different places is that I use a reverse proxy/tunneling software pkg called nGrok, which requires you to assign a CNAME record when you want to use a custom domain name, but not if you use a subdomain of theirs, i.e. *.ngrok.io)

The original file that caused a problem was a file that I added myself (I was trying to write my own "link preview" component as I couldn't get the one from softlab to work correctly, but I've since abandoned that idea). I've removed it entirely now.

Hi Bansh33,

1. Currently your site appears to be working correctly from here: all images in are place, no more linefeds in the beginning. But it would be helpful if you could tell us which file was involved and what exactly was causing the newline.
2. I had a look into your zipped file: it's physically ok - plain ascii, no BOM

But if I got you right, your site stops working again if you're using that file...

Okay, in the very beginning you wrote: "... I did not touch anything else in the filesystem or database, the only other change I made was to my site"s dns records ..."
To my understanding that is: Everything is still in the place - you only added a new DNS record pointing to the same location. But running nslookup I'm getting:

nslookup soulg.ngrok.io --> 52.14.61.47

and

nslookup www.soulfulgathering.com --> 52.15.194.28

We see: your new url not only resolves to a different IP, even more my browser displays a: "Tunnel www.soulfulgathering.com not found" message.

So - before applying any changes to Ossn - make sure the new url at least points to your Ossn installation and displays a rudimentary skeleton of your community's front page.

sorry, I assumed you might be able to hit that file from your browser and see if the extra byte was being sent - I know you can't view the file source like that. I zipped the file here: http://soulg.ngrok.io/configurations/ossn.config.zip

As I mentioned, I DID find one file that was problematic, but I fixed it (which is why my site at http://soulg.ngrok.io seems to be ok w/ images now)... so I'm not really sure why the same error would happen again when I edit a different file...

Please note that the newline effect appears with utf-8 BOM files INCLUDED from another php file, as I said. Thus simply executing the suspicious file from here won't help. And of course I can't download your php files. If you want me to have a look into that file, please zip it.

nevermind, I GOT IT FIXED!

thanks for all the help, Z-Man, much appreciated.

update: Z-Man, I need to ask your help again. I was able to get my site working with the original url I've been using, which is http://soulg.ngrok.io as I said earlier. I found the offending file and things seemed ok, until I tried to change my site's url again. The only file I changed this time was the config file (other changes were dns related and outside of OSSN). I saved the changes I attempted to make to this file here: http://soulg.ngrok.io/configurations/ossn.config.site.new.php - can you take a look and let me know if you get the 1 byte error on that file? As I said, this time I have changed nothing besides that config file and I had to immediately revert my changes because all the images instantly broke, even stuff like the background image on the login page. Any ideas? I would like to change my site's url but obviously it's causing some problems and I'm not really sure why it's still happening as I fixed the offending file.

Z-man, thanks, I'm still trying to make sense of all of this. I guess I will have to go through all the files and check what I modified recently (besides the url in the config file) that may have unintentionally added a linefeed. I know I kind of already asked this, but if you have any suggestions for how I might be able to avoid looking through the entire directory structure (as there are a lot of files), I'd really appreciate it.

Okay,
next I crosschecked what happens on calling /system/start.php
I got 0 bytes on my community and 1 byte on yours. Thus one of your core files seems to cause the problem. As you see a lot of stuff is getting included here, and you know best which files you modified. :) It may be helpful to add some exits here to narrow down which included file is adding the byte...

Be aware that aside from adding a newline manually at a wrong place the same effect can happen by including a file which has been saved mistakenly as utf-8 WITH BOM. So asure that all your changed files are just utf-8 without BOM, since PHP may replace the BOM signatures by a newline otherwise on including.

@Jason
From the visitors point of view both cases look in fact the same (no images), but in your case you don't get no data at all because of addressing a wrong path. Bansh33 in opposite IS getting back data, but the image files signatures are corrupted because of the additional byte in the beginning.

@bansh33
I just called 2 of your files (COPYRIGHT.txt and ossn.config.site.php) directly, just to make sure your server doesn't add the extra linefeed in general: And no, the server is working correctly. So the issue is caused by the Ossn flow.

wow, that's crazy, THANK YOU Z-MAN, I had no idea an extra linefeed could cause this kind of issue. I don't think I modified anything related to Content-Header code. Is there a simple way anyone knows of that I can track down the origin of this extra linefeed?

Something simple like leaving the end forward slash off the path will cause this. (Just tried it on my site and it did the exact same thing as yours).

P.S. Clear your browser cache.