ver, this feature facilitates abuse of the system.

Private wiki servers require

user authentication to edit pages, and sometimes even to read them. Maged N. Kam
el Boulos, Cito Maramba and Steve Wheeler write that the open wikis produce a pr
ocess of Social Darwinism. "?'Unfit' sentences and sections are ruthlessly culle
d, edited and replaced if they are not considered 'fit', which hopefully results
in the evolution of a higher quality and more relevant page. While such opennes
s may invite 'vandalism' and the posting of untrue information, this same openne
ss also makes it possible to rapidly correct or restore a 'quality' wiki page."[
10]
Editing
Some wikis have an "edit" button or link directly on the page being viewed, if t
he user has permission to edit the page. This leads to an "editing page" where p
articipants structure and format wiki pages with a simplified markup language, s
ometimes known as wikitext. For example, starting lines of text with an asterisk
s creates a bulleted list. The style and syntax of wikitexts can vary greatly am
ong wiki implementations,[example needed] some of which also allow HTML tags. Wi
kis favour plain-text editing, with fewer and simpler conventions than HTML, for
indicating style and structure. Although limiting access to HTML and Cascading
Style Sheets (CSS) of wikis limits user ability to alter the structure and forma
tting of wiki content, there are some benefits. Limited access to CSS promotes c
onsistency in the look and feel, and having JavaScript disabled prevents a user
from implementing code that may limit other users' access.
MediaWiki syntax (the "behind the scenes" code used to add formatting to text)
Equivalent HTML (another type of "behind the scenes" code used to add formatting
to text) Rendered output (seen onscreen by a regular web user)
"Take some more [[tea]]," the March Hare said to Alice, very earnestly.
"I've had '''nothing''' yet," Alice replied in an offended tone, "so I can't tak
e more."
"You mean you can't take ''less''?" said the Hatter. "It's very easy to take ''m
ore'' than nothing."
<p>"Take some more <a href="/wiki/Tea" title="Tea">tea</a>," the March Hare said
to Alice, very earnestly.</p>
<p>"I've had <b>nothing</b> yet," Alice replied in an offended tone, "so I can't
take more."</p>
<p>"You mean you can't take <i>less</i>?" said the Hatter. "It's very easy to ta
ke <i>more</i> than nothing."</p>
"Take some more tea," the March Hare said to Alice, very earnestly.
"I've had nothing yet," Alice replied in an offended tone, "so I can't take more
."
"You mean you can't take less?" said the Hatter. "It's very easy to take more th
an nothing."
Wikis can make WYSIWYG editing available to users, usually by means of JavaScrip
t control that translates graphically entered formatting instructions into the c
orresponding HTML tags or wikitext. In those implementations, the markup of a ne
wly edited, marked-up version of the page is generated and submitted to the serv
er transparently, shielding the user from this technical detail. An example of t
his is the VisualEditor on Wikipedia. However, WYSIWYG controls do not always pr
ovide all of the features available in wikitext, and some users prefer not to us
e a WYSIWYG editor. Hence, many of these sites offer some means to edit the wiki
text directly.
Some wikis keep a record of changes made to wiki pages; often, every version of
the page is stored. This means that authors can revert to an older version of th
e page, should it be necessary because a mistake has been made, such as the cont
ent accidentally being deleted, or the page has been vandalized to include offen
sive or malicious text or other content. Many implementations, like MediaWiki, a
llow users to supply an edit summary when they edit a page; this is a short piec
e of text summarizing the changes they have made (e.g., "corrected grammar" or "
fixed formatting in table"). It is not inserted into the article's main text, bu
t is stored along with that revision of the page (often in a log or "history" wi
ndow), allowing users to explain what has been done and why, and enabling other
users to see which changes have been made; this is similar to a log message when
making changes to a revision-control system.
Navigation
Within the text of most pages, there are usually a large number of hypertext lin
ks to other pages within the wiki. This form of non-linear navigation is more "n
ative" to a wiki than structured/formalized navigation schemes. Users can also c
reate any number of index or table-of-contents pages, with hierarchical categori
zation or whatever form of organization they like. These may be challenging to m
aintain "by hand", as multiple authors and users may create and delete pages in
an ad hoc, unorganized manner. Wikis can provide one or more ways to categorize
or tag pages to support the maintenance of such index pages. Some wikis, includi
ng the original, have a backlink feature, which displays all pages that link to
a given page. It is also typically possible in a wiki to create links to pages t
hat do not yet exist, as a way to invite others to share what they know about a
subject new to the wiki. Wiki users can typically "tag" pages with categories or
keywords, to make it easier for other users to find the article. For example, a
user creating a new article on cold weather cycling might "tag" this page under
the categories of commuting, winter sports and bicycling. This would make it ea
sier for other users to find the article.
Linking and creating pages
Links are created using a specific syntax, the so-called "link pattern". Origina
lly, most wikis[citation needed] used CamelCase to name pages and create links.
These are produced by capitalizing words in a phrase and removing the spaces bet
ween them (the word "CamelCase" is itself an example). While CamelCase makes lin
king easy, it also leads to links in a form that deviates from the standard spel
ling. To link to a page with a single-word title, one must abnormally capitalize
one of the letters in the word (e.g. "WiKi" instead of "Wiki"). CamelCase-based
wikis are instantly recognizable because they have many links with names such a
s "TableOfContents" and "BeginnerQuestions." It is possible for a wiki to render
the visible anchor of such links "pretty" by reinserting spaces, and possibly a
lso reverting to lower case. However, this reprocessing of the link to improve t
he readability of the anchor is limited by the loss of capitalization informatio
n caused by CamelCase reversal. For example, "RichardWagner" should be rendered
as "Richard Wagner", whereas "PopularMusic" should be rendered as "popular music
". There is no easy way to determine which capital letters should remain capital
ized. As a result, many wikis now have "free linking" using brackets, and some d
isable CamelCase by default.
Searching
Most wikis offer at least a title search, and sometimes a full-text search. The
scalability of the search depends on whether the wiki engine uses a database. So
me wikis, such as PmWiki, use flat files.[11] MediaWiki's first versions used fl
at files, but it was rewritten by Lee Daniel Crocker in the early 2000s (decade)
to be a database application. Indexed database access is necessary for high spe
ed searches on large wikis. Alternatively, external search engines such as Googl
e Search can sometimes be used on wikis with limited searching functions in orde
r t