Difference between revisions of "Directory Hierarchy"

From GeeklogWiki
Jump to: navigation, search
m (Fixed typos)
 
(8 intermediate revisions by one other user not shown)
Line 1: Line 1:
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 may 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.
+
By [[User:Amckay|Alan McKay]]
  
%TOC%
+
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
+
== Path To Geeklog ==
  
  * have a look at all of the variables 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.
+
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
+
== 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.
+
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.
  
---+ Websever Tricks
+
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.
  
---++ Apache 2.x
+
=== Plugin Versions ===
  
Use the webserver's virtual-directory capabilities to map all plugin files into the main geeklog directoryThat means that when you are logged into the =bash= prompt, your files will be at the well-known /path/to/geeklog, which cooresponds to http://www.example.com/ in the web space.
+
My setup is actually a bit more complex than above, I just wanted to separate this out into it's own little subsectionInstead 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 webside http://www.bodensatz.com/
+
=== 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
 
p.s. it seems this is not the same markup as Twiki.  If anyone knows both wikis and wants to translate this spage before i get time to do so, it would be appreciated.
 

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.

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