GeeklogWiki - User contributions [en]

Using Mercurial

2008-11-14T08:06:36Z

THEMike: /* Windows Users - Secret Sauce (if you have commit rights) */

== Introduction ==

[http://www.selenic.com/mercurial/ Mercurial] is a distributed version control system (DVCS). The differences to a "traditional" centralized VCS (like CVS or Subversion) include:

* Users get a self-contained repository that they can commit changes to, even when being offline.
* Changes can be pushed back to the parent repository or even to other repositories.

Having used CVS since its inception, Geeklog switched to Mercurial after the release of Geeklog 1.5.1. This switch was preceded by an successful experiment using Mercurial during the 2008 [[Google Summer of Code]]. The distributed model did fit this scenario nicely, as each of our students was working on a separate feature. So they had a local repository to check in to (giving them all the benefits of a version control system). Once a feature or part of a feature was done, it could be pushed back to the parent repository. And in the meantime, it was easy to let other people, e.g. their mentor or interested members of the Geeklog community, pull the changes from the student's repository to show things off or get help on a problem.

== Installing Mercurial ==

Installation instructions are provided for [http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall Windows], [http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall Mac OS X], and [http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall Linux]

== Setup ==

Geeklog's Mercurial repository is available from this URL:

: http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/

This repository was converted from the CVS repository right after the release of [http://www.geeklog.net/article.php/geeklog-1.5.1 Geeklog 1.5.1].

To create a copy of that repository, simply do

<pre>hg clone http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/ geeklog</pre>

Where the last "geeklog" is just a directory name for the local copy (and can be changed at will). This will give you a fully working local repository that you can commit changes to.

'''Note:''' The same URL can also be used to browse the repository online. Simply visit that URL with your web browser.

=== SSH Setup ===

For ssh access, you need an account on the server. So this is only of interest for the core developers and SoC students.

You can clone the repository via SSH like so:

<pre>hg clone ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog geeklog</pre>

Where "username" is your login name and the "geeklog" at the end of the command line is again simply a name for your local directory.

Please note the slightly odd path syntax with the two slashes after <tt>cvs.geeklog.net</tt> - those are required.

== Pushing back ==

Being able to push changes back to the repository again requires an account on the server. You can either do

<pre>hg push ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog</pre>

or, to make your life easier, set the <tt>default-push</tt> repository in the <tt>.hg/hgrc</tt> file of your local repository like so:

<pre>[paths]
default-push = ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog</pre>

(Again, in the ssh: URLs above, replace "username" with your login name)

=== Trust and Notifications ===

Changes pushed back into the central repository will trigger an email sent to the geeklog-cvs mailing list. However, that email will only be sent after the following additional steps:

# log into your account on cvs.geeklog.net
# in your home directory, create a file named <tt>.hgrc</tt>
# enter this as the file's content:
<pre>[trusted]
users = geeklog2
groups = users</pre>

This will also get rid of warnings like
: remote: Not trusting file (...) from untrusted user geeklog2, group users
when pushing back changes.

== GSoC Repository ==

The repository used during the 2008 Google Summer of Code is still available from

: http://project.geeklog.net/cgi-bin/hgwebdir.cgi/gsoc-2008/

Note that both the URL and the repository name have changed (formerly <tt>Geeklog-SoC</tt>). You can still use your local copies of that repository - you only need to update the <tt>default-push</tt> setting to the new address and name.

== Best practices ==

Since we're all new to Mercurial, this is something we will have to establish as we go along. For starters, the [http://www.selenic.com/mercurial/wiki/ Mercurial Wiki] has a page on [http://www.selenic.com/mercurial/wiki/index.cgi/WorkingPractices Working Practices] that we may want to adopt.

=== Use a clean incoming repository ===

Pull changes to a local "incoming" repository but don't work on that repository. Cloning that repository locally is a cheap operation and allows you to easily create multiple copies if necessary, e.g. when working on different features in parallel.

Push directly from your working repositories, then sync back by pulling the changes back down via your incoming repository.

=== Merging ===

If you attempt to push changes to the main repository and receive the error:
pushing to ssh://username@cvs.geeklog.net//cvsroot/geeklog/Geeklog-SoC
searching for changes
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)
Simply pull from the main repository, "hg heads" to see the revision numbers, "hg merge [rev number]" to merge your changes, then commit the changes, and push back to the main repository.

Also: Don't try to push newly added files while you still have uncommited changes lying around (or you will end up with the above). In that case, it may make sense to make a fresh clone (fast + cheap if you use an "incoming" repository!), add the new files there, then push from the fresh copy.

=== Username ===

When committing a change, the username associated with that change will be your local username (login, etc.) - ''not'' the name of your account on the server.

For a consistent username, add your preferred username to your local <tt>.hgrc</tt> file:
<pre>username = John Doe <john@example.com></pre>
The email address is optional.

''(More tips and tricks to be added here)''

== Undoing Changes ==

To undo changes you made, use one of the following, depending on circumstances:

* <tt>hg revert</tt> to revert changes made before a commit. This will also undo <tt>hg add</tt> and <tt>hg remove</tt>.
* <tt>hg rollback</tt> to revert changes that have been commited to the local repository but not been pushed to another repository yet. You can only rollback the last hg command.
* <tt>hg backout</tt> to revert changes after they have been commited ''and'' pushed.

Note that <tt>hg backout</tt> will actually add a new change to the current branch that reverts your previous change. I.e. your change will ''not'' be removed from the repository. Unless you've accidentally committed something super-secret, that's usually fine. Mistakes happen - no need to sweat it.

== Documentation ==

The [http://www.selenic.com/mercurial/wiki/ Mercurial Wiki] is a good place to search for information. For starters, however, [http://hgbook.red-bean.com/ Distributed revision control with Mercurial] aka "the hg book" is a much better place to start. This book is available for download under the Open Publication License.

Here's the entirely subjective "The Impatient's Guide to the HG Book":

* Chapter 1: Introduction Skip if you already know about VCS and DVCS
* Chapter 2: A tour of Mercurial: the basics Everything from section 2.2 on is '''recommended reading'''. The essential things you need to know to use Mercurial.
* Chapter 3: A tour of Mercurial: merging work Title says it all - '''recommended reading'''
* Chapter 4: Behind the scenes Feel free to skip
* Chapter 5: Mercurial in daily use Despite the title, this chapter seems more confusing than helpful - skip
* Chapter 6: Collaborating with other people Section 6.2 is '''recommended reading''' once you've mastered the basics
* Chapter 7: File names and pattern matching Nothing surprising here - skip
* Chapter 8: Managing releases and branchy development Advanced topic but useful
* Chapter 9: Finding and ﬁxing your mistakes Very useful (but skip sections 9.5 and 9.6)
* You can effectively stop reading after Chapter 9.
* Appendix A may be useful as a reference.

[[Category:Development]]

== Windows Users - Secret Sauce (if you have commit rights) ==

I'm using command line Mercurial (I don't like the windows explorer performance hit of the tortoise system). But this works for me, after much messing around.

# Clone the main Geeklog repository, as above. (geeklog-hg)
# Clone your local copy of Geeklog to give yourself a clean working environment. (geeklog-hg-mine)
# Clone your clean working environment ;-) (geeklog-hg-dev)
# Update /path/to/geeklog-hg/.hg/hgrc to match bellow
# Update /documents and settings/[your user]/mercurial.ini to match the other bellow

And that works.

For hgrc:

[paths]
default = ssh://[your username]@cvs.geeklog.net//cvsroot/hg/geeklog

For mercurial.ini:

[ui]
ssh = c:/path/to/putty/plink.exe -ssh -v -l [your username] -pw [your password]
username = [your name] <[your email address]>

So I develop in geeklog-hg-dev, then I winmerge my changes back into geeklog-hg-mine to make sure I never accidentally commit localsettings (paths etc) or hacks, debugs. Then I commit to geeklog-hg-mine, then back to geeklog-hg when that's ready, then push up to master. Complex hey? ;-)

Using Mercurial

2008-11-14T08:05:22Z

THEMike: /* Windows Users - Secret Sauce (if you have commit rights) */

== Introduction ==

[http://www.selenic.com/mercurial/ Mercurial] is a distributed version control system (DVCS). The differences to a "traditional" centralized VCS (like CVS or Subversion) include:

* Users get a self-contained repository that they can commit changes to, even when being offline.
* Changes can be pushed back to the parent repository or even to other repositories.

Having used CVS since its inception, Geeklog switched to Mercurial after the release of Geeklog 1.5.1. This switch was preceded by an successful experiment using Mercurial during the 2008 [[Google Summer of Code]]. The distributed model did fit this scenario nicely, as each of our students was working on a separate feature. So they had a local repository to check in to (giving them all the benefits of a version control system). Once a feature or part of a feature was done, it could be pushed back to the parent repository. And in the meantime, it was easy to let other people, e.g. their mentor or interested members of the Geeklog community, pull the changes from the student's repository to show things off or get help on a problem.

== Installing Mercurial ==

Installation instructions are provided for [http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall Windows], [http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall Mac OS X], and [http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall Linux]

== Setup ==

Geeklog's Mercurial repository is available from this URL:

: http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/

This repository was converted from the CVS repository right after the release of [http://www.geeklog.net/article.php/geeklog-1.5.1 Geeklog 1.5.1].

To create a copy of that repository, simply do

<pre>hg clone http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/ geeklog</pre>

Where the last "geeklog" is just a directory name for the local copy (and can be changed at will). This will give you a fully working local repository that you can commit changes to.

'''Note:''' The same URL can also be used to browse the repository online. Simply visit that URL with your web browser.

=== SSH Setup ===

For ssh access, you need an account on the server. So this is only of interest for the core developers and SoC students.

You can clone the repository via SSH like so:

<pre>hg clone ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog geeklog</pre>

Where "username" is your login name and the "geeklog" at the end of the command line is again simply a name for your local directory.

Please note the slightly odd path syntax with the two slashes after <tt>cvs.geeklog.net</tt> - those are required.

== Pushing back ==

Being able to push changes back to the repository again requires an account on the server. You can either do

<pre>hg push ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog</pre>

or, to make your life easier, set the <tt>default-push</tt> repository in the <tt>.hg/hgrc</tt> file of your local repository like so:

<pre>[paths]
default-push = ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog</pre>

(Again, in the ssh: URLs above, replace "username" with your login name)

=== Trust and Notifications ===

Changes pushed back into the central repository will trigger an email sent to the geeklog-cvs mailing list. However, that email will only be sent after the following additional steps:

# log into your account on cvs.geeklog.net
# in your home directory, create a file named <tt>.hgrc</tt>
# enter this as the file's content:
<pre>[trusted]
users = geeklog2
groups = users</pre>

This will also get rid of warnings like
: remote: Not trusting file (...) from untrusted user geeklog2, group users
when pushing back changes.

== GSoC Repository ==

The repository used during the 2008 Google Summer of Code is still available from

: http://project.geeklog.net/cgi-bin/hgwebdir.cgi/gsoc-2008/

Note that both the URL and the repository name have changed (formerly <tt>Geeklog-SoC</tt>). You can still use your local copies of that repository - you only need to update the <tt>default-push</tt> setting to the new address and name.

== Best practices ==

Since we're all new to Mercurial, this is something we will have to establish as we go along. For starters, the [http://www.selenic.com/mercurial/wiki/ Mercurial Wiki] has a page on [http://www.selenic.com/mercurial/wiki/index.cgi/WorkingPractices Working Practices] that we may want to adopt.

=== Use a clean incoming repository ===

Pull changes to a local "incoming" repository but don't work on that repository. Cloning that repository locally is a cheap operation and allows you to easily create multiple copies if necessary, e.g. when working on different features in parallel.

Push directly from your working repositories, then sync back by pulling the changes back down via your incoming repository.

=== Merging ===

If you attempt to push changes to the main repository and receive the error:
pushing to ssh://username@cvs.geeklog.net//cvsroot/geeklog/Geeklog-SoC
searching for changes
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)
Simply pull from the main repository, "hg heads" to see the revision numbers, "hg merge [rev number]" to merge your changes, then commit the changes, and push back to the main repository.

Also: Don't try to push newly added files while you still have uncommited changes lying around (or you will end up with the above). In that case, it may make sense to make a fresh clone (fast + cheap if you use an "incoming" repository!), add the new files there, then push from the fresh copy.

=== Username ===

When committing a change, the username associated with that change will be your local username (login, etc.) - ''not'' the name of your account on the server.

For a consistent username, add your preferred username to your local <tt>.hgrc</tt> file:
<pre>username = John Doe <john@example.com></pre>
The email address is optional.

''(More tips and tricks to be added here)''

== Undoing Changes ==

To undo changes you made, use one of the following, depending on circumstances:

* <tt>hg revert</tt> to revert changes made before a commit. This will also undo <tt>hg add</tt> and <tt>hg remove</tt>.
* <tt>hg rollback</tt> to revert changes that have been commited to the local repository but not been pushed to another repository yet. You can only rollback the last hg command.
* <tt>hg backout</tt> to revert changes after they have been commited ''and'' pushed.

Note that <tt>hg backout</tt> will actually add a new change to the current branch that reverts your previous change. I.e. your change will ''not'' be removed from the repository. Unless you've accidentally committed something super-secret, that's usually fine. Mistakes happen - no need to sweat it.

== Documentation ==

The [http://www.selenic.com/mercurial/wiki/ Mercurial Wiki] is a good place to search for information. For starters, however, [http://hgbook.red-bean.com/ Distributed revision control with Mercurial] aka "the hg book" is a much better place to start. This book is available for download under the Open Publication License.

Here's the entirely subjective "The Impatient's Guide to the HG Book":

* Chapter 1: Introduction Skip if you already know about VCS and DVCS
* Chapter 2: A tour of Mercurial: the basics Everything from section 2.2 on is '''recommended reading'''. The essential things you need to know to use Mercurial.
* Chapter 3: A tour of Mercurial: merging work Title says it all - '''recommended reading'''
* Chapter 4: Behind the scenes Feel free to skip
* Chapter 5: Mercurial in daily use Despite the title, this chapter seems more confusing than helpful - skip
* Chapter 6: Collaborating with other people Section 6.2 is '''recommended reading''' once you've mastered the basics
* Chapter 7: File names and pattern matching Nothing surprising here - skip
* Chapter 8: Managing releases and branchy development Advanced topic but useful
* Chapter 9: Finding and ﬁxing your mistakes Very useful (but skip sections 9.5 and 9.6)
* You can effectively stop reading after Chapter 9.
* Appendix A may be useful as a reference.

[[Category:Development]]

== Windows Users - Secret Sauce (if you have commit rights) ==

I'm using command line Mercurial (I don't like the windows explorer performance hit of the tortoise system). But this works for me, after much messing around.

# Clone the main Geeklog repository, as above. (geeklog-hg)
# Clone your local copy of Geeklog to give yourself a clean working environment. (geeklog-hg-mine)
# Clone your clean working environment ;-) (geeklog-hg-dev)
# Update /path/to/geeklog-hg/.hg/hgrc to match bellow
# Update /documents and settings/[your user]/mercurial.ini to match the other bellow

And that works.

For hgrc:

<code>
[paths]
default = ssh://[your username]@cvs.geeklog.net//cvsroot/hg/geeklog
</code>

For mercurial.ini:
<code>
[ui]
ssh = c:/path/to/putty/plink.exe -ssh -v -l [your username] -pw [your password]
username = [your name] <[your email address]>
</code>

So I develop in geeklog-hg-dev, then I winmerge my changes back into geeklog-hg-mine to make sure I never accidentally commit localsettings (paths etc) or hacks, debugs. Then I commit to geeklog-hg-mine, then back to geeklog-hg when that's ready, then push up to master. Complex hey? ;-)

Using Mercurial

2008-11-14T08:01:07Z

THEMike:

== Introduction ==

[http://www.selenic.com/mercurial/ Mercurial] is a distributed version control system (DVCS). The differences to a "traditional" centralized VCS (like CVS or Subversion) include:

* Users get a self-contained repository that they can commit changes to, even when being offline.
* Changes can be pushed back to the parent repository or even to other repositories.

Having used CVS since its inception, Geeklog switched to Mercurial after the release of Geeklog 1.5.1. This switch was preceded by an successful experiment using Mercurial during the 2008 [[Google Summer of Code]]. The distributed model did fit this scenario nicely, as each of our students was working on a separate feature. So they had a local repository to check in to (giving them all the benefits of a version control system). Once a feature or part of a feature was done, it could be pushed back to the parent repository. And in the meantime, it was easy to let other people, e.g. their mentor or interested members of the Geeklog community, pull the changes from the student's repository to show things off or get help on a problem.

== Installing Mercurial ==

Installation instructions are provided for [http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall Windows], [http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall Mac OS X], and [http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall Linux]

== Setup ==

Geeklog's Mercurial repository is available from this URL:

: http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/

This repository was converted from the CVS repository right after the release of [http://www.geeklog.net/article.php/geeklog-1.5.1 Geeklog 1.5.1].

To create a copy of that repository, simply do

<pre>hg clone http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/ geeklog</pre>

Where the last "geeklog" is just a directory name for the local copy (and can be changed at will). This will give you a fully working local repository that you can commit changes to.

'''Note:''' The same URL can also be used to browse the repository online. Simply visit that URL with your web browser.

=== SSH Setup ===

For ssh access, you need an account on the server. So this is only of interest for the core developers and SoC students.

You can clone the repository via SSH like so:

<pre>hg clone ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog geeklog</pre>

Where "username" is your login name and the "geeklog" at the end of the command line is again simply a name for your local directory.

Please note the slightly odd path syntax with the two slashes after <tt>cvs.geeklog.net</tt> - those are required.

== Pushing back ==

Being able to push changes back to the repository again requires an account on the server. You can either do

<pre>hg push ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog</pre>

or, to make your life easier, set the <tt>default-push</tt> repository in the <tt>.hg/hgrc</tt> file of your local repository like so:

<pre>[paths]
default-push = ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog</pre>

(Again, in the ssh: URLs above, replace "username" with your login name)

=== Trust and Notifications ===

Changes pushed back into the central repository will trigger an email sent to the geeklog-cvs mailing list. However, that email will only be sent after the following additional steps:

# log into your account on cvs.geeklog.net
# in your home directory, create a file named <tt>.hgrc</tt>
# enter this as the file's content:
<pre>[trusted]
users = geeklog2
groups = users</pre>

This will also get rid of warnings like
: remote: Not trusting file (...) from untrusted user geeklog2, group users
when pushing back changes.

== GSoC Repository ==

The repository used during the 2008 Google Summer of Code is still available from

: http://project.geeklog.net/cgi-bin/hgwebdir.cgi/gsoc-2008/

Note that both the URL and the repository name have changed (formerly <tt>Geeklog-SoC</tt>). You can still use your local copies of that repository - you only need to update the <tt>default-push</tt> setting to the new address and name.

== Best practices ==

Since we're all new to Mercurial, this is something we will have to establish as we go along. For starters, the [http://www.selenic.com/mercurial/wiki/ Mercurial Wiki] has a page on [http://www.selenic.com/mercurial/wiki/index.cgi/WorkingPractices Working Practices] that we may want to adopt.

=== Use a clean incoming repository ===

Pull changes to a local "incoming" repository but don't work on that repository. Cloning that repository locally is a cheap operation and allows you to easily create multiple copies if necessary, e.g. when working on different features in parallel.

Push directly from your working repositories, then sync back by pulling the changes back down via your incoming repository.

=== Merging ===

If you attempt to push changes to the main repository and receive the error:
pushing to ssh://username@cvs.geeklog.net//cvsroot/geeklog/Geeklog-SoC
searching for changes
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)
Simply pull from the main repository, "hg heads" to see the revision numbers, "hg merge [rev number]" to merge your changes, then commit the changes, and push back to the main repository.

Also: Don't try to push newly added files while you still have uncommited changes lying around (or you will end up with the above). In that case, it may make sense to make a fresh clone (fast + cheap if you use an "incoming" repository!), add the new files there, then push from the fresh copy.

=== Username ===

When committing a change, the username associated with that change will be your local username (login, etc.) - ''not'' the name of your account on the server.

For a consistent username, add your preferred username to your local <tt>.hgrc</tt> file:
<pre>username = John Doe <john@example.com></pre>
The email address is optional.

''(More tips and tricks to be added here)''

== Undoing Changes ==

To undo changes you made, use one of the following, depending on circumstances:

* <tt>hg revert</tt> to revert changes made before a commit. This will also undo <tt>hg add</tt> and <tt>hg remove</tt>.
* <tt>hg rollback</tt> to revert changes that have been commited to the local repository but not been pushed to another repository yet. You can only rollback the last hg command.
* <tt>hg backout</tt> to revert changes after they have been commited ''and'' pushed.

Note that <tt>hg backout</tt> will actually add a new change to the current branch that reverts your previous change. I.e. your change will ''not'' be removed from the repository. Unless you've accidentally committed something super-secret, that's usually fine. Mistakes happen - no need to sweat it.

== Documentation ==

The [http://www.selenic.com/mercurial/wiki/ Mercurial Wiki] is a good place to search for information. For starters, however, [http://hgbook.red-bean.com/ Distributed revision control with Mercurial] aka "the hg book" is a much better place to start. This book is available for download under the Open Publication License.

Here's the entirely subjective "The Impatient's Guide to the HG Book":

* Chapter 1: Introduction Skip if you already know about VCS and DVCS
* Chapter 2: A tour of Mercurial: the basics Everything from section 2.2 on is '''recommended reading'''. The essential things you need to know to use Mercurial.
* Chapter 3: A tour of Mercurial: merging work Title says it all - '''recommended reading'''
* Chapter 4: Behind the scenes Feel free to skip
* Chapter 5: Mercurial in daily use Despite the title, this chapter seems more confusing than helpful - skip
* Chapter 6: Collaborating with other people Section 6.2 is '''recommended reading''' once you've mastered the basics
* Chapter 7: File names and pattern matching Nothing surprising here - skip
* Chapter 8: Managing releases and branchy development Advanced topic but useful
* Chapter 9: Finding and ﬁxing your mistakes Very useful (but skip sections 9.5 and 9.6)
* You can effectively stop reading after Chapter 9.
* Appendix A may be useful as a reference.

[[Category:Development]]

== Windows Users - Secret Sauce (if you have commit rights) ==

I'm using command line Mercurial (I don't like the windows explorer performance hit of the tortoise system). But this works for me, after much messing around.

1. Clone the main Geeklog repository, as above. (geeklog-hg)
1. Clone your local copy of Geeklog to give yourself a clean working environment. (geeklog-hg-mine)
1. Clone your clean working environment ;-) (geeklog-hg-dev)
1. Update /path/to/geeklog-hg/.hg/hgrc to match bellow
1. Update /documents and settings/[your user]/mercurial.ini to match the other bellow

And that works.

For hgrc:

[paths]
default = ssh://[your username]@cvs.geeklog.net//cvsroot/hg/geeklog

For mercurial.ini:
[ui]
ssh = c:/path/to/putty/plink.exe -ssh -v -l [your username] -pw [your password]
username = [your name] <[your email address]>

Proposed Roadmap

2008-06-30T18:06:19Z

THEMike:

This is a proposed roadmap for the continued development of Geeklog 1.x following a planned and structured approach:

== Geeklog 1.5.1 - Maintenance ==
This is a '''bug fix only''' maintenance release.

=== Release Date ===
July 28th 2008

== Geeklog 1.5.2 - GSoC 2008 ==
This release rolls in the Google Summer of Code 2008 features:

=== Feature List ===
* [[SoC_improving comments_2008|Improving the comments]]
* etc

=== Timeline / Release Schedule ===
# Code Freeze (bug fixes only) - 28th September 2008
# Request Translations - 6th October 2008
# Beta Release 1 - 31st October 2008
# Beta Release 2 - 14th November 2008
# Release Candidate 1 - 1st December 2008
# Final Release - 22nd December 2008

== Geeklog 1.5.3 - Maintenance ==
This is a '''bug fix only''' maintenance release.

=== Release Date ===
January 30th 2009

== Geeklog 1.5.4 - ??? ==
=== Timeline ===
# Final Scope Agreed - January 30th 2009
# Code Freeze (bug fixes only) - 27th March 2009
# Request Translations - 6th April 2009
# Beta Release 1 - 27th April 2009
# Beta Release 2 - 11th May 2009
# Release Candidate 1 - 25th May 2009
# Final Release - 8th June 2009
=== Release Date ===
June 8th 2009

''Note:'' These dates are "too late" for Google Summer of code clean start. and there is no time for a maintenance release, so we'd have to sandbox it...

== Geeklog 1.5.5 - Maintenance? ==
=== Release Date ===
July 27th 2009

== Geeklog 1.5.6 - GSoC 2009 ==
Geeklog Summer of Code if we don't get into, or Google doesn't run, a 2009 summer of code.

Proposed Roadmap

2008-06-30T18:02:54Z

THEMike:

This is a proposed roadmap for the continued development of Geeklog 1.x following a planned and structured approach:

== Geeklog 1.5.1 - Maintenance ==
This is a '''bug fix only''' maintenance release.

=== Release Date ===
July 28th 2008

== Geeklog 1.5.2 - GSoC 2008 ==
This release rolls in the Google Summer of Code 2008 features:

=== Feature List ===
* [[SoC_improving comments_2008|Improving the comments]]
* etc

=== Timeline / Release Schedule ===
# Code Freeze (bug fixes only) - 28th September 2008
# Request Translations - 6th October 2008
# Beta Release 1 - 31st October 2008
# Beta Release 2 - 14th November 2008
# Release Candidate 1 - 1st December 2008
# Final Release - 22nd December 2008

== Geeklog 1.5.3 - Maintenance ==
This is a '''bug fix only''' maintenance release.

=== Release Date ===
January 30th 2009

== Geeklog 1.5.4 - ??? ==
=== Timeline ===
# Final Scope Agreed - January 30th 2009
# Code Freeze (bug fixes only) - 27th March 2009
# Request Translations - 6th April 2009
# Beta Release 1 - 27th April 2009
# Beta Release 2 - 11th May 2009
# Release Candidate 1 - 25th May 2009
# Final Release - 8th June 2009

''Note:'' These dates are "too late" for Google Summer of code clean start. and there is no time for a maintenance release, so we'd have to sandbox it...

Proposed Roadmap

2008-06-30T17:56:04Z

THEMike:

Geeklog Documentation

2008-06-30T17:49:05Z

THEMike: Added link to roadmap

[[Image:Logo.gif]]

== Geeklog Documentation ==

# [[Introduction]]
# [[Installation]]
# [[Administration]]
# [[Users Documentation]]
# [[Programmers/Developers Documentation]]

[[Complete Table of Contents]]

[[Proposed Roadmap]]

Note: This is the start page for the [[Restructuring the Geeklog Documentation|restructuring]] effort, so expect lots of broken links. Please help us fix and update the documentation. Thank you!

SoC geeklog2 syndication api

2008-03-03T15:05:03Z

THEMike:

== Incentive ==
It should be reasonably clear to any web savvy user or developer that Syndication is an essential aspect of any web software these days. The Geeklog2 engine needs a powerful, flexible syndication engine that can be used by all other plugins to provide inbound and outbound syndication feeds.

== Objective ==
* Develop a fully object oriented PHP5 implementation of the Geeklog 1.x syndication classes for reading/writing arbitrary feeds.
* Develop a Geeklog2 Plugin which provides a full API wrapper to the Syndication classes for creation and maintenance of outbound and inbound feeds

== Level of Difficulty ==

''Medium''

Geeklog 1.x's syndication framework is quite nice (even if I do say so myself!) and provides a good basic PHP4 OO implementation of the basic feed handling code. This needs turning into fully object oriented PHP5 (there are some refinements PHP5 allows that the current code misses. This is the easy part.

The harder part is defining what the interface from Geeklog 2 is and how it works, and working with the Geeklog2 framework, which only a couple of engineers are really up to speed with. Figuring this out from scratch will be the challenge to get something "right first time" to avoid the need to radically over-haul and replace the syndication framework at a later stage.

[[Category:Summer of Code]] [[Category:Development]]

SoC geeklog2 spam solution

2008-03-03T15:04:45Z

THEMike:

== Incentive ==

The internet contains nearly as much Spam as it does HTML. A new generation of web applications must start out from their infancy iron-clad with defences against Spam. Geeklog2 is no exception. The objective of this project is to develop a plugin for the Geeklog2 system to provide spam filtering.

== Objective ==

* Implement a Geeklog2 plugin to provide an API for spam filtering
* Include an extensible framework (like SpamX) for extending the abilities of the spam filter
* Include modules to support key anti-spam systems including
** LinkSleeve
** Akismet
** Project Honey Pot
** SWOT
** Local blacklists
** Bad Behaviour

== Level of Difficulty ==

''Medium''

The SpamX approach, with the full OO world of PHP5 seems to be a good base approach, and we have code to talk to the above listed key anti-spam projects largely available. However, ensuring this is a performant, scaleable, extensible, maintainable and well implemented solution may pose some challenges.

== Further Reading ==
[http://www.linksleeve.org/ LinkSleeve]
[http://akismet.com/ Akismet]
[http://www.projecthoneypot.org/ Project Honey Pot]
[http://swot.fuckingbrit.com/ SWOT]
[http://www.bad-behavior.ioerror.us/ Bad Behaviour]
[[Spamx_Plugin|SpamX Plugin]]

[[Category:Summer of Code]] [[Category:Development]]

SoC geeklog2 spam solution

2008-03-03T15:03:47Z

THEMike: /* Objective */

SoC geeklog2 spam solution

2008-03-03T15:03:06Z

THEMike: /* Further Reading */

== Incentive ==

The internet contains nearly as much Spam as it does HTML. A new generation of web applications must start out from their infancy iron-clad with defences against Spam. Geeklog2 is no exception. The objective of this project is to develop a plugin for the Geeklog2 system to provide spam filtering.

== Objective ==

* Implement a Geeklog2 plugin to provide an API for spam filtering
* Include an extensible framework (like SpamX) for extending the abilities of the spam filter
* Include modules to support key anti-spam systems including
* LinkSleeve
* Akismet
* Project Honey Pot
* SWOT
* Local blacklists
* Bad Behaviour

== Level of Difficulty ==

''Medium''

The SpamX approach, with the full OO world of PHP5 seems to be a good base approach, and we have code to talk to the above listed key anti-spam projects largely available. However, ensuring this is a performant, scaleable, extensible, maintainable and well implemented solution may pose some challenges.

== Further Reading ==
[http://www.linksleeve.org/ LinkSleeve]
[http://akismet.com/ Akismet]
[http://www.projecthoneypot.org/ Project Honey Pot]
[http://swot.fuckingbrit.com/ SWOT]
[http://www.bad-behavior.ioerror.us/ Bad Behaviour]
[[Spamx_Plugin|SpamX Plugin]]

Google Summer of Code

2008-03-03T15:02:50Z

THEMike: Create local SWOT page.

== What is it? ==

The [http://code.google.com/soc/ Google Summer of Code™] is a program sponsored by Google where they pay students to develop open source software. In its third incarnation in 2007, Geeklog [[Summer of Code 2007|took part]] in the program for the first time.

'''Note:''' Geeklog will be applying to take part in the Summer of Code 2008 again. At this point in time, however, no organizations have been selected yet. Please refer to [http://code.google.com/soc/2008/faqs.html#0.1_timeline Google's timeline] for the program for details.

== Project Ideas ==

This is a list of ideas for projects that we feel would add useful functionality to Geeklog. We are open for other ideas not listed here as long as they fit in with Geeklog's general ideas and concepts and can be done in the 3-months period of the Summer of Code program.

=== For Geeklog 1.x ===

* [[SoC_improving comments_2008|Improving the comments]]
* [[SoC_webservices_revisited|Webservices revisited]]
* [[SoC_install_script_revisited|Install script: Plugins and Migration]]
* [[Soc_swot|SWOT]] ''(Spam: Web of Trust)'' ([http://swot.fuckingbrit.com/ SWOT])
* [[SoC_mailman|Mailman Plugin]]
* [[SoC_improved_search|Improved Search]]
* [[SoC_socialnetworking|Add Social Networking Features]]
* [[SoC_css_foundation_classes|Implement a theme based on the YUI CSS Foundation Libraries]]
* [[SoC_cross_site_publication|Cross Site Alerting and Publication API]]
* [[SoC_web_analytics_api|Implement Open Web Analytics]]
* [[SoC_core_notification_support|Core Notification Service]]

There are also some [[SoC_more_ideas|leftover ideas]] from 2007.

=== For Geeklog 2 ===

* [[SoC_geeklog2_syndication_api|Geeklog2 Syndication API]]
* [[SoC_geeklog2_spam_solution|Geeklog2 Anti-Spam "Solution"]]

== Notes for Students ==

=== Required skills ===

Students interested in any of the above projects should have reasonable experience with PHP and some basic SQL knowledge. Being able to set up your own LAMP server (Linux, Apache, MySQL, PHP) would probably help but isn't a prerequisite.

=== Background information ===

Please note that there are '''two''' versions of Geeklog currently under active development but that they share little other than the name and a few contributors.

* '''Geeklog 1.x''' (currently 1.4.1, with 1.5.0 "almost done") is the software you may have seen running websites such as [http://www.groklaw.net/ Groklaw].
* '''Geeklog 2''' is "the next generation" of Geeklog and has been rewritten from the ground up. There are no released versions of Geeklog 2 yet.

Geeklog 1.x was started back in the year 2000 and its code is still mostly procedural and it uses its own (thin) database abstraction layer. Geeklog 2, on the other hand, is fully object oriented and uses technologies such as MVC and design patterns.

So basically, you can choose between working on a system that is in wide use already or one that uses all the latest and greatest in technology but isn't ''quite'' ready for mainstream use yet. In either case, you would be helping the Geeklog community immensely.

=== License ===

Geeklog 1.x has been released under the GPLv2 (GNU General Public License, version 2). All code written for Geeklog 1.x projects should also be released under that same license.

No final decision has been made on the license for Geeklog 2. However, it will most likely ''not'' be the GPL but a license in the spirit of the BSD license.

== Contact ==

For all questions regarding Geeklog and the Summer of Code, please email us at <tt>contact-us(AT)lists.geeklog.net</tt> (or use [http://www.geeklog.net/profiles.php?uid=2 this web form]).

[[Category:Summer of Code]] [[Category:Development]]

SoC geeklog2 spam solution

2008-03-03T15:00:26Z

THEMike:

== Incentive ==

The internet contains nearly as much Spam as it does HTML. A new generation of web applications must start out from their infancy iron-clad with defences against Spam. Geeklog2 is no exception. The objective of this project is to develop a plugin for the Geeklog2 system to provide spam filtering.

== Objective ==

* Implement a Geeklog2 plugin to provide an API for spam filtering
* Include an extensible framework (like SpamX) for extending the abilities of the spam filter
* Include modules to support key anti-spam systems including
* LinkSleeve
* Akismet
* Project Honey Pot
* SWOT
* Local blacklists
* Bad Behaviour

== Level of Difficulty ==

''Medium''

The SpamX approach, with the full OO world of PHP5 seems to be a good base approach, and we have code to talk to the above listed key anti-spam projects largely available. However, ensuring this is a performant, scaleable, extensible, maintainable and well implemented solution may pose some challenges.

== Further Reading ==
[http://www.linksleeve.org/ LinkSleeve]
[http://akismet.com/ Akismet]
[http://www.projecthoneypot.org/ Project Honey Pot]
[http://swot.fuckingbrit.com/ SWOT]
[http://www.bad-behavior.ioerror.us/ Bad Behaviour]
[[Spamx_Plugin SpamX Plugin]]

SoC geeklog2 spam solution

2008-03-03T14:50:04Z

THEMike:

== Incentive ==

The internet contains nearly as much Spam as it does HTML. A new generation of web applications must start out from their infancy iron-clad with defences against Spam. Geeklog2 is no exception. The objective of this project is to develop a plugin for the Geeklog2 system to provide spam filtering.

== Objective ==

* Implement a Geeklog2 plugin to provide an API for spam filtering
* Include an extensible framework (like SpamX) for extending the abilities of the spam filter
* Include modules to support key anti-spam systems including
* LinkSLV
* Akismet
* Project Honey Pot
* SWOT
* Local blacklists
* Bad Behaviour

== Level of Difficulty ==

''Medium''

The SpamX approach, with the full OO world of PHP5 seems to be a good base approach, and we have code to talk to the above listed key anti-spam projects largely available. However, ensuring this is a performant, scaleable, extensible, maintainable and well implemented solution may pose some challenges.

SoC geeklog2 spam solution

2008-03-03T14:46:29Z

THEMike:

== Objective ==

The internet contains nearly as much Spam as it does HTML. A new generation of web applications must start out from their infancy iron-clad with defences against Spam. Geeklog2 is no exception. The objective of this project is to develop a plugin for the Geeklog2 system to provide spam filtering.

SoC geeklog2 syndication api

2008-03-03T09:07:27Z

THEMike:

Google Summer of Code

2008-02-23T12:57:13Z

THEMike:

StoryArchitecture

2007-01-15T12:59:01Z

THEMike:

The main thing to understand with the Story "Rewrite" in 1.4.2 is the States a story may be in and how they interact with each other. I'd do a State Transition Network, but, no suitable diagramming tool to hand.

Essentially, a Story (or any piece of textual content by extension) has four main states and a few minor "transitional" states:

'''Display'''
The Display state is the one that is rendered. All that is needed to be done with an element of a story in Display state is to echo it to the page. It is safe to do so. It is clean and secure and HTML friendly. If there was a BBCode postmode, it would be bold for example. Autotags have been replaced, plaintext links made clickable. All ready to go.

'''Edit'''
The edit state is the one that is rendered in the edit controls. It just needs to be echo'd into a textarea tag or value attribute. It contains nothing but the edit version of a piece of text. (If there was a BBCode postmode, it would be [b]bold[/b], if HTML it would be bold). Autotags have not been replaced. Plaintext links are back to just text urls.

'''Database'''
The state that is in the database.

'''Rest'''
This is the native state of the class. There is very little work to do to move to display state. Really, only Autotags.

The sub-modes are:

'''Post'''
The result of an edit form being sent back by a $_POST operation. Stories should only be in this state for the briefest of moments.

The following must be true at all times:

addslashes(Rest) === Database
stripslashes(Database) === Rest

The Rest state must be AS CLOSE TO Display as possible. Only real time critical changes (Autotags) and non-reversible operations (none so far) must be required to move to the Display state. Essentially, for plaintext and html:

PLG_Autotags(Rest) === Display

The move from Edit to Rest must be reversible. Always. i.e.
EditMode(Rest) === Edit
and
LoadFromRequest(Post) === Rest

'''Also''' The following must be true:
LoadFromDatabase(Database) === LoadFromRequest(Post)

The idea being that the LoadFromRequest operation and the LoadFromDatabase operations happen as soon as data comes in from POST or database and moves to the Rest state it should be trivial to move it to Display state. Ideally, '''nothing''' should need doing, autotags is an exception. Autotags exist to provide up to the second information, and thus must be parsed on render. The work should be done in LoadFromRequest (possibly heavy duty processing to provide '''safe''' html markup that can be reversed) and EditElements which reverses that work and escapes for display in the edit fields.

Currently, there are two postmodes HTML (including advanced editor) and plaintext. Plaintext escapes all HTML (no injections or XSS possible at all) and makes links click-able and puts line feeds into place. HTML parses HTML against an allowed list (very minimum risk) and escapes disallowed HTML, leaving it escaped (because that's the right thing to do...).

Postmodes exist to allow formatting of text. Other common options are bbcode and wikitext, which should in my opinion be implemented the same as text and html. They should be responsible for removing security risks and providing required formatting in a safe way.

StripSlashes

2007-01-11T20:10:08Z

THEMike:

When writing a SQL statement, one must be aware that the ' character is the string delimiter.

A common form of attack on websites is called a SQL Injection. In the case of a SQL Injection, the attacker is hoping that a naive programmer has not thought to deal with malicious entry in forms. For example, imagine you need to run the following SQL to check a login:

SELECT uid FROM gl_users WHERE username='someusername' AND password='somepassword'

Suppose you just took the input from a form and did nothing:

$sql = "SELECT uid FROM gl_users WHERE username='$username' AND password='$password'

A malicious user could enter "someusername" for the username, but enter "' OR '' = '" for the password, resulting in the following SQL being executed:

SELECT uid FROM gl_users WHERE username='someusername' AND password='' OR '' = ''

This will result in the user being logged in.

This is is such a common problem that "Magic Quotes GPC was enabled.

Slashes are also automatically added to the contents of a GET, POST or COOKIE value if the Magic Quotes GPC flag is set to true on your PHP instance. For example, if you submit a form with the example above, the result would be:

SELECT uid FROM gl_users WHERE username='someusername' AND password='\' OR \'\' = \''

Which would result in a failed login.

Magic Quotes GPC becomes a problem when it comes to well coded applications, as any sensible developer will have called addslashes to escape the values prior to using them in SQL, and will use stripslashes on retrieving data from the database to put it back how it was.

stripslashes is a common PHP function used to remove the backslash character from a string. It's companion is addslashes.

addslashes adds slashes to a variable. It does this to escape quotes. So for example if you have a string:

''Geeklog's API functions are rich and varied.''

After a call to addslashes you will have

''Geeklog\'s API functions are rich and varied.''

Geeklog has a lot of code. It handles a lot of form posts and database save and load commands. The values fetched from the POST/GET/COOKIE arrays or from the database are passed in and out of numerous functions. Some of these expect non-escaped strings. Others expect escaped strings.

It currently appears to be a common source of bugs that addslashes and stripslashes are called needlessly.

It's also important to note that Geeklog has a function COM_stripslashes that calls stripslashes on the suppied variable if and only if Magic Quotes GPC is enabled.

Now, when doing code in geeklog, the following rules should probably be followed:

1. When your code is to deal with a value from $_GET, $_POST or $_COOKIE immediately load it into an internal variable after calling COM_stripSlashes, this will deal correctly with the value whether or not Magic Quotes GPC is on or off.
2. Immediately before using a value in SQL, addslashes to it.
3. Immediately after loading a value from SQL, stripslashes on it.

There should never be another need to call addslashes or stripslashes.

StripSlashes

2006-08-12T13:29:22Z

THEMike:

stripslashes is a common PHP function used to remove the backslash character from a string. It's companion is addslashes.

addslashes adds slashes to a variable. It does this to escape quotes. So for example if you have a string:

''Geeklog's API functions are rich and varied.''

After a call to addslashes you will have

''Geeklog\'s API functions are rich and varied.''

Slashes are also automatically added to the contents of a GET, POST or COOKIE value if the Magic Quotes GPC flag is set to true on your PHP instance. For example, if you submit a form with the first example above, when you examine the contents of that field server side you will get the second string despite not having done an addslashes in your code. But, '''only if Magic Quotes GPC is enabled on that server'''.

Now, when saving text into the database we use SQL, the ' character delimits a string within a SQL, so we '''must''' addslashes to a variable (that has not already had an addslashes) before using it in a SQL string. This will mean that if we retrieve a value from the database we're going to need to do a stripslashes to get it back to normal.

Geeklog has a lot of code. It handles a lot of form posts and database save and load commands. The values fetched from the POST/GET/COOKIE arrays or from the database are passed in and out of numerous functions. Some of these expect non-escaped strings. Others expect escaped strings.

It currently appears to be a common source of bugs that addslashes and stripslashes are called needlessly.

It's also important to note that Geeklog has a function COM_stripslashes that calls stripslashes on the suppied variable if and only if Magic Quotes GPC is enabled.

I suggest the following guidelines for using these functions:

## On loading from $_GET, $_POST or $_COOKIE call COM_StripSlashes immediately. This will only do a stripslashes if the Magic Quotes GPC flag is set in the PHP instance. Do

'''work in progress, got called away, sorry'''

File Paths

2006-03-11T21:20:32Z

THEMike:

== Beware of Relative Paths ==

Plugins designed to work with files stored on the system are likely to suffer from security issues if they do not take great care to deal with the paths in question.

For example, suppose your plugin prompts a user to pick a file from a list, then passes that filename through to display (log file browser?):

<pre>
<?php

$filename = $_POST['filename'];
readfile( $_CONF['path_system'] . '/plugins/myexploitablefileplugin/files/' . $filename );
?>
</pre>

This is very vulnerable. A malicious user could inject ../../../../../etc/passwd for example, or any other file you wouldn't want to make public. Suppose you use this method to include a theme.php file with an include call? Then a user could inject anything they've managed to drop into your error.log file!

Security and Common Practices

2006-03-11T21:15:28Z

THEMike:

This is a collection of articles on security considerations when developing for Geeklog. They apply to core code as well as plugins and other add-ons.

* [[Using COM_applyFilter]]
* [[register_globals]]
* [[Including lib-common.php]]
* [[Logging|Be careful what you log]]
* [[File Paths]]

Logging

2006-03-11T21:14:13Z

THEMike: Rewritten, still awful though.

== Be careful what you log ==

The PHP interpretter engine will parse PHP out of any file, no matter what the extension, so long as it contains a valid PHP open tag. It doesn't matter what the rest of the content of the file, so long as it has a section of wrapped in the PHP tags, it will parse and (try to) execute that block of content.

So, if you have a jpg file, that contains <?php echo('hello!'); ?> in the middle of the binary JPEG content and your PHP interpretter is asked to open that file, that block will be parsed and executed.

Geeklog provides several logging methods, including COM_errorLog, allowing you to log data to one of several files for the administrator to review. If someone crafts a cunning attack, they could arrange to have a block of PHP code logged into one of the core Geeklog log files, or your plugins custom log file.

This is not an immediate problem, typically these log files are not included in any scripts. However, should the cunning attacker be extra cunning, they may be able to devise a method of tricking Geeklog, or your plugin into doing a require, require_once, include or include_once on the infected log file, resulting in the execution of their injected code.

The fact that the web server is able to (and regularly does) write to these log files is the weak point. It gives them a location they can insert their own code to further open up the system to the full gamit of their evil desire.

''Careful!'' remember, <?php ... ?> is not the only way of running PHP code. If enable_short_tags is set, <? .. ?> works. PHP can even be configured to use the ASP tags: <% ... %>. Or, the log files could be used to attack ASP scripts, Coldfusion scripts or anything else that is available on the server.

Register globals

2006-03-11T08:40:23Z

THEMike:

Starting with version 1.4.0, Geeklog no longer requires to have PHP's register_globals option set to "on".

Despite the common conception that register_globals is "evil", it is not a security issue ''per se'', as long as you follow a few simple rules (see below). In all the years that Geeklog required register_globals to be "on", there was only '''one''' security issue that was a result of that setting.

On a side note, the register_globals setting will be removed from PHP 6, i.e. it will always be "off" and there will be no way to switch it back "on". So now would be a good time to review your code for dependency on the register_globals setting ...

== Initialising variables ==

The main rule to avoid problems with the register_globals setting is pretty simple:

:''Initialise your variables!''

The [http://www.php.net/release_4_1_0.php PHP 4.1.0 release notes] had the following example to illustrate what's bad about register_globals=on:

<pre><?php
if (authenticate_user()) {
$authenticated = true;
}
...
?></pre>

With register_globals=on, it's simple to override the authentication check by adding "authenticated=true" to the URL of this script, e.g.

:http://www.example.com/authenticate.php?authenticated=true

However, that problem is easily fixed:

<pre><?php
$authenticated = false;
if (authenticate_user()) {
$authenticated = true;
}
...
?></pre>

There. You can pass whatever you want in the URL now - initialising the $authenticated variable fixed the problem.

This is actually a better programming style anyway, not only from a security point of view. You should adapt this style in your own interest.

=== Switch on error reporting ===

On your ''development system'' ('''never''' do that on a production site), it's recommended that you switch on error reporting to be made aware of issues with uninitialised variables.

In your php.ini file, set

<pre>error_reporting = E_ALL
display_errors = On
display_startup_errors = On</pre>

... and don't forget to restart your webserver after you've made those changes.

Then, in Geeklog's lib-common.php, find the line

<pre>error_reporting( E_ERROR | E_WARNING | E_PARSE | E_COMPILE_ERROR );</pre>

and comment it out or remove it.

'''Note:''' Removing the error_reporting line from lib-common.php will throw up quite a few notices about uninitialised variables in the language files. Those are historic issues that can't be fixed easily but are not a security hazard. Just make sure not to repeat these design issues in your own code ...

The notices caused by the language files will prevent you from logging in to your site, so you may want to comment out the error_reporting line only during the debugging phase of your development cycle.

== Use typesafe comparison operations ==
The content of the superglobal arrays ($_GET, $_POST, $_REQUEST etc) are all strings, as are any variables created by register_globals. As this is the case, you can secure your code further by using typesafe comparisons:

<pre>
if ($authorized === TRUE)
{
// Only matches if $authorized contains an actual boolean true value.
}
</pre>

== Hidden problems with register_globals ==
Register globals allows you to inject values into arrays in a non-detectable fashion:

<pre>
$sids[] = "123";
foreach ($sids as $sid)
{
// Delete article by sid
}
</pre>

With the above code, a url such as:
somepage.php?sids[]=1&sids[]=2

Will inject additional values into the arrays.

== Use $_GET, $_POST, and $_REQUEST ==

The above explained how to avoid security issues when register_globals is set to "on". Of course, initialising your variables won't make your code work with register_globals=off.

Values passed from user interaction, i.e. when the user clicks on a URL or submits a form, are always passed in the global $_GET and $_POST arrays. The variables you're looking for exist as named array elements in those arrays, e.g.

* $_GET['page'] from a URL like /index.php?page=2
* $_POST['title'] from a form that contains a comment with a "title" field

Note that a form usually has a method="POST" attribute which means that the form is sent as a HTTP POST request. Consequentially, the $_GET array will be empty in such a case and all the form's values will only exist in the $_POST array.

The $_REQUEST array contains both the contents of the $_GET and the $_POST array. This comes in handy sometimes when a certain portion of your code will have to handle something that could come in via either a GET or a POST request.

However, the $_REQUEST should be used sparingly and with caution, as it may make it easier for an attacker to submit manipulated requests. For example, when your form handling code only looks at the $_REQUEST array, it's also possible to submit all the form's parameter through one GET request which, in some situations, is easier to send than a POST request.

The security implications of the $_REQUEST array are only mild, though. It's recommended, however, that you write your code such that you always know whether the incoming data is in the $_GET or $_POST array, which automatically helps to improve the clarity of your code.

=== Switching off register_globals ===

On your development system, you should switch off register_globals in your php.ini file:

<pre>register_globals = Off</pre>

== register_long_arrays ==

A somewhat related setting has been introduced with PHP 5: register_long_arrays, when set to "on", re-introduces the long names of the $_GET and $_POST arrays, i.e. $HTTP_GET_VARS and $HTTP_POST_VARS. These long-named arrays are disabled by default as of PHP 5 and any code relying on them will therefore fail.

The replacement for those, as mentioned above, are the $_GET and $_POST arrays and only those should be used. They were introduced in PHP 4.1.0, which has also been the minimum requirement for Geeklog for a while now.

Register globals

2006-03-11T08:39:22Z

THEMike:

Starting with version 1.4.0, Geeklog no longer requires to have PHP's register_globals option set to "on".

Despite the common conception that register_globals is "evil", it is not a security issue ''per se'', as long as you follow a few simple rules (see below). In all the years that Geeklog required register_globals to be "on", there was only '''one''' security issue that was a result of that setting.

On a side note, the register_globals setting will be removed from PHP 6, i.e. it will always be "off" and there will be no way to switch it back "on". So now would be a good time to review your code for dependency on the register_globals setting ...

== Initialising variables ==

The main rule to avoid problems with the register_globals setting is pretty simple:

:''Initialise your variables!''

The [http://www.php.net/release_4_1_0.php PHP 4.1.0 release notes] had the following example to illustrate what's bad about register_globals=on:

<pre><?php
if (authenticate_user()) {
$authenticated = true;
}
...
?></pre>

With register_globals=on, it's simple to override the authentication check by adding "authenticated=true" to the URL of this script, e.g.

:http://www.example.com/authenticate.php?authenticated=true

However, that problem is easily fixed:

<pre><?php
$authenticated = false;
if (authenticate_user()) {
$authenticated = true;
}
...
?></pre>

There. You can pass whatever you want in the URL now - initialising the $authenticated variable fixed the problem.

This is actually a better programming style anyway, not only from a security point of view. You should adapt this style in your own interest.

== Use typesafe comparison operations ==
The content of the superglobal arrays ($_GET, $_POST, $_REQUEST etc) are all strings, as are any variables created by register_globals. As this is the case, you can secure your code further by using typesafe comparisons:

<pre>
if ($authorized === TRUE)
{
// Only matches if $authorized contains an actual boolean true value.
}
</pre>

== Hidden problems with register_globals ==
Register globals allows you to inject values into arrays in a non-detectable fashion:

<pre>
$sids[] = "123";
foreach ($sids as $sid)
{
// Delete article by sid
}
</pre>

With the above code, a url such as:
somepage.php?sids[]=1&sids[]=2

Will inject additional values into the arrays.

=== Switch on error reporting ===

On your ''development system'' ('''never''' do that on a production site), it's recommended that you switch on error reporting to be made aware of issues with uninitialised variables.

In your php.ini file, set

<pre>error_reporting = E_ALL
display_errors = On
display_startup_errors = On</pre>

... and don't forget to restart your webserver after you've made those changes.

Then, in Geeklog's lib-common.php, find the line

<pre>error_reporting( E_ERROR | E_WARNING | E_PARSE | E_COMPILE_ERROR );</pre>

and comment it out or remove it.

'''Note:''' Removing the error_reporting line from lib-common.php will throw up quite a few notices about uninitialised variables in the language files. Those are historic issues that can't be fixed easily but are not a security hazard. Just make sure not to repeat these design issues in your own code ...

The notices caused by the language files will prevent you from logging in to your site, so you may want to comment out the error_reporting line only during the debugging phase of your development cycle.

== Use $_GET, $_POST, and $_REQUEST ==

The above explained how to avoid security issues when register_globals is set to "on". Of course, initialising your variables won't make your code work with register_globals=off.

Values passed from user interaction, i.e. when the user clicks on a URL or submits a form, are always passed in the global $_GET and $_POST arrays. The variables you're looking for exist as named array elements in those arrays, e.g.

* $_GET['page'] from a URL like /index.php?page=2
* $_POST['title'] from a form that contains a comment with a "title" field

Note that a form usually has a method="POST" attribute which means that the form is sent as a HTTP POST request. Consequentially, the $_GET array will be empty in such a case and all the form's values will only exist in the $_POST array.

The $_REQUEST array contains both the contents of the $_GET and the $_POST array. This comes in handy sometimes when a certain portion of your code will have to handle something that could come in via either a GET or a POST request.

However, the $_REQUEST should be used sparingly and with caution, as it may make it easier for an attacker to submit manipulated requests. For example, when your form handling code only looks at the $_REQUEST array, it's also possible to submit all the form's parameter through one GET request which, in some situations, is easier to send than a POST request.

The security implications of the $_REQUEST array are only mild, though. It's recommended, however, that you write your code such that you always know whether the incoming data is in the $_GET or $_POST array, which automatically helps to improve the clarity of your code.

=== Switching off register_globals ===

On your development system, you should switch off register_globals in your php.ini file:

<pre>register_globals = Off</pre>

== register_long_arrays ==

A somewhat related setting has been introduced with PHP 5: register_long_arrays, when set to "on", re-introduces the long names of the $_GET and $_POST arrays, i.e. $HTTP_GET_VARS and $HTTP_POST_VARS. These long-named arrays are disabled by default as of PHP 5 and any code relying on them will therefore fail.

The replacement for those, as mentioned above, are the $_GET and $_POST arrays and only those should be used. They were introduced in PHP 4.1.0, which has also been the minimum requirement for Geeklog for a while now.

Using COM applyFilter

2006-03-11T08:34:08Z

THEMike: Moved section to register_globals page

== Abstract ==

Geeklog 1.3.9 introduced a new function, COM_applyFilter, that is used to filter parameters passed in HTTP GET and POST requests. It is strongly suggested that plugins and other add-ons make use of this function. This article explains how to use COM_applyFilter and also provides additional
information on how to make your scripts more secure.

== Why parameter filtering? ==

Whenever parameters are passed in an HTTP GET request (usually in a URL of the form script.php?parameter=value) or an HTTP POST request (usually from an input field in a form, e.g. <input name="parameter" value="value">) there is a potential risk that these parameters are manipulated. With GET requests, it is easy to edit the URL and manipulated POST requests can be sent through manipulated forms or by using tools like netcat.

It is therefore important not to trust these parameters too much!

== COM_applyFilter ==

The COM_applyFilter function was designed to clear parameters from the most commonly used injection attempts (both SQL and JavaScript injections). So, to strip any potentially malicious content from parameters, use COM_applyFilter as follows:

<pre>$myvalue = COM_applyFilter ($_POST['myparameter']);</pre>

Or, in case, of a parameter that is supposed to be numeric:

<pre>$myvalue = COM_applyFilter ($_POST['myparameter'], true);</pre>

Your script should be prepared to handle the case that $myparameter is empty (or 0, for numerical parameters) after the call to COM_applyFilter. This will usually be the case when content was stripped from the parameter (unless it was empty / zero to begin with). Whether your script aborts in those cases or continues with default values instead of the empty / zeroed parameter, is up to you. Both may make sense, depending on the circumstances.

== A word on register_globals ==

As can be seen in the examples above, it is recommended NOT to rely on
register_globals being "on" (Geeklog itself doesn't require it any more as of Geeklog 1.4.0) but to use the global $_GET and $_POST arrays instead.

'''Note:''' The $_GET, $_POST, and $_REQUEST arrays are only available as of PHP 4.1.0, but that has been the minimum requirement for Geeklog for some time now.

See also [[Register_globals#Use_.24_GET.2C_.24_POST.2C_and_.24_REQUEST|Use $_GET, $_POST and $_REQUEST]]

== A bad example ==

If possible, you should ''not'' follow Geeklog's example of testing whether a parameter is set in the $_GET or $_POST array. Instead,
write your code such that at any moment you know exactly where your parameters would be in case of proper execution of the script. So if you know that at a specific point in your script, parameters can only be in the $_GET array (because you are expecting to be called through an HTTP GET request), don't bother checking the $_POST array (instead, simply ignore it). Geeklog's core code contains a few bad examples where at specific points in a script it is not clear whether we came there through a GET or a POST request and thus have to test both for the proper parameters. Depending on the situation, it may make things easier for an attacker and the code is in general much harder to maintain. Don't repeat that mistake.

== When not to use COM_applyFilter ==

Please note that you can ''not'' use COM_applyFilter on any sort of "free-form" content, such as the text of a story or things like a user's full name, since the function would strip out many special characters (such as quotes) and make the content illegible and / or useless. Instead, you should do something like this:

<pre>$mytext = COM_stripslashes ($_POST['mytext']);
// do something with it, then:
$mytext = addslashes ($mytext);
DB_save ($_TABLES['mytable'], "mytext", '$mytext');</pre>

The COM_stripslashes function will strip any slashes that may have been added during the POST operation, if the PHP option magic_quotes_qpc is "on" (and leaves the text untouched, if it is off), thus ensuring that you get the text back exactly as it was entered by the user. You can then process the text as needed by your plugin / add-on.

== Preparing for database storage ==

Before you store the text in the database, you should call addslashes on it to ensure that any special characters are properly escaped. This will NOT add slashes to the content in the database, it will only ensure that the text is properly stored (and in case it contains any SQL injection attempts, those would be stored as text, too, instead of being executed as part of the save operation).

Actually, it may be a good idea to apply addslashes on ''all'' parameters that go into the database, even if they have been passed through COM_applyFilter before, just in case.

== Safely identifying the current user ==

On a side note, if you need to identify the current user, you should ''never'' rely on the user's id passed through GET or POST requests (e.g. by embedding it in a form and reading it back when the form was submitted). Instead, ''always'' use the global variable $_USER['uid']. This variable may be empty or contain 1, which indicates an anonymous user, i.e. a user that is not logged in. So you should use something like

<pre>if (!empty ($_USER['uid']) && ($_USER['uid'] > 1)) {
// this is a logged-in user
} else {
// this is an anonymous user
}</pre>

== Summary ==

* use COM_applyFilter on any parameters passed through an HTTP GET or POST request
* add "true" to the call when the parameter is supposed to be numeric
* be prepared for the parameter to be empty or zero afterwards
* don't rely on register_globals - use $_POST and $_GET instead
* write your script such that you know whether your parameters are in $_POST or $_GET
* for "free-form" content, don't use COM_applyFilter but be careful to filter it otherwise and apply addslashes before storing it in the database
* always rely on $_USER['uid'] to identify a user

Using COM applyFilter

2006-03-11T08:32:43Z

THEMike: Added typesafe comparison.

== Abstract ==

Geeklog 1.3.9 introduced a new function, COM_applyFilter, that is used to filter parameters passed in HTTP GET and POST requests. It is strongly suggested that plugins and other add-ons make use of this function. This article explains how to use COM_applyFilter and also provides additional
information on how to make your scripts more secure.

== Why parameter filtering? ==

Whenever parameters are passed in an HTTP GET request (usually in a URL of the form script.php?parameter=value) or an HTTP POST request (usually from an input field in a form, e.g. <input name="parameter" value="value">) there is a potential risk that these parameters are manipulated. With GET requests, it is easy to edit the URL and manipulated POST requests can be sent through manipulated forms or by using tools like netcat.

It is therefore important not to trust these parameters too much!

== COM_applyFilter ==

The COM_applyFilter function was designed to clear parameters from the most commonly used injection attempts (both SQL and JavaScript injections). So, to strip any potentially malicious content from parameters, use COM_applyFilter as follows:

<pre>$myvalue = COM_applyFilter ($_POST['myparameter']);</pre>

Or, in case, of a parameter that is supposed to be numeric:

<pre>$myvalue = COM_applyFilter ($_POST['myparameter'], true);</pre>

Your script should be prepared to handle the case that $myparameter is empty (or 0, for numerical parameters) after the call to COM_applyFilter. This will usually be the case when content was stripped from the parameter (unless it was empty / zero to begin with). Whether your script aborts in those cases or continues with default values instead of the empty / zeroed parameter, is up to you. Both may make sense, depending on the circumstances.

== A word on register_globals ==

As can be seen in the examples above, it is recommended NOT to rely on
register_globals being "on" (Geeklog itself doesn't require it any more as of Geeklog 1.4.0) but to use the global $_GET and $_POST arrays instead.

'''Note:''' The $_GET, $_POST, and $_REQUEST arrays are only available as of PHP 4.1.0, but that has been the minimum requirement for Geeklog for some time now.

See also [[Register_globals#Use_.24_GET.2C_.24_POST.2C_and_.24_REQUEST|Use $_GET, $_POST and $_REQUEST]]

== A bad example ==

If possible, you should ''not'' follow Geeklog's example of testing whether a parameter is set in the $_GET or $_POST array. Instead,
write your code such that at any moment you know exactly where your parameters would be in case of proper execution of the script. So if you know that at a specific point in your script, parameters can only be in the $_GET array (because you are expecting to be called through an HTTP GET request), don't bother checking the $_POST array (instead, simply ignore it). Geeklog's core code contains a few bad examples where at specific points in a script it is not clear whether we came there through a GET or a POST request and thus have to test both for the proper parameters. Depending on the situation, it may make things easier for an attacker and the code is in general much harder to maintain. Don't repeat that mistake.

== When not to use COM_applyFilter ==

Please note that you can ''not'' use COM_applyFilter on any sort of "free-form" content, such as the text of a story or things like a user's full name, since the function would strip out many special characters (such as quotes) and make the content illegible and / or useless. Instead, you should do something like this:

<pre>$mytext = COM_stripslashes ($_POST['mytext']);
// do something with it, then:
$mytext = addslashes ($mytext);
DB_save ($_TABLES['mytable'], "mytext", '$mytext');</pre>

The COM_stripslashes function will strip any slashes that may have been added during the POST operation, if the PHP option magic_quotes_qpc is "on" (and leaves the text untouched, if it is off), thus ensuring that you get the text back exactly as it was entered by the user. You can then process the text as needed by your plugin / add-on.

== Preparing for database storage ==

Before you store the text in the database, you should call addslashes on it to ensure that any special characters are properly escaped. This will NOT add slashes to the content in the database, it will only ensure that the text is properly stored (and in case it contains any SQL injection attempts, those would be stored as text, too, instead of being executed as part of the save operation).

Actually, it may be a good idea to apply addslashes on ''all'' parameters that go into the database, even if they have been passed through COM_applyFilter before, just in case.

== Safely identifying the current user ==

On a side note, if you need to identify the current user, you should ''never'' rely on the user's id passed through GET or POST requests (e.g. by embedding it in a form and reading it back when the form was submitted). Instead, ''always'' use the global variable $_USER['uid']. This variable may be empty or contain 1, which indicates an anonymous user, i.e. a user that is not logged in. So you should use something like

<pre>if (!empty ($_USER['uid']) && ($_USER['uid'] > 1)) {
// this is a logged-in user
} else {
// this is an anonymous user
}</pre>

== Use typesafe comparison operations ==
The content of the superglobal arrays ($_GET, $_POST, $_REQUEST etc) are all strings, as are any variables created by register_globals. As this is the case, you can secure your code further by using typesafe comparisons:

<pre>
if ($authorized === TRUE)
{
// Only matches if $authorized contains an actual boolean true value.
}
</pre>

== Summary ==

* use COM_applyFilter on any parameters passed through an HTTP GET or POST request
* add "true" to the call when the parameter is supposed to be numeric
* be prepared for the parameter to be empty or zero afterwards
* don't rely on register_globals - use $_POST and $_GET instead
* write your script such that you know whether your parameters are in $_POST or $_GET
* for "free-form" content, don't use COM_applyFilter but be careful to filter it otherwise and apply addslashes before storing it in the database
* always rely on $_USER['uid'] to identify a user

Using COM applyFilter

2006-03-11T08:19:20Z

THEMike: Added link to related section

Remote Authentication

2005-06-12T09:35:48Z

THEMike:

New in geeklog 1.3.12 is the Remote Authentication system. With Remote Authentication enabled, users can login to your site via any authorised external service and act as a regular user.

This allows you to disable anonymous comments and make it easier for people to comment (they don't have to sign up on yet another site (yours) they can use a pre-existing central account to make comments).

To enable Remote Authentication:

#Set $_CONF['remoteauthentication'] = true; in config.php
#Set $_CONF['usersubmission'] = 0; in config.php
#Install one or more Authentication classes in /path/to/geeklog/system/classes/authentication (Geeklog ships with a class for Blogger.com and one for LiveJournal.com)

With Remote Authentication enabled, the user is presented with a select box on the login screen to choose the login service. This will default to your site, but allow them to choose an external service. Users are authenticated via their remote username and password, and if they pass authentication a ''local'' account is created on your geeklog site that is slaved to that remote account. These local slave accounts can be banned, have special permissions etc just like any regular site user. The account creation process is the same as for local accounts, so all custom functions and plugin notifications are carried out as normal.

In addition, the user is added to the group 'Remote Users' allowing you to automaticaly grant/deny specific permissions to all remote users.

== Unique Usernames ==
When a new account is created, the local username for that account is set to the remote username. However, if there is already a user in the system with the same username a call is made to custom_uniqueRemoteUsername passing in their remote username and the name of the service used to validate the user. This allows the admin to supply a custom function to ensure unique usernames for all users.

It is not ''necessary'' to have unique usernames. This does not break the security of a local user or remote users login, as the full remote username and service are stored locally to avoid collision and internally users are identified by a unique number. However, if you want to ensure it is clear ''who'' has posted a comment or article by the name displayed, this function allows you to ensure uniqueness.

== Disabling Services ==
To disable a specific service, simply remove the (servicename).auth.class.php file from /path/to/geeklog/system/classes/authentication and that remote service will no longer be available to your users.

== Adding Services ==
Currently authentication modules for LiveJournal and Blogger are available. If you wish to add further services you will have to write custom modules to do so. This can be done by creating a php file named ServiceName.auth.class.php which declares a class called ServiceName with a method called authenticate. Authenticate takes username and password as arguments and should return a boolean. The class should expose an 'email' property and attempt to provide the users valid email address if this can be aquired from the remote server.

Remote Authentication

2005-06-12T09:35:14Z

THEMike:

New in geeklog 1.3.12 is the Remote Authentication system. With Remote Authentication enabled, users can login to your site via any authorised external service and act as a regular user.

This allows you to disable anonymous comments and make it easier for people to comment (they don't have to sign up on yet another site (yours) they can use a pre-existing central account to make comments).

To enable Remote Authentication:

##Set $_CONF['remoteauthentication'] = true; in config.php
##Set $_CONF['usersubmission'] = 0; in config.php
##Install one or more Authentication classes in /path/to/geeklog/system/classes/authentication (Geeklog ships with a class for Blogger.com and one for LiveJournal.com)

With Remote Authentication enabled, the user is presented with a select box on the login screen to choose the login service. This will default to your site, but allow them to choose an external service. Users are authenticated via their remote username and password, and if they pass authentication a ''local'' account is created on your geeklog site that is slaved to that remote account. These local slave accounts can be banned, have special permissions etc just like any regular site user. The account creation process is the same as for local accounts, so all custom functions and plugin notifications are carried out as normal.

In addition, the user is added to the group 'Remote Users' allowing you to automaticaly grant/deny specific permissions to all remote users.

== Unique Usernames ==
When a new account is created, the local username for that account is set to the remote username. However, if there is already a user in the system with the same username a call is made to custom_uniqueRemoteUsername passing in their remote username and the name of the service used to validate the user. This allows the admin to supply a custom function to ensure unique usernames for all users.

It is not ''necessary'' to have unique usernames. This does not break the security of a local user or remote users login, as the full remote username and service are stored locally to avoid collision and internally users are identified by a unique number. However, if you want to ensure it is clear ''who'' has posted a comment or article by the name displayed, this function allows you to ensure uniqueness.

== Disabling Services ==
To disable a specific service, simply remove the (servicename).auth.class.php file from /path/to/geeklog/system/classes/authentication and that remote service will no longer be available to your users.

== Adding Services ==
Currently authentication modules for LiveJournal and Blogger are available. If you wish to add further services you will have to write custom modules to do so. This can be done by creating a php file named ServiceName.auth.class.php which declares a class called ServiceName with a method called authenticate. Authenticate takes username and password as arguments and should return a boolean. The class should expose an 'email' property and attempt to provide the users valid email address if this can be aquired from the remote server.

Login settings

2005-06-12T09:21:07Z

THEMike:

{| border=1 cellspacing=0
!Variable</th>
!Default Value</th>
!Description</th>
|-
| loginrequired
| 0
| Login is required to access ''any'' part of the site. When set to 1, this overrides the following settings. When you only want to block access to certain parts of the site, set this to 0 and select from the following settings.
|-
| submitloginrequired
| 0
| When set to 1, only registered users can submit stories, links, and events
|-
| commentsloginrequired
| 0
| When set to 1, only registered users can submit comments
|-
| linksloginrequired
| 0
| When set to 1, only registered users can access the links area
|-
| pollsloginrequired
| 0
| When set to 1, only registered users can access the list of recent polls
|-
| calendarloginrequired
| 0
| When set to 1, only registered users can access the calendar
|-
| statsloginrequired
| 0
| When set to 1, only registered users can access the site stats
|-
| searchloginrequired
| 0
| When set to 1, only registered users can use the advanced search. When set to 2, the simple search is blocked for anonymous users, too.
|-
| profileloginrequired
| 0
| When set to 1, only registered users can view another user's profile
|-
| emailuserloginrequired
| 0
| When set to 1, only registered users can use the email submission form to send an email to another user
|-
| emailstoryloginrequired
| 0
| When set to 1, only registered users can email stories
|-
| remoteauthentication
| false
| When set to true, users may login with remote accounts. (See [[Remote Authentication]].)
|-
|}

;[[The_Geeklog_Configuration_File|Back to The Geeklog Configuration File]]

Administration

2005-06-12T09:19:55Z

THEMike:

#[[IntroDoc|Introduction]]
#[[Installing Geeklog]]
#[[Administration]]
##[[Configuration]]
###[[The Geeklog Configuration File]]
###[[Remote Authentication]]
###[[Blocks]]
####[[Official Blocks|Official]]
#####[[Topics Block]]
#####[[Admins Block]]
#####[[User Settings & User Functions Block]]
#####[[What's New Block]]
#####[[Poll Block]]
#####[[Events Block]]
#####[[Older Stories Block]]
####[[UnOfficial Blocks|UnOfficial]]
#####[[Clock Block]]
#####[[News Block]]
####[[Block Types]]
###[[Plugins]]
####[[Official Plugins|Official]]
#####[[Static Pages Plugin]]
####[[UnOfficial Plugins|UnOfficial]]
#####[[Ban Plugin]]
#####[[Bookmarks Plugin]]
#####[[Contacts Plugin]]
#####[[EwikiPlugin]]
#####[[External Pages Plugin]]
#####[[FAQ Manager Plugin]]
#####[[Multilanguage FAQ Plugin]]
#####[[File Management Plugin]]
#####[[Forum Plugin]]
#####[[Geekary Plugin]]
#####[[GlinksPlugin]]
#####[[Glossary Plugin]]
#####[[Mailing Lists Plugin]]
#####[[Menu Plugin]]
#####[[Net Tools]]
#####[[Spamx Plugin]]
#####[[ThingsToDoPlugin]]
#####[[UpagePlugin|User Pages Plugin]]
#####[[Visitor Stats Plugin]]
#####[[Weather Plugin]]
#####[[zClassified Ads Plugin]]
####[[How To Install A Geeklog Plugin]]
###[[Themes]]
####[[Installing Themes]]
####[[Custom Themes]]
####[[Default Themes]]
####[[Other Themes]]
###[[Hacks]]
####[[Admin Toolbox]]
##[[Daily Administration]]
###[[Users and Groups]]
###[[Adding and Managing Content]]
####[[Content Types]]
#####[[Stories]]
#####[[Links]]
#####[[Events]]
#####[[Polls]]
####[[Editors and Admins]]
####[[Submission Queues]]
####[[Comments]]
###[[Geeklog Permissions]]
###[[Troubleshooting]]
##[[Quick How-Tos]]
##[[Security Guidelines]]
#[[Users Documentation]]
#[[Programmers/Developers Documentation]]

[[Geeklog_1.3x_Documentation|Main TOC]] 
[[Complete TOC]]