Recent Topics

1 Mar 04, 2006 00:34    

The manual finaly get started.
It became a normal mediawiki 'wiki'.

The rough framework/outline has been set.
Now it needs finetuning and offcourse... filling..

On the communitypage you can discuss with us (Nate and I have started)

Our goal is to write the doc/manual from a users point of view.
So we need the end-user/ newbie to ask the questions.
We/You/Everyone/Somebody will try to answer those questions.

So if you know of a question you have/had you wanted to find an answer for, put it in here, and we'll try to place it somewere in the manual.
IF you found the answer somewere, please be so gentle to also place a link to the answer.

2 Mar 05, 2006 03:31

We've made more progress on the documentation framework. Take a look at and see what's cooking.

We would love to see more people hop on the bandwagon and start porting/gathering/writing information for each little section.

It's fun, and the good part is you don't have to write an 8 page dissertation to help contribute. Every little bit counts, and it's easy to add a few sentences here and a tiny paragraph there. Eventually we'll fill the whole thing up. :D

3 Mar 07, 2006 19:27

The edit and othe rtabs are hidden in FireFox. I think it's because of the b2evo banner + CSS at the top. This needs to get fixed but right now only Halton has th keys to the files.

Anyone heard of him these days?

4 Mar 07, 2006 19:41

I emailed him and he said he was planning on fixing the layout issues in the (near) future. In the meantime, he told me a very simple workaround. Just increase the text size in firefox and then the hidden tabs will be visible/clickable again. It's worked for me.

By the way, the layout issues effect firefox and safari so far from what i've seen.

5 Mar 09, 2006 16:30

Yep I knew about the text size increase, but that wasn't a good solution for the public! :P

Anyway, it's fixed, so let's roll with that manual :)

6 Mar 13, 2006 02:21

Hi guys,

I wanted to give a quick wiki primer for those wanting to help out on the b2evo wiki ( but who might not know where to begin.

If you go to the wiki you'll see the main Table of Contents. Blue links are pages that have been written (or at least started). Red links are pages waiting for some love and attention.

If you click on a red link you will immediately be taken to the edit box where you can begin writing. If you click on a blue link you should see an "Edit" tab at the top of the page so you can add to or change what you see.

In the sidebar there are a couple important pages that I happen to use frequently. The "Recent changes" link ( will let you know who's been working on what and which pages might need help with completion. And the "Help" link which will take you to some helpful wiki formatting examples to get you started with basic page layout stuff.

The best way to start is to find a section that looks fun to you and then have at it. Don't worry about layout and formatting (unless you want to) because that can all be fixed or changed later (even by someone else).

As it stands right now, the Table of Contents pages are about half way completed (although I'm sure they'll always be changing and updating). So join on in and help us finish it off! :D

7 Apr 02, 2006 06:27

It's a new month so I guess it's a good time to give another status update on the b2evolution wiki ( Out of the approximately 65 topics in the current Table of Contents only 14 remain undone (red links). That's really great!

There are some really juicy topics left, though. Things like editing skins, editing css files, and tweaking _main.php. **Drool** :D

As always, you are cordially invited to jump in and help with the documentation effort. Even pages that have been completed can always be modified, added to, etc. If you check the Recent Changes page ( you can see notes on some pages that might need further review.

And remember, there really is no way to mess things up since it's easy to undo mistakes or change formatting at a later time.

See you at the wiki!

8 May 09, 2006 10:08

I see that spam is already hitting the wiki, even though it's not yet 'live'. Once the documentation becomes the official documentation, it'll become an even greater target. I suggest implenting a captcha system for new users. Once a user is trusted, admins can disable the captcha (or perhaps get the user to request it to be disabled, which is less work for the admins). There's a [url=]ConfirmEdit extension[/url] so this should be trivial to do.

There are other useful extensions too - see

10 Jul 02, 2006 02:15

I would like to help out.

By looking at it atm, it seems to be for beginers starting off with v0.9.x, Correct me if i'm wrong.

I would like to work on a technical side for developers.

Like plugins, skins, hacking, the dos and don'ts, things i've learnt along the way, faqs, etc.

As even now after 1 and a half years of developing for b2evolution i'm still asking questions all the time, so i think the answers that i already know would be great help to the developer community.

Although my support would only be for the v1.8 release and current cvs builds. But that should not be a problem for plugin developers espicially, as the plugin enviroment is always having new events added and small changes made by request of the plugin developers.

So how can i help out?

Edit: Btw the link in the first post is broken.

11 Jul 02, 2006 12:45

Balupton: there are not that many people using 1.8 allready, since 1.8 was constantly changing.

That's why we - normal people ;) - ported the existing docs from 0.9.x over to the wiki-manual.

But in a couple of weeks time, 1.8 will be released and then we'll need the docs for 1.8.
So PLEASE feel free to add as mutch docs for 1.8 as you want.
There is code-freeze 1.8 version. That's the one that will get released to the public. So If you write docs, start from that version.

12 Jul 02, 2006 16:04

Plus any page that refers to 0.9.* should specifically say that. I think each page should say what generation it applies to (.9.* or 1.6 or 1.8), but I'm pretty sure it was blueyed who said pages about older stuff need to identify that they're gonna be old one day.

13 Jul 02, 2006 19:14

So If you write docs, start from that version.

So start from v1.8?

And to what EdB wrote as well.
I think the this would be a good layout:
**Stuff that is there now
**Stuff that is there now but for the v1.8 release
**Things for developers and technical information

Anyone else think that is a good idea?

14 Jul 02, 2006 19:46

balupton wrote:

So If you write docs, start from that version.

So start from v1.8?

Yes, start from the stable 1.8 branch.. not the real on-going CVS stuff

and your proposed layout is ok for me
as long as it is the same on each page, it's ok

15 Jul 02, 2006 23:20

Let me just randomly throw something in here ;)

There is ONE thing in 1.8 I am sure will change in future versions: the ItemList class. The whole backoffice already uses ItemList2 while the front end (skins) uses ItemList (1).

If you dig deep enough into the code you will be happy to know that. if you don't, nevermind ;)

16 Jul 04, 2006 05:11

Heres my suggested layout for the Phoenix releases:

EDIT: Removed long stuff that doesn't matter

Should give u the basic idea.

The Knowledge Base sections are where developers and users can add things they've learnt along the way, like quick tips, faqs, things worth reading or knowing, etc.

Good idea?

And is this the right place to be posting ideas for the wiki? or does the wiki have it's own system?

17 Jul 04, 2006 08:35

I'd go for : just do it in the wiki

That's how we, Nate and I, got started.
We just threw everything we though about into 1 page and started from there on.

That's the most inportant : start writing...
that's why we love the wiki-approach, because you can move chapters indefinitely.

19 Jul 04, 2006 17:56

Yep, once you get writing on the wiki and work out the kinks it can be quite fun. Until you hit a lull, that is. :D

20 Jul 06, 2006 03:32

Just got a question before i really get my hands dirty.

How does the wiki handle hierarchy?
So i can have phoenix pages inside the phoenix parent etc.

And what naming convention should i use for the pages?
Phoenix:Getting Started
Phoenix/Getting Started
Phoenix-Getting Started
Phoenix>Getting Started
Phoenix.Getting Started
Or any of the above with spaces inbetween the symbol?

Yeh... And another question i got on my mind, maybe the plugins and skins download page should be moved over to the wiki, so whenever a developer is happy with their plugin they add it to the wiki... Sure beats the current way in my opinion.


21 Jul 06, 2006 08:37

balupton wrote:

what naming convention should i use for the pages?
Phoenix:Getting Started
Phoenix/Getting Started
Phoenix-Getting Started
Phoenix>Getting Started
Phoenix.Getting Started

I would not put the Phoenix into the name of a page.
Since every version will have another nickname, that page would not be applicable for the next version (1.8 for example.)

balupton wrote:

Yeh... And another question i got on my mind, maybe the plugins and skins download page should be moved over to the wiki, so whenever a developer is happy with their plugin they add it to the wiki...

In an ideal world everything would be in the wiki.
But since there is not that many people working on it...
I'm busy with porting over the normal 'manual'.. and that takes time...

So for now, just one advice : start writing ;)

22 Jul 06, 2006 08:52

Ok, so when phoenix gets released what happens with the 0.9 series pages?

Or in each page will we have:

*Some Heading


**Some Heading
**Some Heading


23 Jul 06, 2006 10:45

balupton wrote:

Ok, so when phoenix gets released what happens with the 0.9 series pages?

Or in each page will we have:

Some Heading

Since 0.9.2 is such a stable version, we'll always have the doc for that version.

After the stable release of phoenix, will change it to

Some heading
* 0.9.2

24 Jan 26, 2007 15:32

So let's say I want to write/translate some documentation stuff in spanish. Do I just start editing in spanish, or is there another requirement for different languages? I ask this, because I've seen in my Backoffice, taht the links to the documentation have a parameter for the locale, which matches my current locale inside b2evolution. But of course, there's nothing written other than in english, so i get the default help pages.

25 Jan 26, 2007 16:07

I'm not sure, but you might be speaking about different docs than we are.

We are talking about the online documentation wiki which you can visit at It sounds to me like you're talking about the documentation that comes with your installation of b2e.

Ignore me if I'm wrong. :-)

26 Jan 26, 2007 16:23

Ehhh, Ok, they're two different things, but they send you to the wiki pages. For instance, when I'm in Blog Setting -> Features there are (?) links with urls like:

Which sends me to:

Because I assume there's no help page for es-VE locale. I was referring to that.

But, now I realise I was also thinking of all the other wiki pages, which I don't know if they are linked from inside the Backoffice.

27 Jan 28, 2007 10:19

Actually, b2evo is wired to handle multiple languages in the manual... but the manual site is not ready for that yet :/

You might want to contact Halton (who currently maintains the manual site) about this.

If nothing else, I would just create a spanish page and link to it from the top of the english page for now ;)

28 Jan 29, 2007 13:00

Thanks Fran├žois, I'll write to Halton to see what can be done about this.

29 Jan 27, 2008 03:22

Is this forum the place to discuss conventions/guidelines for creating a coherent manual in the wiki?

Is there a team/committee? If so, is there anywhere I could review past commuications (i.e., is their process transparent) so that I don't bore people with proposing redundant ideas (or, for that matter, conflicting ideas that have already been considered and nixed)

I'd like to be involved in docs, have a very strong background in writing in particular, and when it comes to technology, my niche is "bridging the gap between programmers and users" -- usability, biz analysis, synthesizing requirements into organized spec, tech docs for end-users, and so on (including PM) ... everything that helps programmers understand what users need/mean, or that helps users get up to speed quickly and contribute feedback. Experience across various human domains (from local activism to corporate boardrooms, though I'm sort of allergic lately to the latter!) in contributing momentum to any effort.

For a very outdated look at my creds, Some writing (though no real how-to's, come to think of it) at



Form is loading...