Here is the situation.. I have some classes that are in one project... My main code is in another project... and i split this up because i am using GIT as my SCM... So when i debug my main code... i would like to step into the classes and debug them, but xdebug won't let me step into them... and i assume its because the classes are in another project... any ideas?
Thanks in advance...
I've run into this as well. I am going to assume that the way your projects look when they are deployed is that the classes in the separate project are copied into some directory somewhere in the main code.
Let's assume the separate project contains only one class, Foo, for simplicity's sake. Let's assume, too, that Foo is present in the deployed "main code" in the directory and file /maincode/external/lib/Foo.php. Finally, let's assume that /maincode/external/lib exists as a directory in your version-controlled "main code" project, and that it contains only a place-holder file and is otherwise empty.
First, use one of the many methods git provides to ignore the contents of the /maincode/external/lib directory in your NetBeans project directory for that project. We're going to make it look like it contains some stuff, and we don't want this directory, that is otherwise supposed to be empty, to get changes committed to it by mistake.
Now that it is ignored, make a symbolic link in that directory to Foo.php over in the other project. In Unix, you want the ln command, e.g.
ln -s /path/to/project/files/MyFooProject/Foo.php Foo.php
In Windows, you are looking for the mklink command, e.g.
mklink Foo.php C:\path\to\project\files\MyFooProject\Foo.php
Give NetBeans a moment or two to think about it (or force the issue by invoking the "Scan for external changes" command in the "Source" menu), and you should see Foo.php show up in the "maincode" project where you made the symbolic link.
Now, when you are tracing through execution and need to step into Foo.php to see what the Foo class is doing, you will step into the one that is in the "maincode" project. Since it is a symbolic link over to the file in the "MyFooProject" project, however, any chanes you make will be reflected over there.
Just be sure to unlink everything (the normal rm commmand in Unix, and the usual del command in Windows, but in the directory where the symbolic link is!) when you are through. Also, if there were things in the directory that you ignored that you want to be able to commit, then un-ignore that directory.
If you need to do this for more than just one file, then you can link whole directories. If, instead of the above, you normally copy the contents of "MyFooProject" into the directory /maincode/external/lib/myfoo/ in the deployed version, then just link the appropriate directory like you did the file above. In Windows, for example,
cd \path\to\project\files\maincode\external\lib
mklink /D myfoo C:\path\to\project\files\MyFooProject
That will make a symbolic directory link. It has been a while since I did anything like that on Unix, so I don't remember the exact command for the same thing on that OS (or if symbolic directory links are even possible on Unix). Once the directory is linked, you should see the new directory plus all of the files and subdirectories show up in your NetBeans "maincode" project, ready for your execution-tracing pleasure.
Again, remember to unlink and un-ignore everything once you are done, lest you wake up the next morning to find yourself confused. :) To unlink the directory in windows...
cd \path\to\project\files\maincode\external\lib
rmdir myfoo
and it should unlink. (Just be careful when you are deleteing and rmdir'ing that you are doing it to the symbolic link!)
Related
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'm having some serious frustration getting a simple PHP application to deploy reliably using OpsWorks, I can't find any documentation of how the srv/www/app-name/releases directory is managed, but I think that may been the cause of my current problem.
I'm deploying a Laravel application, so I need two things to happen with chef recipes on deploy: composer install, and some directories to be made writable. Composer does seem to be installing fine, but my recipe to create & chmod the directories seems to happen to the previous release - which makes no sense to me at all.
Install composer:
node[:deploy].each do |application, deploy|
script "composer-install" do
interpreter "bash"
cwd "#{deploy[:deploy_to]}/current"
user "root"
code <<-EOH
composer install
EOH
end
end
This works fine, I can refresh the vendor directory as this runs see the dependencies appearing. But the next recipe to run:
node[:deploy].each do |application, deploy|
Chef::Log.info("Application path: #{deploy[:deploy_to]}");
node['directories'].each do |path|
# Get the path we need
new_path = "#{deploy[:deploy_to]}/current/"+path
Chef::Log.info("Checking directory: "+new_path);
# Ensure the dir exists
unless File.exists?(new_path)
Chef::Log.info("Creating directory: "+new_path);
Dir.mkdir( new_path, 777 )
end
# Ensure its writable
File.chmod( 777, new_path )
end
end
The content from Chef::log does appear in the log, there are no errors, but the directories are simply not there - they are created in the PREVIOUS release/timestamp directory, as if the 'current' symlink has reverted back for the duration of this recipe. They are also created with permissions '411'.
Can anyone explain where I'm going wrong here?
Can I access the new directory path instead of using the 'current' symlink?
What is very likely happening is that you're applying these two specified recipes at different stages of the deployment. Since you're using Current - it will be at one stage the old directory, while checking out the next part of the application.
What you should be maybe doing instead is :
use the "#{release_path}" variable in your recipes to generate build specific files/events in your app.
use the deploy/before_restart.rb file to execute some symlinks that provide the files at a predictable location
If you provide screenshot of the recipes that are being called and on what layer from the layer edit view, it will help people here to see what is happening and give you a better feedback.
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.
The directory structure of my project is like this:-
/var/www/includes/
/var/www/classes/
/var/www/public/css/
/var/www/public/js/
/var/www/public/index.php
The webroot is /var/www/public, so accessing the test domain localhost.dev would serve the files inside the public directory and hence would run /var/www/public/index.php. No need to access like localhost.dev/public/index.php
The problem is when I create the project in Netbeans, I have to set the index file so that the project can be debugged using xdebug and Netbeans.
So when adding the project I provided /var/www as Project source folder (Sources Folder) as the includes and classes are in this folder. In the next project configuration screen (Choose Project > Name and Location > file path is taken as Run Configuration), I'm asked for the Project URL and the index file. Since the index.php file is actually under the /var/www/public/, when I browse the file and select it, the url to index page is taken as localhost.dev/public/index.php instead of just localhost.dev/index.php. This is preventing me from debugging the project.
Can anyone please point out how to add projects to Netbeans when all the source files are not in web root and the project is to be debugged using xdebug.
I think its a bad practice to put all the project files directly in /var/www.
I think you will never see that in real deployed projects. So my first recommendation will be to change the way you are structuring your project. If that's not possible, in Netbeans select /var/www/public as the Project folder.
If Netbeans need references to the folders in /var/www, create symbolic folders inside public pointing to those in /var/www.
The last resource you have is to create a rewrite rule in Apache to make localhost.dev/public be the same as localhost.dev. You can look for this in Apache documentation.
I have a similar set up with one minor difference: my setup uses a remote site on my local development server. On the "Run Configuration" window of the project properties, I set "Run As" to "Remote Web Site (FTP, SFTP)". I don't think this affects the information in my answer, but I'm mentioning it just in case.
Go to the "Sources" window of your project properties, find the entry for "Web Root", click "Browse" and select the /var/www/public directory. That should cause xDebug to use localhost.dev/index.php. You'll notice when you go to the "Run Configuration" window and browse for the Index File that the browse window will start in "public" rather than "www".
An important note about this type of configuration that caused me a great deal of frustration.
When using xDebug, you'll want to be able to set breakpoints in and work with the files outside of the web root (public) directory. Because you've set the web root to /var/www/public, you won't be able to work with the files in /var/www/includes or /var/www/classes.
The thing you need to do is to add the files outside of your web root to the Global Include Path.
There are two methods for adding directories to your Global Include Path, which one you use depends on how you've configured your project.
In your case, the external directories are included in your project, so you need to add them via the "Options" interface. Go to Tools->Options and select the "PHP" tab, then add the /var/www/includes and /var/www/classes folders to the Global Include Path.
The other method for adding files to the Global Include Path is for files that are located outside of your project source folder. For directories like /var/folder_outside_www/, you use the "PHP Include Path" window in the project properties.
I haven't found a better way but I use this steps:
Menu:Project Properties -> Link:Run Configuration -> Button:Advanced
Debug URL, choose: Ask Every Time
Path Mapping, Server Path: http://localhost.dev/ ,Project Path: /var/www/public/
Now, when you start Debugging process, Netbeans will display Specify URL pop-up which you can change from http://localhost.dev/public/index.php into http://localhost.dev/index.php
Set /var/www/public as project folder (contain netbeans project folder) and include in project properties /var/www/includes/ and /var/www/classes/ as global include directories. Or best way use PHPStorm.
We're using CakePHP for a new application, and we use Mercurial as the source control tool. (Mercurial uses one .hgignore file in the root directory, unlike (for example) CVS that uses .cvsignore in any directory.)
I'd like to exclude the content of the app/tmp/ directory from the source control (since they change all the time, and can be regenerated), but I can't add app/tmp/* to .hgignore, since then the standard directories under tmp (cache, logs, sessions, tests, and also cache/models, cache/persistent, ...) would be missing from new clones made by hg clone, resulting in errors.
Currently I have in my hgignore:
app/tmp/logs/*.log
app/tmp/cache/persistent/cake_*
app/tmp/cache/models/cake_*
It would be good to have a "standard" one that could be used in all projects. Can someone suggest a complete solution?
You can add
syntax: glob
app/tmp/**
to your .hgignore file and Mercurial will from that point on ignore all files under app/tmp/ with the exception of files tracked by Mercurial. See hg help patterns for more about file name patterns.
So if you do
% touch app/tmp/cache/.empty
% touch app/tmp/logs/.empty
% hg add app/tmp/cache/.empty
% hg add app/tmp/logs/.empty
and make a clone, then the app/tmp/cache and app/tmp/logs directories will be created and new files in those directories will be ignored. I think that is what you want?
This is also useful for tracking something like $HOME since you would want to ignore most files by default and only track explicitly added files.
If I understand the question correctly you want to ignore file in tmp, but not files in certain directories in tmp. If that's right then I think you can do so using this:
syntax: regexp
^tmp/(?!(cache|logs|sessions|test))
That says ignore anything that starts with tmp, unless the next part is cache, log, sessions, test. For these files:
.
`-- tmp
|-- cache
| `-- afile
`-- tmpfile
here is the hg stat result:
$ hg stat
? .hgignore
? tmp/cache/afile
I will note, though, that Cake is probably telling you not to put those files into source control based ont heir being in a tmp directory. Are you sure they're not something htat your build system is supposed to create? Sessions in particular sound pretty transitory.
In my own checkouts (from SVN), when the site was deployed, the ./tmp/ directory needed to have some specific permissions.
I removed it from version control entirely, and my deployment script created the directories as required.