Directory Hierarchy - Revision history

Dirk: Fixed typos

2009-05-27T12:29:07Z

Fixed typos

Amckay: /* Path To Geeklog */

2006-09-14T23:18:58Z

‎Path To Geeklog

Amckay: /* Apache 2.x */

2006-09-14T23:06:35Z

‎Apache 2.x

Amckay: /* Multi-Domain Directory Structure */

2006-09-14T23:05:08Z

‎Multi-Domain Directory Structure

Amckay: /* Multi-Domain Directory Structure */

2006-09-14T23:03:04Z

‎Multi-Domain Directory Structure

Amckay at 22:57, 14 September 2006

2006-09-14T22:57:39Z

Amckay: /* Apache 2.x */

2006-09-14T22:55:35Z

‎Apache 2.x

Amckay: /* Path To Geeklog */

2006-09-14T22:55:16Z

‎Path To Geeklog

Amckay at 22:54, 14 September 2006

2006-09-14T22:54:36Z

Amckay at 22:44, 14 September 2006

2006-09-14T22:44:49Z

@@ 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.
+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 ==
@@ Line 9: / Line 9: @@
 == 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.
 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.
@@ Line 19: / Line 19: @@
 === And So On ===
-Similary, 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.
+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.
-== Websever Tricks ==
+== 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 cooresponds to http://www.example.com/ in the web space.
+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 webside http://www.bodensatz.com/
+The following entry is from /etc/httpd.conf on my main brewing website http://www.bodensatz.com/
 <pre>
@@ Line 33: / Line 33: @@
 </pre>
-This does not follow my own naming convention simply becausee it was put in place before I started doing things that way.  Never bothered to update it.
+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

@@ Line 5: / Line 5: @@
 == 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 ==

← Older revision		Revision as of 23:06, 14 September 2006
Line 33:		Line 33:
	</pre>		</pre>

		+	This does not follow my own naming convention simply becausee 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

← Older revision		Revision as of 23:05, 14 September 2006
Line 10:		Line 10:

	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 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 ===		=== Plugin Versions ===

← Older revision		Revision as of 23:03, 14 September 2006
Line 10:		Line 10:

	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 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.
		+
		+	=== 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 ===

	Similary, 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.		Similary, 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.

← Older revision		Revision as of 22:55, 14 September 2006
Line 24:		Line 24:

	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.~~

← Older revision		Revision as of 22:44, 14 September 2006
Line 24:		Line 24:

	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.