Difference between revisions of "Getting Started"

From GeeklogWiki
Jump to: navigation, search
m (Gettting Started moved to Getting Started: T-t-t-typo ...)
(First Steps)
 
(14 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
== First Steps ==
 
== First Steps ==
  
If you haven't already done so, [http://www.geeklog.net/filemgmt/viewcat.php?cid=8 download] and [http://www.geeklog.net/docs/install.html install] the current stable version. This will give you an idea how things are supposed to work.
+
If you haven't already done so, [http://www.geeklog.net/filemgmt/viewcat.php?cid=8 download] and [http://www.geeklog.net/docs/english/install.html install] the current stable version. This will give you an idea how things are supposed to work.
  
Next, try the development version. You can either [[Using Mercurial|use Mercurial]] or download the [http://project.geeklog.net/nightly/geeklog-nightly.tar.gz nightly tarball]. In either case, you need the [http://www.geeklog.net/nightly/geeklog-pear.tar.gz PEAR classes], which are not included in Mercurial or the nightly tarball ([http://www.geeklog.net/staticpages/index.php/CVS more detailed instructions here]).
+
Next, try the development version. You can either [[Using GitHub|use GitHub]] or download the [[Nightly Tarball]]. If you're checking out from the Git repository, you also need the [https://github.com/Geeklog-Core/pear/archive/master.zip PEAR classes]. The PEAR classes are already included in the nightly tarball. ([[Installing from the Mercurial Repository|more detailed instructions here]])
  
 
Once you got the development version up and running, you should read Alan McKay's excellent [[Beginner's Guide to Programming|Beginner's Guide to Geeklog Programming]], which will explain to you how to do things the Geeklog way.
 
Once you got the development version up and running, you should read Alan McKay's excellent [[Beginner's Guide to Programming|Beginner's Guide to Geeklog Programming]], which will explain to you how to do things the Geeklog way.
Line 11: Line 11:
 
We also recommend you have a look at our [[Coding Guidelines]]. Summary for the impatient: We're mostly following the PEAR coding standards.
 
We also recommend you have a look at our [[Coding Guidelines]]. Summary for the impatient: We're mostly following the PEAR coding standards.
  
 +
For an overview, you can also [https://github.com/Geeklog-Core/geeklog browse the Git repository] online or look through the [http://project.geeklog.net/src/ documented Geeklog source code].
 +
 +
If you want to ask a Geeklog developer a few questions you can usually find one or more of us hanging out on [https://gitter.im/Geeklog-Core/geeklog Gitter in the Geeklog room].
  
 
== Dive into it ==
 
== Dive into it ==
  
Once you have a rough idea how things work, try browsing our [http://project.geeklog.net/tracking/view_all_bug_page.php bugtracker]. Pick a bug that interests you. Try to reproduce it. If you can add any useful information to the bug (e.g. steps to reproduce the problem), go ahead and leave a comment.
+
''(trying to paraphrase [http://groups.google.com/group/google-summer-of-code-discuss/msg/630ba342ab440c27 this post] by Eric Weddington)''
 +
 
 +
Once you have a rough idea how things work, try browsing our [https://github.com/Geeklog-Core/geeklog/issues bugtracker]. Pick a bug that interests you. Try to reproduce it. If you can add any useful information to the bug (e.g. steps to reproduce the problem), go ahead and leave a comment.
  
See if you can find the area in the source code where the problem occurs. Try to think of a way to fix it and either fix it (patches are always welcome!) or, again, leave a comment.
+
See if you can find the area in the source code where the problem occurs. Try to think of a way to fix it and either fix it ([[Submitting Patches|patches]] are always welcome!) or, again, leave a comment.
  
 
Don't worry, not all the open bugs are hard. Some are fairly easy and are only open because nobody had a chance to fix them yet. Even if you can't solve the problem, you'll learn a lot in the process.
 
Don't worry, not all the open bugs are hard. Some are fairly easy and are only open because nobody had a chance to fix them yet. Even if you can't solve the problem, you'll learn a lot in the process.
  
''(to be continued ...)''
+
== Plugin Development ==
 +
 
 +
If you're interested in developing a new or improving an existing Geeklog plugin, start with the [[Plugin Developers Handbook]]. It's somewhat outdated in places (plugin [[Plugin Autoinstall|install]] and [[Plugin Auto-Uninstall|uninstall]] became a lot easier in recent Geeklog versions, for example), but it's still the best place to get an overview.
 +
 
 +
The most up-to-date description of Geeklog's plugin API is the [https://github.com/Geeklog-Core/geeklog/blob/master/system/lib-plugins.php lib-plugins.php] file.
 +
 
 +
To start writing a new plugin, try the [[Plugin Toolkit]].
 +
 
 +
 
 +
[[Category:Development]]

Latest revision as of 14:28, 28 July 2016

So you want to help out with Geeklog development? Excellent! Here are the first steps to get you started:

First Steps

If you haven't already done so, download and install the current stable version. This will give you an idea how things are supposed to work.

Next, try the development version. You can either use GitHub or download the Nightly Tarball. If you're checking out from the Git repository, you also need the PEAR classes. The PEAR classes are already included in the nightly tarball. (more detailed instructions here)

Once you got the development version up and running, you should read Alan McKay's excellent Beginner's Guide to Geeklog Programming, which will explain to you how to do things the Geeklog way.

We also recommend you have a look at our Coding Guidelines. Summary for the impatient: We're mostly following the PEAR coding standards.

For an overview, you can also browse the Git repository online or look through the documented Geeklog source code.

If you want to ask a Geeklog developer a few questions you can usually find one or more of us hanging out on Gitter in the Geeklog room.

Dive into it

(trying to paraphrase this post by Eric Weddington)

Once you have a rough idea how things work, try browsing our bugtracker. Pick a bug that interests you. Try to reproduce it. If you can add any useful information to the bug (e.g. steps to reproduce the problem), go ahead and leave a comment.

See if you can find the area in the source code where the problem occurs. Try to think of a way to fix it and either fix it (patches are always welcome!) or, again, leave a comment.

Don't worry, not all the open bugs are hard. Some are fairly easy and are only open because nobody had a chance to fix them yet. Even if you can't solve the problem, you'll learn a lot in the process.

Plugin Development

If you're interested in developing a new or improving an existing Geeklog plugin, start with the Plugin Developers Handbook. It's somewhat outdated in places (plugin install and uninstall became a lot easier in recent Geeklog versions, for example), but it's still the best place to get an overview.

The most up-to-date description of Geeklog's plugin API is the lib-plugins.php file.

To start writing a new plugin, try the Plugin Toolkit.