I have a working symfony project. I have it on a private bitbucked repository and locally the website works without an issue.
Today I tried to deploy the project onto an external server linuxpl.com.
Steps taken include:
Istalling composer
Adding the mysql database
Running git clone to get the data into a proper location
Running composer install on the folder to install everything and connect to the db
Cleared the cache
Set the project root as ....domain/project_name/web
However after completing all these steps, when running the website with regular server:run I'm getting this odd error:
Parse error: syntax error, unexpected '.' in /home/spirifer/domains/surowcewobiektywie.pl/konkurs/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1571
Not sure if this is of any importance but the mentioned code partion looks like this in my local files:
// Some objects throw exceptions when they have __call, and the method we try
// to call is not supported. If ignoreStrictCheck is true, we should return null.
try {
$ret = $object->$method(...$arguments);
} catch (BadMethodCallException $e) {
if ($call && ($ignoreStrictCheck || !$env->isStrictVariables())) {
return;
}
throw $e;
}
The local version does not differ from the one on the server.
My local machine has PHP 7.0.9 and the remove server has PHP 7.0.14
How could I fix this issue?
PHP 5.6 adds Variadic functions, with "...". However, Twig v1.x only required the use of PHP 5.2.7 or above.
If you didn't explicitly update to Twig 2.0, it's very possible you have used the 'death star' version constraint in the composer file - '*'. which allows uncontrolled version updates to the latest version. If this is the case, you will need to either update your version of PHP, or at least require just a previous version of Twig/twig, "^1.32" would be the latest in the version 1 series of Twig.
I'm using CakePHP 1.3.16 with PHP 5.4.6. The new PHP version caused a few deprecated warnings with old 1.3 CakePHP applications, which were fixed by updating to the 1.3.16 version. Unfortunately, I'm still getting deprecated warnings when using the console, which is quite annoying, and I can't find the place to turn them off. Here's what I tried:
I checked the error reporting in the php.ini files, in both /etc/php5/cli/php.ini (which should be used by command line php scripts) and /etc/php5/apache2/php.ini: in both cases it says error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT.
I modified all lines saying error_reporting($reporting) in the /cake/libs/configure.php to say error_reporting(E_ALL & ~E_DEPRECATED & ~E_STRICT).
I ran a recursive search for 'error_reporting' in the cake directory. Whenever it showed up, deprecated warnings were switched off by default. Still, I am getting them on the console.
Did anyone else run into this problem?
For cakephp 3.* just set the following value in your config/app.php file:
// in config/app.php
'Error' => [
'errorLevel' => E_ALL ^ E_DEPRECATED ^ E_USER_DEPRECATED,
]
In app/Config/core.php change debug mode to 0:
Configure::write('debug', 0);
I am pretty new to Symfony 2 and brand new to Gearman.
I am looking for a bundle to integrate Symfony 2 with Gearman.
mmoreramerino's bundle seems to be the most popular bundle according to packagist. Unfortunately something seems to be broken, the autoloader does not find the bundle.
Fatal error: Class 'Mmoreramerino\GearmanBundle\MmoreramerinoGearmanBundle' not found in ...
I tried switching to "dev-development" as I got from the issues that it was fixed in this branch, but it did not work for me as well.
Question: How can I install this bundle using Symfony 2.1.x?
Question 2: Are there any working & documented alternatives?
Edit In case someone else comes across this question: Here is how I got it up and running!
Install gearman, libgearman, the PECL extension for PHP (use recent versions!)
check that gearman shows up in phpinfo() (both cli and webserver version)
start gearmand in terminal 1 using "gearmand --verbose INFO" (you will see workers & clients connect to gearman - or not ;-))
start in terminal 2 reverse_worker.php from the gearman php extension example directory
start in terminal 3 reverse_client.php from the gearman php extension example directory
If this is working, you are ready for Symfony: install mmoreramerino/GearmanBundle using "dev-development"
copy dev.base.yml from the bundle to app/config/gearman/dev.yml
Now add TestWorker.php to your bundle as outlined in the documentation
enable the testWorker by using the console script "php app/console gearman:job:execute MmoreramerinoGearmanBundleWorkerstestWorker~test"
now you are able to send jobs to the listening testWorker in a Symfony controller (or somewhere else in Symfony). I had to specify the server though I am using the default host/port.
$gearman = $this->get('gearman');
$gearman->setServer('127.0.0.1',4730);
$gearman->doNormalJob('MmoreramerinoGearmanBundleWorkerstestWorker~test');
To install the bundle, you need to add the following line to composer.json
"Mmoreramerino/GearmanBundle": "dev-development"
and run composer update;
Then register it in app/AppKernel.php (it seems you have already done this)
new Mmoreramerino\GearmanBundle\MmoreramerinoGearmanBundle(),
I've been trying to remove the E_NOTICE and E_STRICT error levels to avoid this error:
Runtime Notice: Only variables should be passed by reference
I tried modifying php.ini but didn't work, error_reporting always is -1. Then I tried setting it dynamically in the current action, and worked fine. Then I also tried the same in the first line in app_dev.php and didn't work. Which means Symfony2 is setting it dynamically somewhere.
What should I do?
EDIT
For those who are not familiar with the error:
$user = $this->('security.context')->getToken()->getUser();
$first = reset($user->getRoles()); // error
$roles = $user->getRoles();
$first = reset($roles); // works fine
Whilst the notice is not 'retarded', this is a reasonable question in other contexts so: this is set in the Kernel instance, instantiated in app_dev.php (or app.php).
The second parameter to the construct is a boolean debug flag, and if true then error_reporting is set to -1 and display_errors to 1, otherwise default and 0 respectively.
$kernel = new AppKernel('dev', false);
symfony documentation
Hope this helps.
I got the same error in the following scenario i.e.
Scenario:
I lost the development environment for my existing LIVE project. But I got the whole code from GIT repo and then installed the symfony 2.4.2 (same version as on LIVE site) in my new development environment. Then I found that the web-application pages working on the LIVE site are broken in my new DEV environment.
Solution:
I spent quit a lot time to understand why the problem is then I found that i.e.
When I installed symfony 2.4.2 in my development environment using composer.phar then it created a new web/app_dev.php file in my development environment and it has the following entry to turn it off i.e.
Debug::enable();
Just comment the above line then the php notices will be off and then all the pages that were giving me notices are fixed.
I hope this will be helpful for someone having the same problem like me. Good Luck!
Cheers.
PS: But I will recommend to enable the above line in your new development projects so that you can see the PHP notices and then remove them during development.
Sorry for another 'phpunit doesn't work' question. It used to work for years now. Today I reinstalled PEAR and phpunit for reasons not connected to this problem. Now when I run phpunit as I usually did. Nothing happens. The cli just shows me a new line, no output whatsoever.
Has anyone encountered this problem or has an idea what could have caused it.
PHPUnit Version: 3.5.15
PEAR Version: 1.9.4
PHP Version: 5.3.8
Windows 7
I'm on OSX and MAMP. To get error messages I had to adjust the following entries in php.ini:
display_errors = On
display_startup_errors = On
Please not that this has to go into /Applications/MAMP/bin/php/php5.3.6/conf/php.ini .
For future reference, for those who are facing any problem with PHPUnit, and PHPUnit is failing silently, just add this three lines inside phpunit.xml:
<phpunit ....... >
...
...
<php>
<ini name="display_errors" value="true"/>
</php>
</phpunit>
After that run the tests again, and now you can see why PHPUnit is failing,
AND ... ENJOY UNIT TESTING :)
I know the orignal poster's question is already answered, but just for any people searching in the future: one thing that can cause PHPUnit to fail silently (i.e. it just stops running tests without telling you why) is that it has an error handler that it set up before each test run, which is intended to capture errors and display them at the end of the test run. The problem is that certain errors halt execution of the whole test run.
What I generally do when this happens, as a first step, is reset the error handler to something that will immediately output the error message. In my base test class I have a method called setVerboseErrorHandler, which I'll call at the top of the test (or in setUp) when this happens. The below requires php 5.3 or higher (due to the closure), so if you're on 5.2 or lower you can make it a regular function.
protected function setVerboseErrorHandler()
{
$handler = function($errorNumber, $errorString, $errorFile, $errorLine) {
echo "
ERROR INFO
Message: $errorString
File: $errorFile
Line: $errorLine
";
};
set_error_handler($handler);
}
Create the simplest test class you can without a bootstrap.php or phpunit.xml to first verify that your new installation works. PHPUnit will stop without any message if it cannot instantiate all of the test cases--one for each test method and data provider--before running any tests.
You have already figured out how to get it to work, but my solution was a little different.
First thing you can do is check the exit status. If it's not 0, then PHP exited and because of the INI configuration settings set, none of the PHP error messages were outputted. What I did was to enable the "display_errors" INI setting, and set "error_reporting" to E_ALL. I was then able to identify errors such as PHP not being able to parse a certain script. Once I fixed that, PHPUnit ran properly.
I managed to spectacularly paint myself in a corner with a custom "fatal error handler" that in certain rare conditions turned out to output nothing. Those conditions, in accordance with Murphy's Law, materialized once I had forgotten the handler was in place.
Since it wasn't really a "PHPunit problem", none of the other answers helped [although #David's problem was at the bottom the same thing], even though the symptoms were the same - phpunit terminating with no output, no errors, no log and no clue.
In the end I had to resort to a step-by-step tracing of the whole test suite by adding this in the bootstrap code:
register_shutdown_function(function() {
foreach ($GLOBALS['lastStack'] as $i => $frame) {
print "{$i}. {$frame['file']} +{$frame['line']} in function {$frame['function']}\n";
}
});
register_tick_function(function() {
$GLOBALS['lastStack'] = debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 8);
});
declare(ticks=1);
If anyone ever manages to do worse than this, and somehow block stdout as well, this modification should work:
register_shutdown_function(function() {
$fp = fopen("/tmp/path-to-debugfile.txt", "w");
foreach ($GLOBALS['lastStack'] as $i => $frame) {
fwrite($fp, "{$i}. {$frame['file']} +{$frame['line']} in function {$frame['function']}\n");
}
fclose($fp);
});
an old thread this one, but one I stumbled across when having the same problem.
I had the same problem, nothing being returned to console including print, print_r, echo etc.
solved it by using --stderr as a test-runner option.
Check that you haven't written any logic into your code that just dies, with no output. For example,
<?php
if (!array_key_exists('SERVER_NAME', $_SERVER)) {
die();
}
This was exactly my case; I'd made some assumptions about the environment which were correct when running the code via Apache, but weren't fulfilled when running from CLI and the code did not echo any output.
PHPUnit tried to include the bootstrap file before giving the usual init output, but died during the bootstrapping proccess, hence exiting with status 0 and no output.
If when you run from command line a recent version of phpunit like this
> php phpunit
or
> ./phpunit
or
> php ./phpunit.phar
or
> ./phpunit.phar
And you immediatly return to the prompt with no messages, this is probably due to a "suhosin secutiry" setup.
phpunit is now a "phar" package including all libraries. To be able to run such file when php has the suhosin security module enabled, you must first set this
suhosin.executor.include.whitelist = phar
into you php.ini file (for example, with debian/ubuntu, you may have to edit file /etc/php5/conf.d/suhosin.ini
i tried everything here, but nothing worked until i tried phpunit --no-configuration simpletest.php. that finally gave me some output, which implies that my phpunit.xml.dist file is broken. (i'll come back and update this once i debug it.)
the contents of simpletest.php are below, but any test file should work.
<?php
use PHPUnit\Framework\TestCase;
final class FooTest extends TestCase
{
public function testFoo()
{
$this->assertEquals('x', 'y');
}
}
Check if the phpunit you're running and the one you installed are the same:
$ pear list phpunit/phpunit
...
script /path/to/phpunit
...
Try to execute exactly that phpunit with the full path.
Then check your PATH variable and see if the correct directory is in it. If not, fix that.
If that does not help, use write something into the phpunit executable, e.g. "echo 123;" and run phpunit. Check if you see that.
For me the conflict was with Xdebug's directive
xdebug.remote_enable=1
If you are using composer, check to make sure your included PHP files are not ending the code executions. The same goes for when you included certain PHP files explicitly.
In my case, I was working on a WordPress plugin and one of the PHP files I included directly in composer.json (which I don't want to load through PSR-4 because WordPress's coding standards don't support it yet) had this code on top;
if (!defined('ABSPATH')) {
exit(); // exit if accessed directly
}
And since ABSPATH will not be defined when I run the tests directly, the code was exiting.
This is because, since I told Composer to always load these files each time, this part of the code will execute, while the other files included though autoload PSR will load on demand.
So check to make sure any of the files you included are not stopping the code execution. If it happens, then even when you run phpunit --info the code will still exit and you won't see any output.
I was facing a seems problem. I could run phpunit from root directory but not from anywhere else. so I put the "--configuration" tag, and point it to my xml configuration.
$ ./<path_to_phpunit>phpunit --configuration <path_to_phpunitxml>/phpunit.xml
The path to phpunit is optinal, I used it because I installed locally by composer.
In /composer/vendor/phpunit/phpunit/src/TextUI/Command.php in main() function in catch (Throwable $t) {} block var_dump (echo / print_r) exception. If an exception exists, you, probably, will solve the current problem.