Regularly develop projects in PHP using Dreamweaver but I would start using Eclipse.
I have my machine in a directory where they are armaezandos projects, but also a place where projects are published in apache.
In Dreamweaver in the project settings I map the local directory, setting to perform the sending of files to the apache automatically after you save them.
I wonder what the correct way to develop with Eclipse.
If I map the project directly in the apache directory (thus having only one copy of the project) or if the Eclipse has some configuration to achieve the same functionality I have in Dreamweaver.
Another problem is that when mapping the project directly in Eclipse are created folders and files .settings, .buildpath and .project.
Note: Keep copies of two projects (one local and one in apache) for the purpose of tests not send files, uploads, etc. in memoento that you publish the project, and sending only the project folder location.
I use Eclipse Helios.
I use Apatana based off of Eclipse, pretty much the same way when storing projects. However I map my virtual hosts files to my project folders. I also keep revision control through Subversion so if any hiccups occur they can immediately be fixed. Just map your Apache Virtual Hosts files to your project folders.
Related
I want to deploy my Laravel project which has a Per-project Homestead inside it (not the global homestead). Some Vagrant and all Homestead files are included inside my Laravel project. This is the first time I'm deploying a Laravel application, and I really cannot find any information about files and folders that may be excluded from the deployment (Especially for a project with a per-project Homestead inside it).
I guess, .vagrant, tests, .env.example, .gitattributes, .gitignore, after.sh, aliases, Homestead.yaml, phpunit.xml, readme.md, and Vagrantfile files and folders may be excluded. Am I right? And what about the vendor folder (There are some Vagrant, Homestead files inside, as well, like e.g. homestead, homestead.bat inside the vendor/bin folder, or the whole homestead folder inside vendor/laravel).
Ideally, you would use a VPS or deployment server like DigitalOcean. However, as you stated you are using a shared server, the directories/files you will need to upload to the root directory of your server account are:
app/*
bootstrap/*
config/*
database/*
public_html/*
resources/*
routes/*
storage/*
vendor/*
.env
The remaining .files are for dependency management and development tests, and since you likely won't be using any build processes or Continuous Integration on a shared server, you won't need them.
Note: make sure these are in the root directory and the only publicly accessible directory is public_html. By default, shared hosting servers already have this restriction. Uploading the Laravel project as you have it will overwrite the website's current public_html directory, so make sure to back up anything you may have there currently.
Update
Frameworks like Laravel are designed to use root/command-line access to assist with deployment and server management. This is the advantage of frameworks. Shared servers do not typically allow users root access, so you end up having issues like yours, where deployment is a manual upload instead of a CLI command through version control.
vendor contains all of the dependencies your app is relying on to operate (Eloquent, Doctrine, Flysystem, etc.), so it won't work without the vendor directory.
You should deploy from version control, and by default that should exclude .vagrant and Homestead.yaml everything else is safe to leave in.
I have been using Eclipse for Remote System Development and after hearing a lot of good things about Netbeans for PHP development, I wanted to give it a shot.
I ran into couple of issues even before starting:
1. Downloading complete remote directory to my local machine:
I work on multiple projects located on a development server and the code base is pretty huge. While setting up new PHP remote project using sftp to access my remote directories, Netbeans started downloading all the files from the remote location I specified. This is a bit annoying as it is taking really long to download all the files (includes large videos which are part of the projects).
Eclipse remote system development (and most other editors like EditPlus), on the other hand, simply shows me the remote file structure and only downloads a file to local temp dir when I open it.
Is this behavior standard in Netbeans?
2. Will external file modifications cause sync issues?
I usually update my svn by connecting to the dev server using putty. Since Netbeans is trying to maintain a copy of it's own on my local computer, will updating the source files externally outside netbeans create sync issues?
3. Can I manage remote svn repos from within Netbeans?
Since I already checked-out my svn projects on the dev server, can I use svn from within netbeans to commit or update?
Yes, it is standard. Netbeans downloads the remote application so that it can scan the local copies to enable code-completion.
It shouldn't. By default, Netbeans is almost immediately aware of any changes you make to project files outside of Netbeans.
Yes.
Basically I've got various projects all version controlled using subversion. This is for many reasons: backup of files in case of bugs/issues in the future; backup of files in case of local system failure etc; collaboration from others in the company; etc..
One of the systems we work with is Wordpress which does updates and installs plugins through its administration panel and such, plus on installing it the system creates various files (including a wp-config.php file and a .htaccess file). This means that on install there are files on the server integral to the running of the system which aren't on the local systems and aren't in svn. Plus any installed plugins and updates aren't mirrored in version control or the local copy.
Plus it feels wrong (specifically when you compare with data normalisation in databases and such) to be working with two copies of the same code - one in version control and one on the server.
So my question is am I using the tools in the right way? Is there any way that the public_html folder from the server can "point" to the latest version in the repo? Or can SVN be configured to read from the public_html folder and automatically add+commit any files created/edited on the server?
Or do people just literally download anything that gets changed/created and add them to SVN manually? Or do people not care? Maybe I've misinterpreted what SVN is for? I'm using it for backup effectively.
Thanks
Tom
I only have versioned my own wordpress theme. All the other stuff including the data is live on the server and solely backuped from there.
The code of wordpress and the plugins used are developed elsewhere, they have their own repositories, and i do not mess mine with code I never will touch.
The question is how to deal with configurations. I am currently running a wiki where I document all the plugins installed live and what configuration properties I have set up.
A sync of live to local then goes like this:
Update wordpress version and plugins to the versions written in the wiki
Setting all configuration options as written in the wiki.
Importing the data base (except wp_options). Converting the static URL of wp_content files to the local scheme.
Syncronisation of the wp_content directory
In many cases your hosting provides regular backup. But is you use VPS you have more freedom to do whatever you want. I have made my public_html folder under version control and created a small script to commit every night. So I can have a complete version history of my site with changes traced. You can also create a script just to copy this folder elsewhere. There may be other better solutions for enterprises, but this may be enough for small project.
What is the best way to deal with config / directory / OS differences using SVN to develop and deploy on 2 different platforms?
I am developing in Windows and deploying to Linux.
I'd like to use my home PC to test the files before using commit, I'm using a web framework and you must specify the paths to your system and application files for the framework. Obviously those are different on the 2 machines.
I have the option of using a linux server at home, as a last resort. I really like working with SVN using a GUI right now since I am new to SVN web development.
So what would be the best solution to config differences between my development and live servers?
There has got to be an easier way then changing the file everytime I commit it to the live server, which is really against what SVN is trying to accomplish in the first place.
One option is to keep the configuration files out of the repository - set them up on their own for both your local and server machines, and then don't touch them again unless you have to. (Using the svn-ignore: property can keep you from accidentally adding the config files to the repository later on.)
Another option is to try to use relative paths and then have the config/etc directories be in the same relative location to the working directory, even if they're not in the same absolute locations.
You can set a svn-prop (property) to ignore the config file. Forcing you to create one (manually or generated) specific to every installation.
I'm learning Eclipse PDT for PHP development. In pretty much all tutorials I've read they put the eclipse workspace inside the document root of the webserver (htdocs in my case).
Is this common practice? I mean; I don't like the configuration files on my (test) webserver. Isn't there a way to publish the changes to webserver's folder from the workspace elsewhere on the filesystem?
You can have the workspace in one directory, and projects in any other directories you'd like (not necessarily sub-directories of the workspace).
The location you specify as "workspace location" is the place where some configuration files (internal to eclipse) will be stored, I believe.
On my (Linux) machine, I have :
the workspace location in /home/squale/bin/eclipse-workspaces/1
projects are in /home/squale/developpement/ :
aggregator
php-src-5.3
...
On my Windows machine at work, I have :
workspace location is something like d:\bin\eclipse-workspaces\pdt-1\
I have a project on a hard disk (like d:\projects\project1 )
And another project on a network drive (which points to a Linux server, through samba)
That way, too, workspace files are in a really separate directory, not deployed to any server, and not in the SVN's checkout structure or even near it.
Putting the workspace inside the docroot is maybe easier, but works only if you have one virtual host, anyway (and not a couple of projects, so).
With older versions of Eclipse, sometimes, when Eclipse crashed, the workspace was totally corrupted, and had to be deleted ; not habing the projects' files in sub-directories of the workspace was really useful, by then.
You can also try setting up a local repository and using svn:externals, tho' I'm not a pro at knowing how to set those up.