How do I have Symfony 2 ignore hidden files? If I edit my source tree, my Mac puts all kinds of .AppleDouble directories everywhere and I get errors like this (when running a command via CLI):
The autoloader expected class
"Thing\CoreBundle\Command.AppleDouble\EnsureIndexesCommand" to
be defined in file
"/var/www/mysite.com/Symfony/app/../src/Thing/CoreBundle/Command/.AppleDouble/EnsureIndexesCommand.php".
The file was found but the class was not in it, the class name or
namespace probably has a typo.
The .AppleDouble directory contains a file that ends in "Command.php" which is picked up by Symfony which thinks it's a valid command file when it's just serving some OSX purpose.
I see that there's an ignoreDotFiles option that is set on by default in the Finder.php constructor, but it apparently has no effect:
https://github.com/symfony/symfony/commit/7ab3fdeb8325d5a72c44dc73214c97f366a11c4c
I have to clean the source tree before I run every command which gets old and makes the Mac filesystem & Eclipse unstable since those hidden files are there for a reason.
Related
Been scratching my head over this for hours.
I've inherited a large PHP project and it's now my responsibility.
I also admit that I am not very experienced with Symfony.
Looked all over StackOverFlow for help, but still cannot resolve the following issue.
I made a change in \src\Entity\SOMETHING\BLAH.PHP
Now when I run php bin/console make:migration I get the following error:
[Symfony\Component\Debug\Exception\FatalErrorException]
Compile Error: Cannot declare class App\Entity\SOMETHING\BLAH, because the name is already in use
All I changed was the string length of a column.
#ORM\Column(type="string", length=100, nullable=true)
I've tried moving the migration file that defined the table orignally out of the src folder
I've tried clearing the vendor and node_modules folders, and running
npm and composer install.
I've tried cache:clear command
I've searched the code, and the class is only defined once. Any help greatly appreciated.
The issue was that there were two files in the same directory with the same name, however with a different case (BLAH.php and Blah.php). For reasons unknown, the "duplicate" files did not show in any source code editor, nor in any ls commands to the directory, nor in any text searches with grep.
After moving one of the conflicting files, it was noticed when doing an ls that the other file with a different case was there. It was not visible prior to moving the file. After removing the other file and moving the original back, then the code compiled.
In summary: a possible file-system glitch was preventing files with the same name but a different case from being visible.
I'm looking through the documentation, but I'm not seeing any option to change the working directory used when running tests.
I'm using PhpUnit as it's included in Laravel. I want to be able to run vendor/bin/phpunit from my project's root directory, and have it run using the /public directory as the working directory.
I tried running ../vendor/bin/phpunit from the /public, but since the phpunit.xml file isn't in the public directory and I don't want to specify my config file path every time, that won't work.
Is there something I can add to my phpunit.xml file to tell it to run tests using the /public directory as the "cwd" (current working directory)?
Based on the feedback I received in the comments and the documentation, I determined the following:
It's probably not possible to change the cwd that phpunit uses by default (well, it's possible in PhpStorm, but not the command line without writing some kind of wrapper script)
Code that depends on being run from a specific directory is not a good idea.
What I had was some code in one of my classes like this:
$var = file_get_contents("../some_file.json");
This works fine -- until you try to add unit tests. The web server runs using the /public directory as the cwd, while phpunit will run using the root directory.
Rather than trying to force phpunit to always use a particular cwd (/public), I decided it's probably best to remove relative paths from the code that rely on a consistent cwd. So the line above becomes:
$var = file_get_contents(base_path("some_file.json"));
I didn't want to change production code that was already working just to get some tests in place, but this change seemed insignificant enough. (and it's an improvement anyway)
Well, you'd have to do the actual chdir in PHP, but you can define a bootstrap script in the XML (<phpunit bootstrap="./bootstrap.php">) and have that change the working directory.
Alternatively, you can put a setUpBeforeClass function into your test class that changes the working directory.
I have a php application that relies on several classes to function properly. If I take one of the application's class files
/my/folder/class.php
then move it somewhere else
mv /my/folder/class.php /my/other/folder/class.php
then in its place inside of
/my/folder/
I create a symlink to it called class.php via
ln -s /my/other/folder/class.php /my/folder/class.php
I would expect my application to be unaffected, but instead this is breaking it. I know the symlink is valid since at the command line I can do
nano /my/folder/class.php
and everything looks as I would expect it to. Am I missing something fundamental about the behavior of symlinks, and/or how apache or php processes them? Is it changing the working directory or $_SERVER['DOCUMENT_ROOT']? I can not figure out why this would have any affect on my application.
I am using Apache server in CentOs.
Thanks!
The only difference would be if you are using require_once or include_once and you are mixing the symlink path with the real file path. In this instance, the X_once is going to think those files are different and load it twice (which will of course cause problems if you define any classes or functions).
Would probably need an actual error message to guess any further.
I have set up PhpStorm 5 with PHPUnit, and I'm curious if PhpStorm might have some functionality that will automatically run a unit test when saving a file. Like watchr and guard. I have tried search our beloved www and the PhpStorm docs, but haven't been able to find a solution for it.
As of version 6, PHPStorm has "File Watchers"
Open your project preferences.
Select File Watchers from the left hand list of options.
Click the + symbol at the bottom of the empty right hand panel.
Select <custom>
You will have to set up a command line for PHPUnit, it wont be the integrated testing, but you can have errors output to the console (which is good a good start!)
Various macro options are available to you, so you can include (for example) $FileNameWithoutExtension$Test.php in the arguments passed to your command line.
I personally had to set up two watchers. The first detected modifications to project files, and the second detected changes to test files (the second did not append Test.php to the filename) I also created a new project scope to exclude the tests directories from the first watcher.
You may also want to turn off immediate synchronisation, as this causes PHPUnit to run when PHPStorm auto-saves files.
My other settings are like:
File Type: PHP files (PHP)
Scope: Project excluding tests
Program: /path/to/php
Arguments: /path/to/phpunit --configuration /path/to/phpunit.xml.dist /path/to/tests/$FileNameWithoutExtension$Test.php
Working directory: $FileDir$
Output paths: $FileDir$
No output filters set, syntax error checks enabled, and console showing errors.
PHPUnit watcher named as hot phpunit runner
https://github.com/slavahatnuke/hot-phpunit-runner
You can also have a look at TDDRunner
It is console tool that execute PHPUnit autmaticly on file changes. You can also configure PHPUnit by excuting only one file ot whatever.
/usr/bin/tddrunner --group=test
There's a a German article providing further detail.
In 2017 Jetbrains release a feature that allow auto-run for tests.
It's located in the Run console, therefore it's linked to the run settings, easing the setup of this autorun.
See https://blog.jetbrains.com/phpstorm/2017/07/autorun-phpunit-tests-in-phpstorm-2017-2/
I have a strange problem. I want to turn off the auto generating of my proxies in Doctrine 2. I found this line of code that should do (and does) the trick:
$config->setProxyDir(APPPATHSYSTEM."/proxies");
$config->setProxyNamespace('Proxies');
// Auto generate proxies for development
$config->setAutoGenerateProxyClasses(DEVELOPMENT);
On my test environment the proxies are located at application/proxies. i.e.:
application/proxies/BaseUserProxy.php
When I'm on the live environment my code suddenly searches for the proxies at application/proxies/Proxies which is not the actual location.
I do understand it has something to do with the namespace, but I don't understand why it behaves differently when using the setAutoGenerateProxy method.
Any ideas?
edit
I did generate the new proxies using the:
orm:generate-proxies
option.
Which gave me this output:
php doctrine.php orm:generate-proxies
Processing entity "Base\Element"
Processing entity "Base\Page"
...
Processing entity "Base\Site"
Proxy classes generated to "/var/www/application/proxies"
Looking at the last line, the proxies are generated in /var/www/application/proxies. The directory listing looks like this:
BaseElementProxy.php
BasePageProxy.php
...
BaseSiteProxy.php
So there is no extra Proxies directory. But when I refresh my webpage it thinks there is, it gives me the following error:
Warning: require(/var/www/application//proxies/Proxies/BaseUserProxy.php)
[function.require]: failed to open stream:
No such file or directory in /var/www/library/Doctrine/Common/ClassLoader.php on line 148
Why is the extra Proxies directory added? If I do generate the proxies on each request it does not look in the extra Proxies directory. Anybody?
#Bryan M.: That is not a solution, but a workaround. Besides, it does not work. When generating the proxies they will, if applying your suggestion, be generated in APPPATHSYSTEM and my webapp will try to load them from APPPATHSYSTEM."Proxies". The problem is that the system looks for the proxies on different locations if I use:
$config->setAutoGenerateProxyClasses(DEVELOPMENT);
If DEVELOPMENT is true, it will look at APPPATHSYSTEM. If DEVELOPMENT set to false, it will look at APPPATHSYSTEM."Proxies". Just switching the DEVELOPMENT constance breaks my application, what theoretically should not be possible.
I don't think AutoGenerated proxies care.
Instead of pushing autogenerated proxies to production, you should probably doctrine orm:generate-proxies, which I suspect will put them in the place your production code is configured to look for them.
Are you developing on OS X and deploying to Linux? OS X's filesystem is case insensitive. So I'll often run into a problem where I mistype the case of a class, and it runs and passes just fine in the local environment, but chokes on our server.
So in this case, in OS X, the namespace "Proxies" is able to resolve to "/proxies", but in production, it can't find the class folder, and creates it under "/proxies/Proxies".
If you rename the folder to something called "/temp" you will realize the difference between path and namespace.
The path is the absolute path to the directory the proxies are getting generated into. The namespace is necessary to allow you to configure how an autoloader picks up these entities.
The path in your case has to be something like "proxies/Proxies" and the namespace is then "Proxies". Your autoloader has to be configured to listen to namespace prefix "Proxies" at directory "proxies/".
This is all mood with Doctrine 2 RC1 though, we found a way to explicitly load a proxy path without help of an autoloader at no additional cost. The Proxy Namespace configuratino is therefore only necessary to make sure no other classes are in the same namespace as the proxies.