Difference between revisions of "Directory Hierarchy"
m (Fixed typos) |
|||
| (8 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | By [[User:Amckay|Alan McKay]] | |
| − | + | These are currently just notes but soon I'll be organising them into a general discussion on the way i manage my Geeklog installations. While I do not yet have a (mostly) fully-automated means of administering many Geeklog sites, I have finally put together an organisational mechanism which will eventually allow me to write a collection of automated PHP scripts to do the rest for me. | |
| − | + | == Path To Geeklog == | |
| − | + | Have a look at all of the paths in config.php which are based on /path/to/geeklog, and realise that any of these should be movable anywhere, and Geeklog will still work fine. Plugin writers should note this as well - most of my own plugins do not adhere to this standard, and break. Though my latest "books" plugin should work fine. | |
| − | + | == Multi-Domain Directory Structure == | |
| − | On my server all domains live at /home/username/domains/hostname.example.com/, and | + | On my server all domains live at /home/username/domains/hostname.example.com/, and Geeklog is always at /home/username/domains/hostname.example.com/htdocs/geeklog-x.ysrz. I also maintain under that a /home/username/domains/hostname.example.com/vdirs/ into which all virtual directories go. So plugins should ideally go into /home/username/domains/hostname.example.com/vdirs/gl-plugins/pluginname/public_html, the latter of which maps to <nowiki>http://www.example.com/pluginname/</nowiki>. You have to use similar webserver tricks to map in any admin, layout or other parts of the plugin which may be included (depends on the plugin). Always ask the plugin author if unsure whether it will work like this. But any good plugin should adhere to those GL base system variables. |
| − | -- | + | Note that I actually maintain /path/to/geeklog-version and then use a Linux symlink to point to /path/to/geeklog, and my webserver config file points /path/to/geeklog (the symlink). Since I never put any plugins or other non-default data into this file space, it makes it very easy to upgrade my version of Geeklog without having to worry too much about plugin files and other 'foreign' data. |
| − | + | === Plugin Versions === | |
| − | + | My setup is actually a bit more complex than above, I just wanted to separate this out into it's own little subsection. Instead of /path/to/gl-plugins/pluginname/, I actually do /path/to/gl-plugins/pluginname-version and then use a symbolic link to point to /path/to/gl-plugins/pluginname, which is what the web server points to. This way you can keep many older versions around between upgrades of various plugins, and just use symlinks to link in the current version into the web space. | |
| − | The following entry is from /etc/httpd.conf on my main brewing | + | === And So On === |
| + | |||
| + | Similarly, any directory where you want to store anything at all which is not part of the base Geeklog distribution, you should map into the web space virtually with your webserver. This will make life so easy for upgrades you'll thank yourself many times over for taking a bit of time up front to do it. | ||
| + | |||
| + | == Webserver Tricks == | ||
| + | |||
| + | === Apache 2.x === | ||
| + | |||
| + | Use the webserver's virtual-directory capabilities to map all plugin files into the main Geeklog directory. That means that when you are logged into the =bash= prompt, your files will be at the well-known /path/to/geeklog, which coresponds to <nowiki>http://www.example.com/</nowiki> in the web space. | ||
| + | |||
| + | The following entry is from /etc/httpd.conf on my main brewing website http://www.bodensatz.com/ | ||
<pre> | <pre> | ||
Alias /filemgmt_data/ "/home/bodensatz/vdirs/filemgmt_data/" | Alias /filemgmt_data/ "/home/bodensatz/vdirs/filemgmt_data/" | ||
</pre> | </pre> | ||
| + | |||
| + | This does not follow my own naming convention simply because it was put in place before I started doing things that way. Never bothered to update it. | ||
more to come ... 2006.09.14 | more to come ... 2006.09.14 | ||
| − | |||
| − | |||
Latest revision as of 12:29, 27 May 2009
By Alan McKay
These are currently just notes but soon I'll be organising them into a general discussion on the way i manage my Geeklog installations. While I do not yet have a (mostly) fully-automated means of administering many Geeklog sites, I have finally put together an organisational mechanism which will eventually allow me to write a collection of automated PHP scripts to do the rest for me.
Contents
Path To Geeklog
Have a look at all of the paths in config.php which are based on /path/to/geeklog, and realise that any of these should be movable anywhere, and Geeklog will still work fine. Plugin writers should note this as well - most of my own plugins do not adhere to this standard, and break. Though my latest "books" plugin should work fine.
Multi-Domain Directory Structure
On my server all domains live at /home/username/domains/hostname.example.com/, and Geeklog is always at /home/username/domains/hostname.example.com/htdocs/geeklog-x.ysrz. I also maintain under that a /home/username/domains/hostname.example.com/vdirs/ into which all virtual directories go. So plugins should ideally go into /home/username/domains/hostname.example.com/vdirs/gl-plugins/pluginname/public_html, the latter of which maps to http://www.example.com/pluginname/. You have to use similar webserver tricks to map in any admin, layout or other parts of the plugin which may be included (depends on the plugin). Always ask the plugin author if unsure whether it will work like this. But any good plugin should adhere to those GL base system variables.
Note that I actually maintain /path/to/geeklog-version and then use a Linux symlink to point to /path/to/geeklog, and my webserver config file points /path/to/geeklog (the symlink). Since I never put any plugins or other non-default data into this file space, it makes it very easy to upgrade my version of Geeklog without having to worry too much about plugin files and other 'foreign' data.
Plugin Versions
My setup is actually a bit more complex than above, I just wanted to separate this out into it's own little subsection. Instead of /path/to/gl-plugins/pluginname/, I actually do /path/to/gl-plugins/pluginname-version and then use a symbolic link to point to /path/to/gl-plugins/pluginname, which is what the web server points to. This way you can keep many older versions around between upgrades of various plugins, and just use symlinks to link in the current version into the web space.
And So On
Similarly, any directory where you want to store anything at all which is not part of the base Geeklog distribution, you should map into the web space virtually with your webserver. This will make life so easy for upgrades you'll thank yourself many times over for taking a bit of time up front to do it.
Webserver Tricks
Apache 2.x
Use the webserver's virtual-directory capabilities to map all plugin files into the main Geeklog directory. That means that when you are logged into the =bash= prompt, your files will be at the well-known /path/to/geeklog, which coresponds to http://www.example.com/ in the web space.
The following entry is from /etc/httpd.conf on my main brewing website http://www.bodensatz.com/
Alias /filemgmt_data/ "/home/bodensatz/vdirs/filemgmt_data/"
This does not follow my own naming convention simply because it was put in place before I started doing things that way. Never bothered to update it.
more to come ... 2006.09.14
