Bug #74339 [Com]: BOGUS: Fatal error: strict_types declaration must be the very first statement

From: Date: Sat, 19 Jan 2019 17:50:54 +0000
Subject: Bug #74339 [Com]: BOGUS: Fatal error: strict_types declaration must be the very first statement
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-219090@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=74339&edit=1 ID: 74339 Comment by: spam2 at rhsoft dot net Reported by: spam2 at rhsoft dot net Summary: BOGUS: Fatal error: strict_types declaration must be the very first statement Status: Not a bug Type: Bug Package: Scripting Engine problem Operating System: Linux PHP Version: 7.1.3 Block user comment: N Private report: N New Comment: all the workarounds are fine but the first php staement is after <?php no matter how many shebangs and BOM are before and when i read something like "You shouldn't have CLI scripts within your webroot in the first place" i just get upset since the whole purpose of if(PHP_SAPI === 'cli') is to write proper software which bheaves corretly in CLI as well as in web-mode (require a web-login versus just do the job as example) Previous Comments: ------------------------------------------------------------------------ [2019-01-18 16:36:17] stefansobick at gmx dot de Convert the file to utf without BOM, than it should work fine, when you have done it like this: <?php declare(strict_types=1); ?> <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Page title</title> </head> <body> ... ------------------------------------------------------------------------ [2017-04-07 13:14:12] spam2 at rhsoft dot net > You shouldn't have CLI scripts within your webroot in the first place ... really? #!/usr/bin/php <?php declare(strict_types=1); switch(PHP_SAPI} { case 'cli': break; default: break; } ...shared..code.... ?> i have ton of examples where this works pretty fine by intention while in cron mode the only output are errors and when runnigng in the browser authenticated against the CMS you get runtime informations maybe i am the only guy on this planet which is using PHP and cli heavily for a decade and write any code so that it is 100% cli capable including the whole CMS bootstrap but that don't change the fact that "You shouldn't have CLI scripts within your webroot" is nonsense and frankly on shared hosting you have usually no way to run CLI or palce something outside the webroot at all and so you need to make sure that these tasks can be called via web and be it that your conjob running somewhere else running curl('https://url/cron.php?username=bla&pwd=bla'); and you break that all for no reason with claim "declare(strict_types=1)" is not the first line while IT IS and even bobody would care about "#!/usr/bin/php" in the output when called via websevrer #!/usr/bin/php <?php declare(strict_types=1); ------------------------------------------------------------------------ [2017-04-07 12:18:49] narf at devilix dot net You shouldn't have CLI scripts within your webroot in the first place ... ------------------------------------------------------------------------ [2017-04-02 11:15:16] spam2 at rhsoft dot net than at least ignore shebangs also with mod_php #!/usr/bin/php <?php declare(strict_types=1); if(PHP_SAPI != 'cli') { exit('CLI ONLY'); } ?> is also broken when called via browser which leads to fatal erros and so flood logs which is bad in case of emial reporting every 30 minutes when any of some hundret vhsost triggers any php-warning/error ------------------------------------------------------------------------ [2017-03-30 12:01:31] daverandom@php.net Shebangs are explicitly ignored. Everything else that appears outside PHP tags is considered to be script output. This is the way that PHP has always worked. To make your code work, do this: <?php declare(strict_types=1); ?> <html> <head><title>Test</title></head> <body> <?php // code here ?> </body> </html> ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=74339 -- Edit this bug report at https://bugs.php.net/bug.php?id=74339&edit=1

« previous php.bugs (#219090) next »