Advanced Reference

From CampingDFW
Jump to navigation Jump to search

Wiki Home Page > Advanced Reference

Much of this page deals with wiki markup code. If you would rather use the much more intuitive Visual Editor, then see instead the Quick Reference.

This site hosts four types of content: (1) text; (2) photos; (3) PDFs; and (4) links. This site does not host any video.

1 Pictures and PDF's

How to contribute pictures and PDFs to the website

1.1. Content that Should NOT Be Contributed

  • 1.1.1. Copyright. Please do not contribute content that you did not create. If you created something, then you have the right to do whatever you want with it, including uploading it to the wiki. But if someone else created the content, then you do not have that right, and we ask that you not upload it to the wiki.
Except that all materials created by the federal government and its agencies are in the public domain, and these materials can be freely used and uploaded to the wiki without violating copyright.
Much of the content on this Wiki actually consists of links to other sites, which neatly avoids the question of ownership.
  • 1.1.2. Privacy. Please do not contribute pictures in which individuals can be recognized – especially minors. Facebook and other places exist to post pictures in which you and your friends can be recognized. But the purpose of this wiki is not share your memory of what your trip was, but rather to share with others what their trip would likely be. Watch the pictures on the Welcome Page for examples of an appropriate balance that shows unrecognizable people enjoying the outdoors.
Remember that your friends will not have consented to have their pictures posted on this wiki. And if those friends are under age 18, they do not have the legal capacity to consent to having their pictures posted on this wiki. But even if you do have effective consent, the wiki administrators have no way of knowing this, have no interest in keeping written records somehow tied to specific uploaded pictures, and have no desire to become embroiled in arguments about these issues.

1.2. How to Contribute Pictures and PDFs

  • In addition to text, the Wiki also hosts PDF documents and photographic images. These items can be contributed in either of two ways:
  1. You can upload those items to a webpage that you control, and you can then create a link on the wiki to that webpage; or
  2. You can send an email to the Wiki Administrator. You will receive a reply email that includes a link for uploading the pictures to Dropbox.

1.3. Reasons for Not Uploading Pictures via MediaWiki

  • There are several reasons for not incorporating these items directly into wiki pages. Most of these reasons come down to the fact that, although MediaWiki is the industry standard for handling wiki text, it is poorly suited to handling large numbers of images.
  • Keeping images off of wiki pages makes for a better user experience in terms of image quality. Excellent tools do exist for displaying large numbers of thumbnails and full size photographs on screens of varying sizes. This website uses uses WordPress supplemented with the Imagely plugin.
  • This also makes for a better user experience in terms of speed by keeping the wiki pages small and loading quickly. And if the user does decide to download a page of images, WordPress and Imagely are designed to make those pages load as quickly as possible.
  • This also reduces the volunteer administrator's workload. Every single image added to or removed from a wiki page must be individually coded. With Imagely this can be done in batches with a simple box check or a drag and drop.
  • This promotes both website security and website maintenance by allowing people to contribute text but denying them the ability to upload files to the website file structure.
  • This extra step also provides an opportunity to ensure that photos conform, such as ensuring that any people in a picture are not individually identifiable, that photos are tagged in a uniform manner (much of it batch tagging with Fast Photo Tagger), and so on (see 1.1. above).

2 No Videos

Videos are not hosted on this website

2.1. Videos Are Discouraged.

  • There are two problems with videos as they relate to this wiki.
  • First, it will take a user of the wiki much longer to watch a video than to quickly glance through a large number of still images. Since the wiki is a reference, and the point is to learn what you need as as quickly as possible, this is counterproductive.
  • Second, it is time-consuming for the wiki administrators to watch and figure out if the content of a video file is either consistent with the purpose and rules of the Wiki or beneficial. Even if your video is wonderful, enough other videos will be of an uninteresting home-movie quality, and/or will violate the rule against pictures of recognizable individuals, that neither users nor administrators should be asked to go through them.

3 Characters

Finding unusual text characters in MediaWiki

3.1. Hard to Find Characters.

  • The two following sections discuss how to insert unusual characters in wiki markup code. But the Visual Editor will usually be the easiest way to insert an unusual character.

3.2. Hard to Find Characters.

You may want to copy and paste these characters that are hard to find but frequently used on the wiki:
  • 3.2.1. Dot. ( • ) This is often used to visually separate items in a list. It is just a dot and does not implement formatting like an asterisk.
  • 3.2.2. N Dash. ( — )
  • 3.2.3. Ellipses. ( … ) This is a single character that will not separate at the end of a line.

3.3. Non-Standard Characters in URLs

  • In a URL, all symbols must be among:
A-Z a-z 0-9 . _ \ / ~ % - + & # ? ! = ( ) @ \x80-\xFF
  • If a URL contains a character that is not on this list, it should be encoded by using a percent sign (%) followed by the hex code of the character. These can be found in the table of printable characters. For example, the caret character (^) would be encoded in a URL as %5E. This needs to be verified and cleaned up.

4 Formatting Text

How to format one or more text characters in MediaWiki

Troubleshooting Tip. If you make what you thought was a simple change, and suddenly everything on the page below that point turns into a mess, there is a good chance that the culprit is just a piece of formatting code that you have failed to properly open or close. Proofread your work where the problem begins to ensure that all of these codes are properly opened and properly closed, and the problem will usually fix itself.
  • 4.1.1. Bold. Three single quotes to both open and close: '''Bold.'''
  • 4.1.2. Italics. Two single quotes: ''Italics can be hard to read on electronic screens and is usually avoided.''
  • 4.1.3. Underline. <u>Underline</u>. This is HTML code, so the closing tag must begin with /.
  • 4.1.4. Big. <big>Big</big>. Also requires / to close.
  • 4.1.5. Big-Bold. '''<big>Big-Bold.</big>''' This looks like a level 3 heading to the reader, but not to the wiki software, so it functions as a level 3 heading that does not clog up the table of contents at the top of the page.
  • 4.1.6. Bold-Italics. Five single quotes: '''''Bold-Italics.''''' Italics weakens the visual impact of bold, so bold-italics can work well in low level subheadings. Or in the Troubleshooting Tip above it makes the item jump out as being different.
  • 4.1.7. Monospace. A monospace typewriter font: <tt>monospace text</tt>
  • 4.1.8. Modifying Font Size. Specify a font size such as <font style="font-size:120%">Text at 120%.</font>. This may not implement consistently on all browsers and needs to be tested.
  • 4.1.9. Centering Text. Text can be centered with the following command. To center a heading, the command must appear on the lines before and after the heading. There is currently no plan to implement this on the wiki.
<center>Centered Text</center>
  • 4.1.10. Undisplayed Text To put a note in the editable version of a page so that it will be seen by future editors but not displayed:
<!-- Text here will not be displayed -->
  • 4.1.11. Displaying Wiki Code without Activating. A single quote before and after a bracket '[' or any other character will cause that bracket to appear as a text character without being activated by the wiki software. A single quote inserted at the beginning of a webpage address will likewise cause that link to appear as text rather than an active link. The nowiki command is much cleaner and is preferred.
  • 4.1.12. Displaying Wiki Code without Activating. (ignore the single quotes in this example):
'<'nowiki'>' '''''<u>These wiki codes did not activate</u>''''' '<'/nowiki'>'

5 Formatting Blocks of Text

How to format blocks of text in MediaWiki

5.1. Lists and Paragraphs

  • 5.1.1. New Paragraph. To start a new paragraph, hit the Return key twice to separate the two paragraphs with a line of white space. Without that line of white space, the wiki software will keep adding to the previous paragraph – unless the next line begins with a command such as an asterisk (*) or colon (:), in which case a new paragraph will begin even without a line of white space. That extra line of white space will also help future editors to find paragraph breaks when working with the editable version of a page.
  • 5.1.2. Bullets. To make a paragraph indent with a bullet at the beginning, use an asterisk (*) as the first character in the paragraph. It will help future editors if the asterisk is followed by a space. Bullets are frequently used on this wiki because they help the eye to quickly recognize the beginning of a new topic. This compensates for tools that are often implemented on paper but are hard to consistently implement as a wiki on multiple web browsers, such as indenting the first line or adding a small amount of vertical white space.
  • 5.1.3. Indentation. To make a paragraph indent without a bullet, use one or more colons (: or :: or :::). This is often used for a second paragraph on the same topic. More colons mean more indentation. It will again help future editors if the string of colons is then followed by a space.
  • 5.1.4. Indented Bullets. To indent a bullet, use one or more colons followed by an asterisk (:* or ::*). Multiple asterisks can also be used, but there is no point since no numbering is tracked in a bulleted list.
  • 5.1.5. Block quotes. To indent a paragraph on both the left and right margins to form a block quote, begin the paragraph with <blockquote> and end it with </blockquote>. The block quote can be made to indent further on the left margin by using one or more colons (:) before the <blockquote> command. Block quotes do not work well with bullets.
  • 5.1.6. Line Break. To make a line of text end for the reader without making the wiki software think that the paragraph has ended use <br>. This is generally disfavored, and can make the page very dense for future editors, but it does have some specific useful purposes.
  • 5.1.7. Numbered sequence. To get an indented and automatically numbered sequence of paragraphs, use the pound sign (#) instead of an asterisk. An empty line between paragraphs will break the sequence. To get a line of white space to display without breaking the sequence, use two line breaks (<br><br>) at the end of the line, one to end that line, and another to end the line of white space. To get sublevels, use more pound symbols (##) rather than colons.

5.2. Collapsible Text

  • 5.2.1. Collapsible Inline Text. All text contained within the command below will be collapsible. Because this is a <span> command, it works within a single paragraph.
<span class="mw-collapsible mw-collapsed">This text will not appear until the user clicks on Expand</span>
<span class="mw-collapsible">This text will appear until the user clicks on Collapse</span>
  • 5.2.2. Collapsible Paragraphs. All text contained within the command below will be collapsible. Because this is a <div> command, it works upon entire paragraphs. Control of white space with this command is currently poor, and refinement would be welcome.
<div class="mw-collapsible mw-collapsed">
* [[All#tarrant_county|Tarrant County]]
* [[All#denton_county|Denton County]]
Also see MediaWiki Manual and MediaWiki Manual Talk on collapsible elements.

6 Headings

Creating headings in MediaWiki, and conventions about using headings on this website

6.1. Levels of Headings - Default

  • The wiki automatically employs six levels of headings. Level 1 is used only for the page name. The next five levels are indicated as follows:
<h2>Heading Level 2</h2> or ==Heading Level 2==
<h3>Heading Level 3</h3> or ===Heading Level 3===
<h4>Heading Level 4</h4> or ====Heading Level 4====
<h5>Heading Level 5</h5> or =====Heading Level 5=====
<h6>Heading Level 6</h6> or ======Heading Level 6======
The convention on this wiki is to use ==-style headings rather than <h2>-style headings, in part because it is easier for page editors to see, and in part because the ==-style headings are native to MediaWiki, while the <h2>-style headings are native instead to HTML and it is therefore possible that they might not be as well supported in the future.

6.2. Levels of Headings - As Implemented

  • A – Real Headings. You will rarely need to add this type of heading. These headings begin and end with two to six equal signs (==Level 2 Heading==, ===Level 3 Heading===). They are interpreted by both the reader and the wiki software as headings, which means (among other things) that they automatically show up in the table of contents at the top of the page. But one of the design choices in implementing this wiki is to keep the table of contents relatively short and clean. So you will not generally need to add any real headings unless you are either making a lengthy contribution or reorganizing a page.
  • 6.2.1. Level 2 Headings. These are the highest level heading it is possible to have on a page and will always be real headings in the form: ==Level 2 Heading==. These are the headings that automatically create a horizontal line.
  • B – Apparent Headings. This is the type of heading that you will typically add. These headings are interpreted by the reader as headings, but are interpreted by the wiki as regular text. This keeps the table of contents short and clean.
  • 6.2.2. Level 3 Headings. These will usually be apparent headings using big-bold text in the form: '''<big>Level 3 Heading</big>'''.
  • 6.2.3. Level 4 Headings. Except on very lengthy pages, these will be apparent headings using bold text in the form: '''Level 4 Heading'''.
  • 6.2.4. Level 5 Headings. With rare exception, these will be apparent headings using bold-italics text in the form: '''''Level 5 Heading'''''.

6.3. Table of Contents

  • 6.3.1. Use of Real and Apparent Headings. Headings of level 2 and level 3 automatically appear in the table of contents. So think about what should appear in the table of contents when naming sections with level 2 and level 3 headings, and whether an apparent heading should be used instead.
  • 6.3.2. Table of Contents Location. The table of contents appears by default just above the first heading. But it will instead appear wherever the
command appears.
  • 6.3.3. Float-Right Heading - As Implemented. In this wiki, the fhe following code for the table of contents should almost always be used. It should be the very first line of the page in order to get the text placement consistent across all pages.
  • 6.3.4. Eliminating the Table of Contents. A wiki page will not generate a table of contents if the
command appears anywhere on the page. This should only be used on very short wiki pages. When it is used, putting it at the every end of the page avoids interference with the line spacing of the page.

6.4. Additional Visual Separation

  • 6.4.1. Horizontal Lines. Four or more dashes/hyphens will create a horizontal line stretching across the page like the one below. This can be visually appealing and help to break up space so the eye can more quickly find section headings. Horizontal lines are not needed on most pages, especialy short pagees, except at the bottom to signal the end of content on each page.
  • 6.4.2. White Space. Please do not create extra white space. Extra white space on the editable version of a page remains as extra white space on the displayed page. While this can be attractive to the eye, it is unlikely that contributors will leave uniform amounts of white space at the end of each edited section. So in order to avoid the non-uniform use of white space, which is even more unattractive and misleading than no white space, please do not leave extra white space when editing a page.
  • 6.5. Suppressing the Edit Links. Insert __NOEDITSECTION__ into the document to suppress the edit links that appear next to every section header.

7 Text Links

Creating links and anchors in MediaWiki

7.1. Internal Links to Wiki Pages

  • 7.1.1. Page name within Double Brackets. Internal links are simple. Just put the name of a page within double square brackets. For example, the source code for this link Getting Started is:
[[Getting Started]]
Here the target or destination of the link (the webpage Getting Started) is the same as the trigger or displayed text that sends you to that link (the text Getting Started).
  • 7.1.2. Customizing Triggers. You can use the vertical pipe character (|) to change the name of the trigger that activates the link. For example, the source code for this link Getting Started Contributing to the Wiki is:
[[Getting Started|Getting Started Contributing to the Wiki]]
Here the same target (still the webpage Getting Started) is reached by clicking on a different and fancier trigger (now the text Getting Started Contributing to the Wiki).
This link goes to the same target page as the link in 7.1.1 because both have the same target webpage address at the beginning of the link. The difference is that the second example has employed the vertical pipe character to display a different trigger for activating the link.
The vertical pipe character (|) is located at the right end of the keyboard between the Backspace and Enter keys. Use the shift key.
  • 7.1.3. Only for Wiki Pages. These internal links only work for wiki pages on this website. These internal links do not work for other items hosted on this website, such as uploaded maps in PDF format or gallery pages written in HTML. Even though these resources are part of this website, they are external to the wiki software.
  • 7.1.4. Self-Linking. A wiki page cannot link to itself with these internal URLs. Self links are displayed as inactive bold text.
  • 7.1.5. Redirect Pages. A redirect page does nothing except redirect all incoming traffic to another location. To link to a page, you can link either to that page, or to a redirect page that will in turn send you to the desired destination. For example, the complete content of the wiki pages Home, Start, and index is:
#REDIRECT [[Wiki Home Page]]
After clicking on the link for Home, the Wiki Home Page will say in the top left corner (Redirected from Home). Click on that link, and you will now stay on the redirect page and be able to edit it.
You cannot chain redirect pages in an endless sequence. Only the first redirect page will execute.
  • 7.1.6. Underscores When Linking to the Wiki. Unlike these internal links to wiki pages, incoming links to the wiki from other websites usually must replace all blank spaces with an underscore (_).

7.2. External Links

External links are formatted similarly to internal links, but with a few significant differences. Here is an example of an external link to this website's Welcome Page:
[ Welcome Page]
  • 7.2.1. Page Name within Single Brackets. A link to an external webpage is placed within single brackets, not double brackets. The easiest way to do this is to open the target webpage and then cut and paste its URL or web address into the wiki page that you are working on.
  • 7.2.2. Full Page Name. The web address must begin with "https://www." or "http://www." If this is left off when you paste in the web address, you can add it manually. When the name of the webpage ends with .htm, .html, .pdf, etc., so should the link.
  • 7.2.3. Customizing Triggers. Triggers for external links work exactly the same as for internal links – except that here with external links they are separated by a blank space rather than a vertical pipe. Since URLs cannot contain blank spaces, the wiki software will recognize the first blank space as the end of the URL and the beginning of the trigger. (In contrast, the names of internal wiki pages can contain blank spaces, so the vertical pipe character is instead needed to indicate the end of the page name for an internal wiki page).
  • 7.2.4. Non-Standard Characters. If an external link does not work, check to see if it has any unusual non-standard characters. See § 2.3. Non-Standard Characters in URLs.
  • 7.2.5. Links to Google Maps. Every wiki page for a destination should have a link to Google Maps showing the destination address, route, and directions. If the destination is outside the four DFW counties, then the beginning point should be either Fort Worth, Denton, McKinney, or Dallas. The idea is that almost all routes will exit the area on the highway through one of those four cities, and people already know about how long it takes for them to get to each of those four well known points.
Once you have this information up on your computer screen in Google Maps, you can add a link to that map, including directions, by following these steps: (1) In the top left corner of the screen, click on the three horizontal bars; (2) About halfway down the list of options, click on Share or embed map; (3) Click on Copy Link; and (4) Put the mouse cursor where you want the link to appear on the editable wiki page and paste the link by pressing Ctl-V. The exact map of directions that you had up on your computer screen is now available to everyone else. Users can easily change the beginning point and get an accurate set of directions for their exact situation.
  • 7.2.6. Burn Ban Information.
  • Texas. Texas A&M is the designated Texas State Agency to which burn ban information is to be reported and which is to in turn make that infomration publicly available. See Texas A&M and TPWD and [State].

7.3. Creating Anchors

  • 7.3.1. What anchors do. An anchor or bookmark is a specific location on a page. Anchors make it possible to link not only to the top of a page, but to a specific location on the page.
  • 7.3.2. Automatic anchors. The wiki software automatically recognizes the top of the page and all headings as anchors. The name for the anchor at the top of a page is #top. The name of the anchor for a heading is simply # followed by the text of the heading. But if the name of a heading gets changed, the link to that heading will be broken. This potential problem does not exist with manual anchors, and manual anchors are therefore preferred.
  • 7.3.3. Manual anchors. You can manually create an anchor anywhere on a page by using the following code. On this page there is an anchor named external-links. This anchors was created with the text:
<span id="external-links"></span>
Placing the anchor at the very beginning of a paragraph means the wiki software will link to the top of that paragraph. These anchors can even be placed within headings (following the first set of ==='s).
Anchors can be created using <div> instead of <span>, but there is no perceived reason to do so.
  • 7.3.4. Naming Conventions. Although not required by the wiki software, the convention on this wiki is to name all anchors in lower case letters and with hyphens between words instead of underscores or spaces. This is to ensure full compatibility with web browsers.
It is also better to select an anchor name that is somewhat distinctive to reduce the chance that someone else will inadvertently put another anchor with the same name on the same page.

7.4. Linking to Anchors

Links to automatic anchors and to manual anchors both work in exactly the same way, and both work much the same as any other link. The name of the anchor is preceded by a hashtag #.
  • 7.4.1. Linking to Anchors on the Same Page.
  • [[#internal-links|Internal Links]]
When linking to an anchor on the same page, the name of the page can and must be left off. If you attempted to also use the page's own name in the link, it would not display as an active link, but only as simple bold text.
  • 7.4.2. Linking to Anchors on Other Wiki Pages.
  • [[Every Destination on the Wiki#dallas-county|Dallas County]]
  • 7.4.3. Linking to Anchors via Redirects. The wiki software is smart enough to execute a redirect command before it starts looking for the anchor. Some redirect pages exist specifically so that contributors can identify a region such as the Central Texas Hill Country as though it were a separate web page and arrive at the correct portion of the correct page where that discussion happens to be located.
  • 7.4.4. External Incoming Links to Anchors. These look like any other external incoming link, but at the end add the name of the anchor preceded by the pound sign (#).
  • [http://Every_Destination_on_the_Wiki#dallas-county Dallas County]
  • 7.4.5. Linking to External Anchors and Bookmarks. Linking to a bookmark on another website or to a page number or bookmark in a PDF document, if enabled in that document, also works in the same way with a # followed by a page number or bookmark name.
  • 7.4.6. No Tracking of Anchors. The wiki software cannot easily search for and find anchors. Thus, in order to use an anchor, you must already know its name. Use the search box?
  • 7.5. Plain Links. This is rarely used because (1) it is often helpful for the link icon to draw the user's attention to the fact that a text string is a hot link; and (2) this is very unlikely to ever get implemented consistently across the wiki. But for those few occasions when this does make sense:
<span class="plainlinks">URL</span> This URL will not show the arrow afterward.

8 More MediaWiki Stuff

Some more Media Wiki bits and pieces

  • 8.1. Sandbox.
  • 8.2. Skins. This wiki uses the standard default “Vector” skin on the Desktop and the "Minerva" skin for mobile because they are the best supported. You may want to know that if you go looking online for help with WikiMedia.
  • 8.3. Footnotes and Endnotes. There is probably no need for this on this particular wiki. While the notes display at the bottom of the page, the text of each note actually resides in the text at the point where the footnote number appears. The wiki software command that makes footnotes appear is: '<'references/'>'. The notes display on the page wherever this command is located. If ever used, the notes should be placed under a separate heading at the bottom of the page. The notes themselves are inserted in the text between the two commands" '<'ref'>' and '<'/ref'>'. The text of a note may include bold, italics, internal links, and external links.
  • 8.4. Site Maintenance.
  • 8.4.1. Special:SpecialPages. Useful pages for wiki maintenance. Some pages appear only when logged in as an administrator.
  • 8.4.2. Wiki Do List. A list of priorities for adding to the site
  • 8.5. Official Media Wiki Resources
  • 8.6. MediWiki Admin Help. It took multiple frustrating attempts to find the solutions to some of the following items – especially short url's. These items are collected and published for the benefit of other MediaWiki administrators who may be looking for these solutions.
  • 8.6.1. MediaWiki Short URLs and Visual Editor. It took a very long and frustrating time to find good instructions for solving this issue, so here they are for any newbie MediaWiki administrator who has not yet cracked this issue.
  • 8.6.2. MediaWiki and WordPress. How to Implement both MediaWiki and WordPress on a single website with (reasonably) pretty URLs.
  • 8.6.3. MediaWiki Suppress Links When Printing. The MediaWiki default when printing a wiki page is to print the entire url of every link. This can make a printed page very hard to read. This simple solution removes those links.
  • 8.6.5. MediaWiki Changing Logo. Changing the default MediaWiki logo that appears in the top left corner of every page to something else that better identifies your website.
  • 8.6.6. MediaWiki Embedding Images. This is discouraged on this wiki in order to keep pages loading quickly and to keep them useful even on small screens.

9 About the Website

Some big picture considerations about how this site is set up

  • 9.1. Text and Photos. This site hosts four types of content: (1) text; (2) photos; (3) PDFs; and (4) links. But the only two that involve any significant choice about how to handle them are text and photos.
Even if a single piece of software were the best tool for handling both text and photos, these two types of information would still be split up on separate pages. Pages of wiki text do not have any images specifically so that they will remain small and load quickly. After reading the text, a user can then decide whether to also download a much larger page of photos.
9.2. MediaWiki and WordPress. In order to use the right tool for each job, text on this website is handled by MediaWiki, while photos are handled by WordPress supplemented by the Imagely plugin and theme.
MediaWiki is the same software base that powers Wikipedia and is the most robust tool for a wiki of any substantial size. The Visual Editor (finally) makes MediaWiki easy to use for contributors. But even though the wiki markup described above is no longer needed for most editing tasks in MediaWiki, its availability continues to make it easy to troubleshoot if anything should go wrong on a page, as well as to back up any page in a non-proprietary format simply by viewing the page source code and pasting it into Notepad. Finally, MediaWiki is at least as likely to continue to be supported as any other wiki software. These advantages outweigh the increased beauty available through some WordPress wiki themes.
WordPress and Imagely, on the other hand, are ideally suited to managing large number of photographs. Galleries eliminate the need to hand code a reference to each individual photograph. And WordPress and Imagely do an excellent job of resizing thumbnails responsively for variously screen sizes, optimizing download speeds, and creating attractive displays. And the only data entrusted to either of these programs are the photographs themselves, which are likewise easily backed up in a non-proprietary format.
9.3. Subdomains. Neither MediaWiki nor WordPress creates pages as separate computer files on the server. Rather, both store pages as information within a database and then render pages on the fly as requested.
One consequence is that both MediaWiki and WordPress want to control page naming and access as a condition of implementing pretty URLs on pages created by each program's database. This prevents them from playing well with each other within a single domain, and this website therefore functions as two separate but cross-linking parts with the MediaWiki portion on the domain and the WordPress portion on the subdomain The only three WordPress pages on the domain are the landing page, the "Page Not-Found" error page, and the contact form (which has an ugly URL).
Another consequence is that granting access to edit pages created by MediaWiki is completely separate from granting access to edit pages and photo galleries created in WordPress. Separate logins are thus required for each of these two distinct functions.

To sign up to contribute to the wiki or to report any broken links or other issues to the Wiki Administrator.

Wiki Home Page > Advanced Reference / Back to Top of Page