GS Wiki Re-Build

[Timbow]

Proposal - That the wiki should no longer support older GS releases

I am beginning to go through the existing GS wiki page by page. I want the wiki to be clear and simple so where there are references to versions of GS previous to 3.0 I am removing them. The wiki will in effect become documentation for GSvs 3.x.x. I might also remove references to bug fixes and improvements from 3.0 to 3.2 depending on how relevant and important they are.

• Any strong objections?
  
• Anybody using GS 2.x still?
  
• Any particularly important improvements in vs 3.0 - 3.2 which ought to be documented?
  

[WebDevandPhoto]

Data is always important and imo shouldn't be put into oblivion... and having public track record can boost exposure in the grande scope of things (even if data is terribly outdated, so long as it's labeled as outdated it's okay).
Perhaps there's a way to move that data in a aesthetic fashion to a retired section?

[shawn_a]

It's a wiki it always retains history that's why we use it.
Go ahead please

[Connie]

I do not agreee.

If some content belongs to older releases, keep it.

Why not have some branches from GS 1.2 (yes I do have that version zipped somewhere) to GS 3.0
we could keep that special content, but restrict edit permissions for these branches

do not loose that, people get clients with old versions and need info!

[shawn_a]

Then we can create archives of it and offer them as static copies or something, we cannot possible keep all information forever on it.

[Timbow]

i haven't read through all the pages yet. there are about 100 of them. Just a few refer to old versions. I will look carefully at footnotes or putting old stuff in another page. I don't intend to delete much, mainly organise it.

[shawn_a]

I think footnotes are essential when referencing when something was available.
We probably need a standard way of noting this on functions/functionality.

[Connie]

Then we can create archives of it and offer them as static copies or something, we cannot possible keep all information forever on it.

why not static copies... that will do it!

[datiswous]

• Any particularly important improvements in vs 3.0 - 3.2 which ought to be documented?
  

Maybe some more info on some of the:

New config directives

GSNOVERCHECK - Disable persistant header version checking
GSTIMEZONE - Timezone string for server default timezone
GSNOSITEMAP - Disable sitemap generation
GSSTYLE - Set an alternative style, eg. GSSTYLEWIDE
GSDEBUGINSTALL - Debugging, Prevent removal of install files for debugging installs
GSSUPPRESSERRORS - reproduce previous GS behavior ragarding php error supression

Maybe it's an idea that plugin documentation will also become part of a wiki section. This especially handy with unsupported plugins, where someone now has to search to long forum topics to get solutions posted by users.

[Timbow]

Maybe it's an idea that plugin documentation will also become part of a wiki section. This especially handy with unsupported plugins, where someone now has to search to long forum topics to get solutions posted by users.

It is an excellent idea. It is really hard to find good information in some of those threads. We must make sure there is a place where users are invited to write up-to-date how-tos for reference by others, maybe for specific plugins, maybe for say contact forms in general, or common tasks like setting up components.

[datiswous]

Maybe it's an idea that plugin documentation will also become part of a wiki section. This especially handy with unsupported plugins, where someone now has to search to long forum topics to get solutions posted by users.

It is an excellent idea. It is really hard to find good information in some of those threads. We must make sure there is a place where users are invited to write up-to-date how-tos for reference by others, maybe for specific plugins, maybe for say contact forms in general, or common tasks like setting up components.

Using the wiki for documenting plugins in general is probably even better and easyer to keep up to date, than using other forms op documentation (via forum posts, plugin description page, documentation file in plugin). If a plugin description is made, putting a link to that wiki section would be good.

I'm not sure about the idea in the wiki that anyone can edit each other tutorials, but it didn't give problems in the past with the main wiki (I think), so maybe that shouldn't be an issue. Off course this has mainly strong points and the issues are with every kind of wiki in general.

[WebDevandPhoto]

we cannot possible keep all information forever on it.

But why not? Aren't we like Google and have unlimited resources ;P lol.

If the wiki is like Github where it keeps a revision history then that's good imo.
But keeping old help docs avail for those occasional clients with old versions would be a good idea.

Edit:
I mean if no one will, I will host the old docs. It will only generate more traffic for me anyway and I'm fine with that ;P

[shovenose]

I don't mind hosting the old docs. It's my server It's just a matter of clutter.

[shawn_a]

"If the wiki is like Github where it keeps a revision history "

That is what a wiki is.

[Timbow]

The first thing i am going to do is make a new Table of Contents alongside the existing one and start linking the existing pages in the right places. This is purely a hierarchy of links - I am not moving pages in directories or anything like that.

The idea is to organise existing information into a more accessible structure and to provide places where users are invited to contribute articles. It will look something like this:

Intro
Page - what is GS? what is it for? Purpose & Mission

Quick Start or Try Out
Page - a How-to of simple Install, Create pages, Add content

User Level info & Guides
Installation
Pages for detailed installation, upload and setup
Backend Reference
Pages for backend tabs and core usage
Themes
Pages - User level theming descriptions and how-tos
Plugins
Pages - i18n and languages, individual plugins how-tos and guides
Content Adding and Editing
Pages - With and without the ckEditor, editor configuration
General Guides and how-tos
Pages - maybe backups, security, blogging, seo how-to

Developer Level info
Advanced Theming
Pages Theming and admin themes
Plugin Development
Pages - Plugin development guides and info
Core development
Pages relating to core development, releases, contributors, control.

[shawn_a]

Not to be an idiot, but wikis automatically do this, again that is why they are wikis. You can insert index automatically for any page based on back links and whatnot.

[Timbow]

Not to be an idiot, but wikis automatically do this, again that is why they are wikis. You can insert index automatically for any page based on back links and whatnot.

I don't have any experience of wikis, i have only thumbed through the docuwiki manual. istm our wiki doesn't have a directory structure and doesn't have a sensible system of links so it cannot generate a worthwhile Table of Contents. Most of the pages are in one directory so the wiki 'pagespace' (=position in directory tree) has no meaning. The existing ToC categorises the wiki pages by subject, but it isn't very good for a user because pages of newbie user information (like how to install a plugin) are alongside info for developers (how to code a plugin) .

[Connie]

I can't remember, was it always DOKUWIKI? Then it was started from the beginning with the wrong leg..

So I think it would be more flexible for the future to re-construct a real wiki-structure... not living with the mistakes of our forefathers ;=)

[shawn_a]

Dokuwiki is very good. You can use media wiki but it is highly advanced.

[shovenose]

Connie sometimes you just spout nonsense. DokuWiki is great!

[Connie]

I didn't spout nonsense about dokuwik. I know it is working. I use it as well.

My 3.5 cents were that the structure of the wiki was not done well (from our site!)

[Psychosopher]

My 3.5 cents were that the structure of the wiki was not done well (from our site!)

There are a additional possibilities for the structure. For example with a menu bar or with tagging.

I also use DokuWiki after giving some others a chance.

And: DokuWiki without database is approptiate to GetSimple CMS.

[datiswous]

I mentioned this before in an other topic. There are plugins for a better structure look:
https://www.dokuwiki.org/plugin:dwmenu