I moved from using Docksal to Acquia ADS (Lando) which automatically upgraded my Drush from 8 to 9. My local site works fine but I can't get Drush 9 to "see" my Drupal 8 site. The aliases seem to have been created and added to the drush/sites folder and running drush site:alias does show them. However running drush status shows my Drupal root as /app. My Drupal root is /app/docroot. My alias files do have this as their root (for local). I'm not sure why Drush doesn't use the alias files it knows about. I've tried:
drush #self(or #local) list and I get some commands and this statement at the end:
[NOTE] Drupal root not found. Pass --root or a #siteAlias in order to see Drupal-specific commands.
Doing drush #local(or #self) cr returns:
In BootstrapHook.php line 32: Bootstrap failed. Run your command
with -vvv for more information.
With -vvv:
Exception trace: at
/app/vendor/drush/drush/src/Boot/BootstrapHook.php:32
Drush\Boot\BootstrapHook->initialize() at
/app/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:34
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->callInitializeHook()
at
/app/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:27
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->initialize()
at
/app/vendor/consolidation/annotated-command/src/CommandProcessor.php:145
Consolidation\AnnotatedCommand\CommandProcessor->initializeHook() at
/app/vendor/consolidation/annotated-command/src/AnnotatedCommand.php:289
Consolidation\AnnotatedCommand\AnnotatedCommand->initialize() at
/app/vendor/symfony/console/Command/Command.php:221
Symfony\Component\Console\Command\Command->run() at
/app/vendor/symfony/console/Application.php:1005
Symfony\Component\Console\Application->doRunCommand() at
/app/vendor/symfony/console/Application.php:255
Symfony\Component\Console\Application->doRun() at
/app/vendor/symfony/console/Application.php:148
Symfony\Component\Console\Application->run() at
/app/vendor/drush/drush/src/Runtime/Runtime.php:118
Drush\Runtime\Runtime->doRun() at
/app/vendor/drush/drush/src/Runtime/Runtime.php:49
Drush\Runtime\Runtime->run() at /app/vendor/drush/drush/drush.php:72
require() at /app/vendor/drush/drush/drush:4
drush status:
PHP binary : /usr/local/bin/php
PHP config :
PHP OS : Linux
Drush script : /app/vendor/drush/drush/drush
Drush version : 10.2.2 <-- Had 9.0.0 but currently trying 10, same issue
Drush temp : /tmp
Drush configs : /root/.drush/drush.yml
/app/vendor/drush/drush/drush.yml
/app/drush/drush.yml
Drupal root : /app
self.site.yml:
local:
root: /app/docroot
uri: example.lndo.site
Can someone please point me in the right direction?
Figured it out. No matter how many ways you try to tell Drush where to look to find your Drupal root, none of it will matter until you edit your composer.json file. Turns out the key to making Drush 9+ work is changing the name in composer.
My composer.json file name went from:
"name": "drupal/drupal",
to:
"name": "drupal-composer/drupal-project",
I don't think this feature was documented anywhere so I'm posting it here in response to my own question in case this helps anyone else.
I realize that this is an older question, however with Drupal 8 recently reaching end of life, and the high probability of many people (like myself) scrambling to upgrade now that clients have realized the risks of using EOL software, I want to take a moment to explain why #r00t's answer works.
r00t is correct that changing the "name" value in composer.json fixed the issue, however, the value that is set is not limited to drupal-composer/drupal-project. This seems to stem from the package webflo/drupal-finder and the way it works.
webflow/drupal-finder is a requirement of drush/drush, so it's going to be included even if you haven't added it manually. It's also a requirement of a couple of others that you may or may not have installed, like palantirnet/drupal-rector (which as a side note, is really helpful for this upgrade).
Within the code for drupal-finder is a method that looks for the install path of Drupal core based on a few items within your composer.json file.
Here is the code from DrupalFinder::isValidRoot()
foreach ($json['extra']['installer-paths'] as $install_path => $items) {
if (in_array('type:drupal-core', $items) ||
in_array('drupal/core', $items) ||
in_array('drupal/drupal', $items)) {
$this->composerRoot = $path;
// #todo: Remove this magic and detect the major version instead.
if (($install_path == 'core') || ((isset($json['name'])) && ($json['name'] == 'drupal/drupal'))) {
$install_path = '';
} elseif (substr($install_path, -5) == '/core') {
$install_path = substr($install_path, 0, -5);
}
....
Which is telling drupal-finder that if the "name" value is drupal/drupal then the install path of the site is at the base of the project, however if it is not drupal/drupal then use a value from extra.installer-paths to find the site install.
I'm still not aware if this is documented anywhere on either webflo/drupal-finder or in drush/drush, but understanding why it was an issue helped me out tremendously.
TL;DR:
If your site's docroot lives next to your vendor folder, change the name in composer.json to anything that isn't drupal/drupal. If your vendor folder lives inside your docroot, drupal/drupal will work for you.
After install react-native-firebase and add module auth, showed this erro in Android Studio:
ERROR: Project with path ':#react-native-firebase_app' could not be
found in project ':#react-native-firebase_auth'.
What does this mean?
I have also faced the same issue.
After I install npm i #react-native-firebase/app the problem is solved.
You can try the following:
-Checking if firebase app was referenced in an incorrect way in MainApplication.java.
-Remove the modules and re-installing them may fix the problem sometimes.
I think you have different versions of firebase/app and firebase/auth.
Just go in 'node module/#react-native-firebase' directory and check package json of both firebase/app and firebase/auth you will see different version.
This problem can also happen if you are using #react-native-firebase#6.2.0
if you check the build.gradle of firebase/auth in version 6.2.0
dependencies {
api project(':#react-native-firebase_app')
implementation platform("com.google.firebase:firebase-bom:${ReactNative.ext.getVersion("firebase", "bom")}")
implementation "com.google.firebase:firebase-auth"
}
So here is a problem that it is not able to find #firebase/app
and #firebase/auth depends on #firebase/app
And in #6.3.4 which is working fine for me have build.gradle of #firebase/auth like below
so it is able to find #firebase/app
if (findProject(':#react-native-firebase_app')) {
api project(':#react-native-firebase_app')
} else if (findProject(':react-native-firebase_app')) {
api project(':react-native-firebase_app')
} else {
throw new GradleException('Could not find the react-native-firebase/app package, have you installed it?')
}
implementation platform("com.google.firebase:firebase-bom:${ReactNative.ext.getVersion("firebase", "bom")}")
implementation "com.google.firebase:firebase-auth"
}
run npm uni #react-native-firebase/auth
then run this simple command #react-native-firebase/auth#10.4.1
I was using "#react-native-firebase/auth": "15.1.1", and having the same problem , then i downgrade it to "#react-native-firebase/auth": "^10.4.1", and it worked.
if you have any problem installing make sure to use --legacy-peer-deps at the end , like this:
npm i #react-native-firebase/auth#10.4.1 --legacy-peer-deps
when I try to run a failed test with this command :
./vendor/bin/phpunit
I get this Fatal Error :
PHPUnit 5.7.20 by Sebastian Bergmann and contributors.
PHP Fatal error: Class 'PHPUnit\Framework\ExpectationFailedException'
not found in /var/www/zend/vendor/zendframework/zend-
test/src/PHPUnit/Controller/AbstractControllerTestCase.php on line 444
Your version of phpunit is probably too old for your version of Zend. The class PHPUnit\Framework\ExpectationFailedException have been renamed in PhpUnit 6.X from PHPUnit_Framework_ExpectationFailedException to ExpectationFailedException
Please check your PhpUnit version: phpunit --version, it should be 6.X. Update it to the last version to avoid this error.
This is "fixed" by a script in Zend\Test called phpunit-class-aliases.php but it's not configured properly IMHO since it's in the autoload-dev section (meaning it doesn't propagate out to other projects.)
So, in your project composer.json, do something like this:
"autoload-dev": {
"files": [
"vendor/zendframework/zend-test/autoload/phpunit-class-aliases.php"
]
},
Then composer install
N.B. Zend\Test has a pull request that fixes this very thing, but they're saying it's PHPUnit's fault (Shame on you PHPUnit 4 for... idunno... having the wrong class name according to Zend\Test) So, I've done it instead: composer require illchuk/phpunit-class-aliases
This is a configuration flaw in zend-test. It consumes classes from Phpunit 6 but per it's Composer requirements, Phpunit before that version are OK to require:
"phpunit/phpunit": "^4.0 || ^5.0 || ^6.0",
Most likely as your system because of the PHP version does not satisfy the requirements of Phpunit 6, the next lower version was installed.
As the code in the base test case (https://github.com/zendframework/zend-test/blob/master/src/PHPUnit/Controller/AbstractControllerTestCase.php#L444) makes use of Phpunit 6 classes, I strongly assume that when the configuration flaw is made aware to the Zend-Test project, you won't be even able to install on your system any longer.
Therefore upgrade to a recent PHP version and then run
composer update
If you're stuk with the PHP version, downgrade zend-test to a version that supports an older Phpunit version. I don't know that project well, so it's just a suggestion, I don't know if such a version exists or can't even recommend one.
I filed a report, perhaps using that one class was an oversight or there is a less hard way to resolve the dependency: https://github.com/zendframework/zend-test/issues/50
I have been researching this issue for days and although many people ask this question I never found a clear and concise answer.
I am running:
PHP Unit: Version 3.7.21
WordPress: Version 3.5.1
OS: Ubuntu 11.10
MySQL: Version 5.1.69-0ubuntu0.11.10.1
PHP: Version 5.3.6-13ubuntu3.10
Long story short, I have the basic wordPress core downloaded into a directory on my computer. I have successfully downloaded and installed pear and phpunit. I tested phpunit by writing basic tests on simple php files which worked fine. My issue is when I run phpunit on a wordpress site (which I have not changed the core WP files of).
I get the error:
"PHP Fatal error: Call to a member function main() on a non-member
object in /< root_directory>/functions.php on line 779".
This error corresponds to this code-segment:
function wp( $query_vars = '' ) {
global $wp, $wp_query, $wp_the_query;
$wp->main( $query_vars ); // Line 779
if ( !isset($wp_the_query) )
$wp_the_query = $wp_query;
}
After some intense internet crawling I found many people had errors on this exact line so I know there is some general thing like an environment setting or our setup process that gave us all this error.
Some solutions I have read and tried that did not work for me:
Change the required file in your "index.php" file.
Place a require of "load.php" above the head in your "index.php" file.
Re-install WordPress
Change boot-strap and phpunit environments.
I have been a web-developer for 5 years but I have never used WordPress for one of my clients before. Once I can get this set up writing the unit tests will be easy; but I have no idea what is causing this issue. Any links to guides/tutorials or clear explanations would be greatly appreciated. Thank you for your time.
There is a WordPress test suite, which your question suggests you might have missed:
http://make.wordpress.org/core/handbook/automated-testing/
Keep in mind, with that being highlighted, that WP was not designed in such a way that it or anything related to it can or is supposed to be tested. The modus operandi has, for years, been to commit code with no tests at all. It's admittedly improving over the years, albeit at a slow pace.
Related questions:
What are the best practices of custom application Wordpress development?
WordPress Plugin: How do I avoid "tight coupling"?
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.