I am getting Class 'Splash\\SiteBundle\\Util\\Resize' not found when running my app on prod. This does not happen on dev.
Here is the code from the error:
$resize = new \Splash\SiteBundle\Util\Resize($this->getAbsolutePath());
I have a file called Splash\SiteBundle\Util\Resize.php with this namespace
namespace Splash\SiteBundle\Util;
Class Resize{ ... }
Any thoughts?
So the quick fix is to add this include dirname(__FILE__) . "/../Util/Resize.php"
I am not sure why my production machine would need the include while my dev machine works fine without it. Using Symfony2 and the autoloader I have never needed to include a file. Not sure whats goin on but this get me past it for now
One of the possible thing that could lead this to happen could ne not cleared cache
php app/console cache:clear -e prod
Another stupid thought could be that production has merge conflicts within that file and PHP doesn't see the class compiled.
I love when its the little things. My util folder was not capitalized. I changed this and it works now. I'm surprised my dev machine did not fail w this error.
Related
Im kind of new with Travis, and I am expreimenting with it right now. I uploaded have my PHP Project on Github and when I let it test via Travis it fails and gives me this error.
PHP Fatal error: Class 'controllers\Welcome' not found in /home/travis/build/ezylot/PHPSkeleton/tests/controllers/welcomeTest.php on line 4
I use a autoloader to load the classes, and it is no problem on my local machine. I include the autoloader in bootsrap.php with the bootstrap in the PHPUnit Konfiguration-XML File.
<?php
if (!#include __DIR__ . '/../vendor/autoload.php') {
die('You must set up the project dependencies, run the following commands:
wget http://getcomposer.org/composer.phar
php composer.phar install');
}
?>
You are most likely developing on OSX which has case insensitive filesystem and tests pass. Travis uses case sensitive file system. Try renaming app/controllers/welcome.php to app/controllers/Welcome.php.
In general it is good idea to follow PSR-1 standard to avoid autoloading issues.
I had a short php open tag at the top of the class file.
<?
as opposed to
<?php
This broke it on the remote, but not on my local. Which is weird, because I would've expected it to break locally too.
Putting this out there in case someone else is in the same odd situation.
I've finished a web site that runs on my computer and on the old server. The problem is that the old server is dying and my employer wanted to move it to a new server.
When he moved it, one web page shows me an error:
The autoloader expected class "Equips\FrontendBundle\Helper\LDAPHelper" to be defined in file "/var/www/sinfratic_dev/src//Equips/FrontendBundle/Helper/LDAPHelper.php". The file was found but the class was not in it, the class name or namespace probably has a typo.
and it's like "what?" because I haven't done anything of that part (I just worked with another part of the web). And I've checked that file and inside there is the class "LDAPHelper".
I know what a server LDAP is, but I don't know if that problem is because the new server cannot communicate with out LDAP server or it doesn't have all things installed (I've installed ldap-auth-client, ldap-auth-config, libaprutil1-ldap, libldap-2.4-2, libldap2-dev, libnss-ldap, libpam-ldap and php5-ldap; things that were on the old server but not in the new, but it still doesn't work).
Any idea?
Thanks you so much.
EDIT
Thanks for the comment. Here is the header of the file:
<?
namespace Equips\FrontendBundle\Helper;
class LDAPHelper {
Ok, it was PHP and something unexpected.
By default, short_open_tag is off, so this .php could not be readed properly.
Just needed to put it on in php.ini.
I'm using PHP 5.4, and have a PSR-0 class structure similar to the following.
A\Library\Session.php:
namespace A\Library;
class Session { ... }
My\Application\Session.php:
namespace My\Application;
class Session { ... }
My\Application\Facebook.php:
namespace My\Application;
use A\Library\Session;
class Facebook { ... }
When I try to run the application, I get the following error:
Cannot use A\Library\Session as Session because the name is already in use in My\Application\Facebook.php
Even though it's not, at least not in this file. The Facebook.php file declares only the Facebook class, and imports exactly one Session class, the A\Library one.
The only problem I can see is that another Session class exists in the same namespace as the Facebook class, but as it was never imported in the Facebook.php file, I thought it did not matter at all.
Am I wrong (in that case please point to the relevant documentation), or is this a bug?
There is a bug confirmed in PHP that may affect the behavior you see. It is supposed to fatal error, but with opcache enabled, it may still execute flawlessly.
https://bugs.php.net/bug.php?id=66773
If it still concerns you, please vote for the bug.
No, this is not a bug. As mentioned in Using namespaces: Aliasing/Importing
use A\Library\Session;
is the same as:
use A\Library\Session as Session;
So try using something like:
use A\Library\Session as AnotherSessionClassName;
The only problem I can see is that another Session class exists in the
same namespace as the Facebook class, but as it was never imported in
the Facebook.php file, I thought it did not matter at all.
Yes, it does matter. This is why you don't need to "import" classes from the same namespace. If you have conflicting names from different namespaces, you need to alias the class.
namespace My\Application;
use A\Library\Session as ASession; // choose a proper alias name here
class Facebook { ... }
I've read the thread about the issue, but I tested on many PHP versions (php 5.5, 5.6, 7.*, x32, x64, vc11, vc14, vc5). I'm using Laravel with Laragon. But, when I build up the server with php artisan serve (and open the server at http://localhost:8000) I have the problem of "the namespace that some Class was already used" and stuff.
I tested with and without opcache extension and nothing works, then I tested the virtual domain that Laragon provides and... voila, the error just disappeared and now I can work OK. I don't know what was happening, my namespaces were OK, I had an alias but the same code works in many machine without problem (AWS, local, prod, dev, etc) but only in my machine I had the problem just as I described it.
So, if someone is working with Laravel (5.1) and is having this issue, try the virtual host of Laragon.
I've browsed through similar problems on SO, but to no avail. I'm running PHP 5.3.6 and phpunit version 3.6.10. When attempting to execute a simple test:
require_once 'PHPUnit/Framework.php';
class UserTest extends PHPUnit_Framework_TestCase {
}
I receive the following error:
PHP Fatal error: require_once(): Failed opening required 'PHPUnit/Framework.php'
(include_path='.:/Users/username/pear/share/pear:/usr/lib/php/pear/:/Users/username/pear/share/pear/PHPUnit') in ...
When reinstalling PHPUnit, I'm not sure if the install location was duplicated, but it appears that when running which phpunit, the path is: /usr/bin/phpunit. However, it appears to also be installed in /Users/user/pear/bin/phpunit.
I've tried updating all channels and reinstalling PEAR and PHPUnit, but the problem still exists. I'm running on OSX Lion. Any help would be greatly appreciated.
Just remove the line
require_once 'PHPUnit/Framework.php';
and everything should work.
You don't need to include/require anything PHPUnit related since (at least) PHPUnit 3.6 any more and you can't include that file because it doesn't exist any more in the distribution.
The phpunit runner will take care of bootstrapping everything that is needed by PHPUnit :)
As others pointed out, Framework.php is not required anymore.
But in any case if you already have too many test files written and having the include statement, then fixing them going to be a cumbersome task. Which was the case I had to face.
If a quick workaround is needed, create an empty Framework.php file. That will resolve the problem.
Create an empty file named Framework.php under your PHPUnit directory. (eg: at: /usr/share/php/PHPUnit/Framework.php).
sudo touch /usr/share/php/PHPUnit/Framework.php
I just installed PHPUnit 3.5 on my system, upgrading it from 3.4, and I'm having some trouble with the new version. When I try to run a test, I always get the same output. Here's what I get when I try to run on the command line the StackTest example from the PHPUnit manual, example 4.1:
> phpunit StackTest
X-Powered-By: PHP/5.2.17
Content-type: text/html
PHPUnit 3.5.13 by Sebastian Bergmann.
Class StackTest could not be found in StackTest.php.
Worse yet, when I try to run it from a web browser, I get the following output:
Fatal error: Class 'PHPUnit_Framework_TestCase' not found in /path/to/tests/StackTest.php on line 2
Does anyone know how to set this up? Thanks.
I had the problem you described on Windows.
The problem was in the file pear\PHPUnit\Runner\StandardTestSuiteLoader.php on line 131 an it was caused by different drive letter case in file name in the condition
if ($class->getFileName() == realpath($suiteClassFile)) {
My simple fix is to change this line to be case insensitive
if (strtolower($class->getFileName()) == strtolower(realpath($suiteClassFile))) {
phpunit MyTestClass
In my case
MyTestClass.php should be in the project home directory
it should starts with long php open tag (<?php, not <?)
it should contain class MyTestClass extends PHPUnit_Framework_TestCase {
I know this is most likely not the best way, just point for a beginner to start with.
Try
pear upgrade pear
(if it asks you to channel upgrade do so)
and then
pear install --force --alldeps phpunit/phpunit
and try again.
The 3.5 upgrade combined with a buggy pear installer (1.9.1 has a kinda annoying bug so make sure you are really on 1.9.2) can be a pain sometimes.
I think your PHPUnit Class named StackTest, and the class you want to test is also named StackTest. This will cause a path conflict in PHPUnit.
Make these 2 names different and you will get this resolved.
In my case, this problem was caused by including PHPUnit in the source file via require_once:
require_once 'phar://phpunit.phar';
Removing that line made my test case runnable.
This error can also be caused when you forget to have your test class extend the PHPUnit TestCase class, like
class MyTestClass extends \PHPUnit\Framework\TestCase { ...
I was able to fix the problem. It was a result of how I was loading the class. I used my arguments in the argument array like so and it worked. But there were a lot of other problems with the classpath etc that I had to fix first. To see a working solution look here (http://www.siteconsortium.com/h/p1.php?id=php002).
$command = new PHPUnit_TextUI_Command();
$command->run(array('test', 'testCase', 'c:\workspace\project\testCase.php'), true);
Starting from PHPUnit 9, it is required that the filename match the class name in the test.
#4105: Deprecate multiple test case classes in single file and test case class name differing from filename
So test-plugin.php with a class name PluginTest will fail with this error. To fix it, you'd need to rename the file to PluginTest.php.
Bad error message IMO.
It sounds like PHPUnit isn't on your include path. To easily test this, try this:
$ phpunit --include-path /path/to/PHPUnit StackTest