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.
Related
Following an audit, I've been tasked to remove extraneous files from the Twig 1.x vendor directory in one of our sites. Planning on removing /twig/twig/doc, /twig/twig/test and see if anything breaks.
What about /twig/twig/ext/twig/run-tests.php, or the entire "ext" directory?
Does anyone have prior experience weeding a default Twig 1.x installation for production environments? Any assistance or advice gratefully welcomed.
The correct action would be to update your site's layout so that these files are outside your web server's document root -- then you don't have to worry about what to delete and what to leave. You probably have something like this, where your web server's document root is pointing directly at /path/to/project:
/path/to/project
/lib
foo.php
bar.php
/twig
/twig
/doc
/test
index.php
This means anybody can directly request http://yourdomain.com/twig/twig/test/some_file.php
What you want is more like this:
/path/to/project
/public
index.php
/lib
foo.php
bar.php
/twig
/twig
/doc
/test
Then configure your web server so that its document root is /path/to/project/public. Then your application code can still include() things in /twig and /lib, but your web server won't directly serve them.
If your removing files from the vendor directory they'll come back the next time you do a composer install so this seems kind of pointless.
The files you mention (docs and test) are causing no harm other than taking up space as they are not directly called, but that's just a downside to any package management system. Like #Alex said as long as they are not publicly accessible there is no need to worry.
If you really want Twig without the extra files you could fork the project, move it into your own Git repo then reference that in your composer.json instead of the official one - but you will miss out on any updates from Twig.
We're running on Apache, so the easiest solution was to simply add a .htaccess file to the top vendor directory:
# Prevent non-local access to the vendor directory.
Order deny,allow
Deny from all
Directory structure:
/root
/vendor
.htaccess
/twig
...
/includes
...
Now the PHP scripts continue to have access, but external attempts to view anything inside the vendor directory return a 403 error.
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.
Which folders should I ignore when using version control on a project developed on the CodeIgniter framework?
I am already ignoring the application/cache folder, but are there any else?
You can ignore any application generated logs and any development specific configuration files. Here's a commonly used .gitignore file for CodeIgniter:
*/config/development
*/logs/log-*.php
*/logs/!index.html
*/cache/*
*/cache/!index.html
https://github.com/github/gitignore/blob/master/CodeIgniter.gitignore
Beyond the default github codeigniter template provided by birderic, (at https://github.com/github/gitignore/blob/master/CodeIgniter.gitignore for good measure) I also like to simply exclude any php file in the /config director with
*/config/*.php
Some third party apps, like HybridIgnite, like to put their configuration files in the /config directory and a limited config block might enable on of these files to be tracked... Better safe than sorry...
To make it clear how config files should work, I keep a copy of the default files (with no passwords of course) in a seperate config_template directory.
HTH,
-FT
My application path looks like this: home/webadmin/problemio.com/html
In fact, I output it here on the test url: http://www.problemio.com
I installed CakePHP into the /problemio.com directory, but should it live one down at the root of the application, in the /html directory?
Thanks!
Also, I just moved the cakephp install to the root dir, and I got all these errors there:
Here is how it looks like: http://www.problemio.com/cakephp/
Btw, should I just rename that dir as my application name, and put my index.php in that dir instead of the root?
Your webroot should be set to /home/webadmin/problemio.com/html/cakephp/app/webroot
Your app basically is in the /home/webadmin/problemio.com/html/cakephp/app/ (you modify files only in this directory and subdirecetories)
/home/webadmin/problemio.com/html/cakephp/cake is where cakephp framework code lives and you should not alter any code there as it's 3rd party code.
Read more about folder structure here.
you have set up cake correctly, the errors here are not errors, just warnings. To get rid of them do the following.
1) set recursively cakephp/app/temp permissions to 775 or 777
2) go to cakephp/app/config/core.php and change security salt and security cipher seed.
3) go to cakephp/app/config and create database.php (you have a model there) and configure your database.
4) the last error, you have to reinstall the pcre... (sometimes you won't be able to do it but it may not affect you)
i suggest you follow Janis Veinbergs answer for a correct setting of the folders. The actual configuration works... just some warnings
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!)