As some of you may know, I’m now employed full-time at a computer firm doing web design and program work (I have more to say on this, but I’ll keep that for a later post). It’s a Drupal-heavy shop (with a significant though minor WordPress presence). Because of this switch for me, I’ve been wanting to re-organise my development directories to isolate projects from one another so that the git repo has only files relevant to the actual project (i.e. why keep up with WordPress files when they’re easily available?) and that my local test environment has access to all project files (e.g. I’ve set up a WordPress test site at wordpress.lan which can access all of my WP-related projects).
In addition to this desire (nay, necessity), I’ve also made a switch from using Kdevelop (which I love) to using Eclipse. This is mainly so that I can utilise Xdebug straight from my IDE (which is very handy). Because Eclipse likes to use different directories for its projects, I thought I would incorporate this into my changes.
As a result, I’ve done the following:
- Everything is located within ~/workspace (still)
- There are three special directories: archives (for old projects), sources (for upstream sources, like jQuery plugins, which can be used in multiple projects), and [workname] (for all projects with my new job — though I hope to integrate this into my regular schema)
- In addition to the special ‘root’ directories, there are regular project-area directories: joomla, drupal, wordpress, interlude, laravel, android, and openframeworks.
- Within each project-area directory, there is a single special directory (sources) where I place anything I do not maintain there (e.g. core Joomla distribution, third party plugins, etc) in both directory and zip/tarball (in case I’ve changed anything). For example, my WordPress sources directory has a wordpress directory along with buddypress, debug-bar, etc. I have a global Git ignore directive for the sources directory so that none of these appear in my repo. These ignore directives are in addition to any kind of sensitive data (e.g. config files) and user-generated data (caches, uploads, etc).
- Beside the sources directory, I have directories for each of my own projects (a lot in WordPress: media-libraries, adjunct-db, activists-without-lobbies, etc). Each of those directories are separate Git repos (and most are available on GitHub).
- Within the [project-area]/sources/[project-area]/ directory, I add symlinks in the proper locations for my own projects (all WP plugins are symlinked in sources/wordpress/wp-content/plugins/*) so that when I load the test site, I can access them.
- Apache is configured somewhat logically as domains using the .lan TLD (e.g. wordpress.lan, joomla.lan, drupal.lan, etc) to point to the [project-area]/sources/[project-area]/ directory. Xdebug is also configured to work here.
- MySQL is also configured for easy usage. I use a single test user (e.g. test) which has a wildcard access to all databases prefixed by that name (so test_joomla and test_wordpress are automatically accessible by the test user). I use a silly password (it’s my dev environment so I don’t really need anything more secure than “pleasework”).
As I mentioned above, I’ve switched to using Eclipse. I’ve set up a number of workspaces within Eclipse that reflect the organisation above: each workspace is dedicated to a particular project area, and I’ve created workspace projects within that workspace for each of my projects in addition to the [project-area] source and any major third party extensions which I use often (mainly for faster reference).
Lastly, I’ve switched to using the git-flow branching method (and I’m slowly migrating everything I’m still actively working with to this). Being able to use Xdebug from the IDE is all the more possible with this methodology because I am no longer worried about committing to the repo a debugging echo (or var_dump, printf, etc) — all of that data is available using the debugger. Now, every commit is useful (though I still need to work on committing more often).