Upgrade to KH 3.1.3.1

This commit is contained in:
Deon George
2011-05-13 16:00:25 +10:00
parent 8013aadc4c
commit 6d256839fc
675 changed files with 22771 additions and 24111 deletions

View File

@@ -0,0 +1,41 @@
# Adding your module to the userguide
Making your module work with the userguide is simple.
First, copy this config and place in it `<module>/config/userguide.php`, replacing anything in `<>` with the appropriate things:
return array
(
// Leave this alone
'modules' => array(
// This should be the path to this modules userguide pages, without the 'guide/'. Ex: '/guide/modulename/' would be 'modulename'
'<modulename>' => array(
// Whether this modules userguide pages should be shown
'enabled' => TRUE,
// The name that should show up on the userguide index page
'name' => '<Module Name>',
// A short description of this module, shown on the index page
'description' => '<Description goes here.>',
// Copyright message, shown in the footer for this module
'copyright' => '&copy; 20102011 <Your Name>',
)
)
);
Next, create a folder in your module directory called `guide/<modulename>` and create `index.md` and `menu.md`. All userguide pages use [Markdown](markdown). The index page is what is shown on the index of your module, the menu is what shows up in the side column. The menu should be formatted like this:
## [Module Name]()
- [Page name](page-path)
- [This is a Category](category)
- [Sub Page](category/sub-page)
- [Another](category/another)
- [Sub sub page](category/another/sub-page)
- Categories do not have to be a link to a page
- [Etcetera](etc)
Page paths are relative to `guide/<modulename>`. So `[Page name](path-path)` would look for `guide/<modulename>/page-name.md` and `[Another](category/another)` would look for `guide/<modulename>/page-name.md`. The guide pages can be named or arranged any way you want within that folder (with the exception of `menu.md` and `index.md`). The breadcrumbs and page titles are pulled from the `menu.md file`, not the file names or paths. You can have items that are not pages (a category that doesn't have a corresponding page). To link to the `index.md` page, you should have an empty link, e.g. `[Module Name]()`. Do not include `.md` in your links.

View File

@@ -0,0 +1,35 @@
# Configuration
The userguide has the following config options, available in `config/userguide.php`.
return array
(
// Enable the API browser. TRUE or FALSE
'api_browser' => TRUE,
// Enable these packages in the API browser. TRUE for all packages, or a string of comma seperated packages, using 'None' for a class with no @package
// Example: 'api_packages' => 'Kohana,Kohana/Database,Kohana/ORM,None',
'api_packages' => TRUE,
);
You can enable or disabled the entire api browser, or limit it to only show certain packages. To disable a module from showing pages in the userguide, simply change that modules `enabled` option using the cascading filesystem. For example:
`application/config/userguide.php`
return array
(
'modules' => array
(
'kohana' => array
(
'enabled' => FALSE,
),
'database' => array
(
'enabled' => FALSE,
)
)
)
Using this you could make the userguide only show your modules and your classes in the api browser, if you wanted to host your own documentation on your site. Feel free to change the styles and views as well, but be sure to give credit where credit is due!

View File

@@ -0,0 +1,66 @@
[!!] When the docs get merged these images/links should be update
# Contributing
Kohana is community driven, and we rely on community contributions for the documentation.
## Guidelines
Documentation should use complete sentences, good grammar, and be as clear as possible. Use lots of example code, but make sure the examples follow the Kohana conventions and style.
Try to commit often, with each commit only changing a file or two, rather than changing a ton of files and commiting it all at once. This will make it easier to offer feedback and merge your changes. Make sure your commit messages are clear and descriptive. Bad: "Added docs", Good: "Added initial draft of hello world tutorial", Bad: "Fixed typos", Good: "Fixed typos on the query builder page"
If you feel a menu needs to be rearranged or a module needs new pages, please open a [bug report](http://dev.kohanaframework.org/projects/userguide3/issues/new) to discuss it.
## Quick Method
To quickly point out something that needs improvement, report a [bug report](http://dev.kohanaframework.org/projects/userguide3/issues/new).
If you want to contribute some changes, you can do so right from your browser without even knowing git!
First create an account on [Github](https://github.com/signup/free).
You will need to fork the module for the area you want to improve. For example, to improve the [ORM documentation](../orm) fork <http://github.com/kohana/orm>. To improve the [Kohana documentation](../kohana), fork <http://github.com/kohana/core>, etc. So, find the module you want to improve and click on the Fork button in the top right.
![Fork the module](contrib-github-fork.png)
The files that make the User Guide portion are found in `guide/<module>/`, and the API browser portion is made from the comments in the source code itself. Navigate to one of the files you want to change and click the edit button in the top right of the file viewer.
![Click on edit to edit the file](contrib-github-edit.png)
Make the changes and add a **detailed commit message**. Repeat this for as many files as you want to improve. (Note that you can't preview what the changes will look unless you actually test it locally.)
After you have made your changes, send a pull request so your improvements can be reviewed to be merged into the official documentation.
![Send a pull request](contrib-github-pull.png)
Once your pull request has been accepted, you can delete your repository if you want. Your commit will have been copied to the official branch.
## If you know git
**Short version**: Create a ticket on redmine for your changes, fork the module whose docs you wish to improve (e.g. `git://github.com/kohana/orm.git` or `git://github.com/kohana/core.git`), checkout the appropriate branch, make changes, and then send a pull request with the ticket number.
**Long version:** (This still assumes you at least know your way around git, especially how submodules work.)
1. Create a ticket on redmine for your changes.
2. Fork the specific repo you want to contribute to on github. (For example go to http://github.com/kohana/core and click the fork button.)
3. Now go into the repo of the area of docs you want to contribute to and add your forked repo as a new remote, and push to it.
cd system
# make sure we are up to date
git checkout 3.1/develop
git pull
# add your repository as a new remote
git remote add <your name> git@github.com:<your name>/core.git
# (make some changes to the docs)
# now commit the changes and push to your repo
git commit
git push <your name> 3.1/develop
4. Send a pull request on github containing the ticket number, and update the ticket with a link to the pull request.

View File

@@ -0,0 +1,3 @@
# Userguide
The userguide module provides documentation viewing including browsing the source code comments.

View File

@@ -0,0 +1,235 @@
# Markdown Syntax
The userguide uses [Markdown](http://daringfireball.net/projects/markdown/) and [Markdown Extra](http://michelf.com/projects/php-markdown/extra/) for the userguide pages, and the in-code comments used to generate the API browser. This is a brief summary of most of Markdown and Markdown extra features. It does not cover everything, and it does not cover all the caveats.
[!!] Be sure to check out the **[Userguide Specific Syntax](#userguide-specific-syntax)** for things that Userguide adds to markdown.
## Headers
# Header 1
## Header 2
### Header 3
#### Header 4
## Paragraphs
~~~
Regular text will be transformed into paragraphs.
Single returns will not make a new paragraph, this
allows for wrapping (especially for in-code
comments).
A new paragraph will start if there is a blank line between
blocks of text. Chars like > and & are escaped for you.
To make a line break,
put two spaces at the
end of a line.
~~~
Regular text will be transformed into paragraphs.
Single returns will not make a new paragraph, this
allows for wrapping (especially for in-code
comments).
A new paragraph will start if there is a blank line between
blocks of text. Chars like > and & are escaped for you.
To make a line break,
put two spaces at the
end of a line.
## Links
~~~
This is a normal link: [Kohana](http://kohanaframework.org).
This link has a title: [Kohana](http://kohanaframework.org "The swift PHP framework")
~~~
This is a normal link: [Kohana](http://kohanaframework.org)
This link has a title: [Kohana](http://kohanaframework.org "The swift PHP framework")
## Code blocks
For inline code simply surround some `text with tick marks.`
For inline code simply surround some `text with tick marks.`
// For a block of code,
// indent in four spaces,
// or with a tab
You can also do a "fenced" code block:
~~~
A fenced code block has tildes
above and below it
This is sometimes useful when code is near lists
~~~
~~~
A fenced code block has tildes
above and below it
This is sometimes useful when code is near lists
~~~
## Unordered Lists
~~~
* To make a unordered list, put an asterisk, minus, or + at the beginning
- of each line, surrounded by spaces. You can mix * - and +, but it
+ makes no difference.
~~~
* To make a unordered list, put an asterisk, minus, or + at the beginning
- of each line, surrounded by spaces. You can mix * - and +, but it
+ makes no difference.
## Ordered Lists
~~~
1. For ordered lists, put a number and a period
2. On each line that you want numbered.
9. It doesn't actually have to be the correct number order
5. Just as long as each line has a number
~~~
1. For ordered lists, put a number and a period
2. On each line that you want numbered.
9. It doesn't actually have to be the correct number order
5. Just as long as each line has a number
## Nested Lists
~~~
* To nest lists you just add four spaces before the * or number
1. Like this
* It's pretty basic, this line has eight spaces, so its nested twice
1. And this line is back to the second level
* Out to third level again
* And back to the first level
~~~
* To nest lists you just add four spaces before the * or number
1. Like this
* It's pretty basic, this line has eight spaces, so its nested twice
1. And this line is back to the second level
* Out to third level again
* And back to the first level
## Italics and Bold
~~~
Surround text you want *italics* with *asterisks* or _underscores_.
**Double asterisks** or __double underscores__ makes text bold.
***Triple*** will do *both at the same **time***.
~~~
Surround text you want *italics* with *asterisks* or _underscores_.
**Double asterisks** or __double underscores__ makes text **bold**.
___Triple___ will do *both at the same **time***.
## Horizontal Rules
Horizontal rules are made by placing 3 or more hyphens, asterisks, or underscores on a line by themselves.
~~~
---
* * * *
_____________________
~~~
---
* * * *
_____________________
## Images
Image syntax looks like this:
![Alt text](/path/to/img.jpg)
![Alt text](/path/to/img.jpg "Optional title")
[!!] Note that the images in userguide are [namespaced](#namespacing).
## Tables
~~~
First Header | Second Header
------------- | -------------
Content Cell | Content Cell
Content Cell | Content Cell
~~~
First Header | Second Header
------------- | -------------
Content Cell | Content Cell
Content Cell | Content Cell
Note that the pipes on the very left and very right side are optional, and you can change the text-alignment by adding a colon on the right, or on both sides for center.
~~~
| Item | Value | Savings |
| --------- | -----:|:-------:|
| Computer | $1600 | 40% |
| Phone | $12 | 30% |
| Pipe | $1 | 0% |
~~~
| Item | Value | Savings |
| --------- | -----:|:-------:|
| Computer | $1600 | 40% |
| Phone | $12 | 30% |
| Pipe | $1 | 0% |
# Userguide Specific Syntax
In addition to the features and syntax of [Markdown](http://daringfireball.net/projects/markdown/) and [Markdown Extra](http://michelf.com/projects/php-markdown/extra/) the following apply to userguide pages and api documentation:
## Namespacing
The first thing to note is that all links are "namespaced" to the current module. For example, from anywhere within the Kohana core docs you do not need to include `kohana` at the beginning of a link url. For example: `[Hello World Tutorial](tutorials/hello-world)` rather than `(kohana/tutorials/hello-world)`.
To link to a modules index page, have an empty url like: `[Kohana]()`.
To link to page in a different module, prefix your url with `../` and the module name. For example: `[Kohana Routes](../kohana/routing)`
**Images are also namespaced**, using `![Alt Text](imagename.jpg)` would look for `media/guide/<modulename>/imagename.jpg`.
## API Links
You can make links to the api browser by wrapping any class name in brackets. You may also include a function name, or propery name to link to that specifically. All of the following will link to the API browser:
[Request]
[Request::execute]
[Request::execute()]
[Request::$status]
[Request]
[Request::execute]
[Request::execute()]
[Request::$status]
If you want to have parameters and have the function be clickable, only put the brackets around the class and function (not the params), and put a backslash in front of the opening parenthesis.
[Kohana::config]\('foobar','baz')
[Kohana::config]\('foobar','baz')
## Notes
If you put `[!!]` in front of a line it will be a "note" and be placed in a box with a lightbulb.
[!!] This is a note
will display as:
[!!] This is a note
## Headers automatically get IDs
Headers are automatically assigned an id, based on the content of the header, so each header can be linked to. You can manually assign a different id using the syntax as defined in Markdown Extra. If multiple headers have the same content (e.g. more than one "Examples" header), only the first will get be automatically assigned an id, so you should manually assign more descriptive ids. For example:
### Examples {#more-descriptive-id}
## Including Views
If you need you may include a regular Kohana View file by placing the name of the view in double curly brackets. **If the view is not found, no error or exception will be shown, the curly brackets and view name will simply remain there!**
{{some/view/file}}

View File

@@ -0,0 +1,7 @@
## [Userguide]()
- [Using the Userguide](using)
- [How userguide works](works)
- [Contributing](contributing)
- [Markdown Syntax](markdown)
- [Configuration](config)
- [Adding your module](adding)

View File

@@ -0,0 +1 @@
Give tips on how to most effectively use the user guide. How to navigate around, how things are organized, etc.

View File

@@ -0,0 +1,25 @@
# How the Userguide works
The userguide uses [Markdown](markdown) for the documentation. Both the userguide pages, and the in code comments for the API browser are written in markdown.
## Userguide pages
Userguide pages are in the module they apply to, in `guide/<module>`. For example, documentation for Kohana is in `system/guide/kohana` and documentation for orm is in `modules/orm/guide/orm`, database is in `modules/database/guide/database`, etc.
Each module has an index page at `guide/<module>/index.md`.
Each module's menu is at `guide/<module>/menu.md`.
All other pages are are in `guide/<module>` and can be organized in subfolders and named however you want.
For more info on how to make your module have userguide pages, see [Adding your module](adding).
### Images
Any images used in the userguide pages must be in `media/guide/<module>/`. For example, if a page has `![Image Title](hello-world.jpg)` the image would be located at `media/guide/<module>/hello-world.jpg`. Images for the ORM module are in `modules/orm/media/guide/orm`, and images for the Kohana docs are in `system/media/guide/kohana`.
### API browser
The API browser is generated from the actual source code. The descriptions for classes, constants, properties, and methods is extracted from the comments and parsed in Markdown. For example if you look in the comment for [Kohana_Core::init](http://github.com/kohana/core/blob/c443c44922ef13421f4a/classes/kohana/core.php#L5) you can see a markdown list and table. These are parsed and show correctly in the API browser. `@param`, `@uses`, `@throws`, `@returns` and other tags are parsed as well.
TODO: give more specific details on how to comment your classes, constants, methods, etc. including package and how it relates to the api module.