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.
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!
There is a compiler.assign.php plugin in Smarty 2.6.19. Its contents can be looked here: http://smarty-php.googlecode.com/svn/branches/Smarty2Dev/libs/plugins/compiler.assign.php
Sometimes PHP halts on the line where this file is included. No errors thrown. But if I make any change in the file (i.e. add a character in a commented line), it starts working. If I remove added text, it halts again.
Halting can be reproduced only when file contents are original. If I add one character in one place and remove one in another, the script will work, despite its size is the same as original.
Restarting Apache helps. So this is an Apache+PHP problem.
I was adding and removing characters in the comments only, so they couldn't affect PHP. I am confused very much by this weird problem.
The problem occurs under Apache 2.2.24, PHP 5.3.23 and Linux 2.6.18. Didn't check another environments.
I am working on Wordpress.
After upload my project file in the live server and then for any certain changes, I found everything inside "styles.css" files comes into only one line.
Even what ever inside the "header.php" or "footer.php" also comes into only one line.
Then its become hardest to search any particular keyword.
Can anybody please suggest me, how do I prevent this kinda editing in the server?
I am using "NetBean 7" as the editor.
Your server has converted your file types to match the server's file system it sounds like. Your line breaks might be gone. Try opening them in Notepad++ or vim to be sure.
If you look at it in Windows under Wordpad it should work too.
All of a sudden, my SMF powered forum has stopped working.
In fact, PHP files no longer seem to want to open on my website. I tried uploading a blank PHP file with just a few characters of text, and it refuses to open giving the error below.
I also tried a PHPinfo file, which didnt work, giving the same error. Other sites on the same server are working.
Fatal error: Unknown: Failed opening required '/home/users/a/n/mysite/www/index1.php' (include_path='.') in Unknown on line 0
Any ideas about whats gone wrong?
Just an idea. As it happens to all php files that could to what i know only mean 2 things.
Either there is somekind of error on the php extension.
OR what it most likely is, is that SMF uses a .htaccess to make user friendly links. Which means all requests to the server no matter what (Unless specified in the .htaccess) will be sent to index.php and then be handled.
So if there is a error in the index.php or the library of some sort it would explain why no matter what php file you're looking at it gives the error.
-
One thing you could do is to take a backup of all your images in the system. Then try to install a fresh version on your local machine. Once done copy/past the images back and copy all the current php files for SMF and replace the current ones on your host with them.
-
Haven't used SMF much so I'm not sure this is the solution at all. But to me it sounds like a solution.
It seems you have broken your root document.
do chmod 755 index1.php
and it should solve the problem.
You should check the php.ini or php5.ini file. I don't believe the single ticks around '.' for the include_path are valid. Double quotes will work however.
It seems you have been hacked:
http://wordpress.org/support/topic/fatal-error-unknown-failed-opening-required-google_verifyphp
Ahh sorry reread the question. I guess this is what you may try.
Check your file permissions. by default if your web server can not read files thats what you are going to get. I could be wrong but worth having a look
so just chmod your root folder to say 755 atleast
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.