I have a weird issue. Laravel 5.2 is prepending \ to every single response which is messing up the responses. JSON data is getting returned as \{"message": ""} instead of {"message": ""} and view responses \<!DOCTYPE html> which is causing the \ to be displayed on the page.
I'm using laravel 5.2 on PHP 5.6.23 (ubuntu server).
Any help is appreciated!
EDIT: This issue is not present on a different server using PHP 5.5.9
EDIT 2: artisian command output are getting prepended with \, example: \Configuration cache cleared!, \Route cache cleared!
`
I'd bet you have accidentally added '\' in some file before <?php or after ?> This happened to me quite some times, always the same result as you. With some luck you can use find in project and search for \<?php and ?>\
Most likely somewhere, in some file or another, you have probably echo'ed / printed a '/' is my guess.
I would start with public/index.php and comment out everything and then hit that file from the browser, and find no output (hopefully).
If no /, slowly uncomment out bits of index.php until you see it pop up again.
Unfortunately, because its such a common character, there is no way to search all to find it.
Related
In a Laravel Nova application i've got a strange issue: Whenever i try to download a file i have a linefeed char on the first line (0A, an empty line). This corrupts images, zip-files and so on. But what is causing this?
I've tried/checked:
Check all php files on closing tags (there are none)
Original file on hdd does not have this extra linefeed when it's created
Checked every php file since last release for correct UTF-8 encoding
Copied composer.lock from live server and installed everything again
Ran composer dump, php artisan cache:clear, php artisan clear-compiled
Checked all code changes since the last release (where there was no issue)
Tried Chrome and Firefox
Here's some Laravel Nova code that produced this error:
return Fields\Image::make(__('Image')), 'imageStorage')
->rules('image', "dimensions:max_width={$image_max_width},max_height={$image_max_height}")
->squared()
->disk(Enums\StorageDisk::APP_PUBLIC_DISTRIBUTORS)
->path(DistributorPath::products($distributorId))
->deletable(false)
->prunable()
->onlyOnForms();
First charachter is always 0A.
So, how do i find the cause? Any tips or strategy?
Short answer: the linebreak was hiding in a routes file.
This mistake was made almost a year ago and never surfaced until now, because it was no issue in any of the output the application created (html / xml). Started to be a problem when I tried to output binary files (zip / images).
So how did i find this bug? die('find bug!');
For anyone in the future:
Start at index.php
Place die('find bug!'); at one place and test.
Don't be afraid to place it in vendor or library code.
No linebreak? Remove die('find bug!'); and place it in the next call.
Found the linebreak? So now you now the linebreak is somewhere inbetween.
Zoom in and find it!
This is a weird one, and something I've never run into before.
I'm deploying to a vvv (Varying Vagrant Vagrants) box from PHPStorm, and the project is a wordpress site.
Frequently, when files are moved over, after reloading the site, I get a PHP parse error, always at the last line of the file. The file isn't necessarily the one I opened and edited, and adding a ?> to the end fixes it. I can then immediately remove the ?> at the end of the file, and all remains well.
This occurs intermittently, making it very difficult to isolate and fix.
An example parse error would be something like:
Parse error: syntax error, unexpected '' (T_ENCAPSED_AND_WHITESPACE), expecting end of file in /srv/www/cpr/public_html/wp-content/plugins/jetpack/3rd-party/class.jetpack-amp-support.php on line 359
The specific parse error changes; it's not always the same thing, but it is always fixed by simply adding a ?>, refreshing, etc.
I keep thinking this has to be something to do with either line endings or encoding, but both seem to be ok. (PHPStorm using LF and UTF-8.
The only part of this workflow that is new to me, is the vvv box, as I've previously used other vendors' vagrant boxes, but I'm not sure how that would cause this.
Is something being appended to these files that's breaking when PHP goes to parse them? Is git or vagrant or PHPStorm's deployment overriding line ending rules and changing them?
I'm at a total loss.
Any help is greatly appreciated. As I roll out larger plugin changes, I'm unable to use the WP api, or do anything else without manually opening all the affected files and adding PHP closing tags, then removing them.
I was able to finally track down the cause of this by isolating the various components.
I ruled out phpStorm and git by migrating some files manually and getting the same error to occur above the app's root, on the vagrant box. This isolated the issue to the vvv box itself, and not the project, PHPStorm, or the deploy settings.
I then setup git to force linux line endings via a .gitattributes file in the repo root, with settings based on things I read in this thread.
Here's what I'm using now:
# Force provisioning script to use LF, even on Windows
* text eol=lf
# Avoid binary files to be corrupted by CRLF conversion
*.png binary
*.gif binary
*.jpg binary
*.jpeg binary
I then used dos2unix and find to recursively fix all the line endings in the project, like so:
find . -name '*.php' |xargs dos2unix
So far - all is well, and persisting. I'll update if this pops back up and needs further revision.
I got a weired behavior on my apache, php setup on debian system.
I tried to create an image with php and output it directly. It failed permanent and the browser said sth. like corrupt image file. After a lot of try and error arroun 3 hours I figured out that there is a TAB character added right at the beginning ob my image content, that does not belong there.
To proove that its part of the apache-php setup I created a test.php file, that just contains the letter 'a' and coppied this file to test.html. So Both files just contain the letter a.
You can see the resulting tab here:
http://www.activeroom.net/test.php
http://www.activeroom.net/test.html
and even on the base url itself - its a php-file, too.
Hope anybody can point me in the correct direction. Btw. on the console everything is fine: php test.php just returns an a. Maybe it is something about the Apache MimeTypes or headers?!
How stupid - there was a php-file prepended through the php.ini. That file had a tab at the end. Sometimes things are really messed up.
I'have instaled codesleeve/asset-pipeline and use command php artisan assets:update
got no errors, but when I load the page an in my chrome developer tools go to Network tab there is jQuery-1.10.2.min.map 404 not found
could please someone tell me if I forgot to do something?
Normally, a minimized source file will be unreadable since all the whitespace & comments are removed. The .min.map file allows the client to "rebuild" the original source for the purposes of browsing & debugging. Thus, if you want/need to debug jQuery, you might want to get that file.
If that file is missing, your application should still work properly. So, the short answer to your question is "no, you didn't forget anything". You can safely ignore that warning.
I'm working with a custom made Joomla script that generates an image from a blob in a database. However, when we moved it from an Apache server to an IIS server, the script is breaking.
Upon investigation, it seems that now, there is a line break that is getting appended before the header function is being run (when I comment out the image portion, and do an echo "test";, test gets printed on line 2 of the source code.
I've gone through the script over and over again, and through the many files in the component, and can't seem to find out where this new line is coming from. At all.
I've tried using ob_start() and many similar functions, but nothing seems to work.
I'm completely out of ideas, and don't know where to turn.
Is there a way to trace what files are being called in the page, perhaps? Any thoughts on further steps?
Look out for additional whitespace at the end of PHP files. If a PHP file ends in more than a single return after the last ?>, that stuff gets printed regardless of where the file is/was included. That is a common error source in larger PHP projects and would meet your symptoms.
(To circumvent this, some have started with a coding standard that prohibits the last ?> in their source files, which is perfectly legal PHP.)
Be careful, maybe it's an encoding problem. Open the file with vim under linux to see if there an ^M or something like that.