To edit the Wiki, you'll need to get new user credentials. You can request access by sending a personal message to user “@rs232” on the Tomato Forum. Make sure to include your email address and preferred username.

• Please choose your words carefully. Some wiki readers aren't fluent in English.

• Unless explaining complex concepts, please keep things brief and concise.
  We aim to make the documentation simple and easy to read, even for beginners.
  Most content is not meant to read like a reference manual. Extra “precision”
  can become overwhelming to many readers.

• Add a meaningful title to every wiki page. Format it with the Heading1 format.
  

• Avoid abbreviations not standard across the industry or in common English.
  
  For example, anyone unfamiliar with Linux/Unix may not know that “wl” indicates
  a Broadcom wireless interface. If it's not industry standard terminology, explain it.
  However, using “LAN”, is fine. It's common industry terminology.
  
  
• Avoid using the word: “Note”. It's overused, and doesn't add meaning.
  If the content isn't a critical warning, consider putting it in the
  “Notes and Troubleshooting” section at the bottom of the page.
  Otherwise, try bolding just a few of the most important words.
  
  
• Avoid underlining. It's obsolete and makes things hard to read.
  
  
• Check other pages to see which kinds of text content are capitalized
  and which are written in lower case.
  
  
• Check spelling with your browser's spell checker.
  
  
• When referring to FreshTomato web interface menus:
  
  • If there's only one menu with that name, indicate menu paths using just
    the name of the menu. For example, refer to the “Admin Access” menu.
  • If there's more than one menu with a similar name, write it as:
    “/Menu/Submenu”.
    
    For example: “/Bandwidth Monitoring/Real-Time”.
    
    This differentiates it from the “/IP Traffic Monitoring/Real-Time” menu.
    
    
• Avoid quotation marks, except around filenames or numeric variables.
  They're almost never appropriate.
  
  
• Use double quotation marks around filenames. For example, “wg0.conf”.
  
  
• Use rounded brackets “()” . Square brackets generally aren't appropriate and could
  be confused with code snippets or markdown language.
  
  

Following style guidelines makes content easier to read, and easier to understand.
It also reduces stress on the brain and eyes while reading.

The wiki uses dokuwiki as its underlying software.

It uses ProseMirror as its editor.

• Focus on content. Not everyone uses the same size monitor or resolution.
  Some people use a mobile device to access the wiki. Different browsers
  and accessibility features also affect how formatting appears (such as line breaks).

• Subheadings use the Heading2 format, and subheadings below that, Heading3.
  

• When taking screenshots, always use the “Tomato” theme (set in Admin Access).
  
  
  
  
  In general, please use this syntax for naming screenshots files for upload:
  “top level node name-bottom level node name-section name-release.png
  
  
  For example, a screenshot of the Options section in the Basic/DHCP Reservation menu
  should be named “basic-dhcp reservation-options-2024.1”.
  
  
• For screenshots of just one or few settings options under one section, use syntax:
  “top level node name-bottom level node name-option name to option name-release.png”
  
  
  Example: “advanced-wireless-roaming assistant to fragmentation threshold-2024.1”
  
  
• Please save screenshots in .png format. Lossy formats are blurry,
  and may reveal personal user data.

• Please wrap bulleted text at no more than about 40% frame width.It makes things much easier to read/follow. Shorter bulleted portions should be wrapped even earlier for reading ease.

• Screenshots in bitmap formats should be scaled/resized in even
  multiples of their original size. Otherwise, they may appear blurry.

• Avoid quotation marks. In the context of this wiki, they should be used only:
  • When slang is used.
  • When expressing something precise, separate from the text body, such as a filesystem path.
    
    
• Avoid underlining. It's been obsolete since the 1980s and makes text harder to read.
  
  
• Avoid using the word “Note”. Put notes in the Notes section that exists
  at the bottom of most pages.
  
  
• Except in a code window, command strings should be set in the monospace font,
  or in a callout box.
  
  
• Variables or process/module names should be italicized to distinguish them from other text.

• Avoid dividing lines. They're obsolete and make text hard to read.
  Better spacing and modern formatting methods work better.