From IndieWeb
Jump to: navigation, search


wiki may refer to:

Page type

Main article: wiki-page

In addition to sequential / time-ordered posts, many in the IndieWebCamp community either want to or already host a wiki or wiki pages on their own personal site.

Wiki pages are typically editable and versioned with visible / easily accessible version history & browsable versions. Wiki pages are often also multi-authored and have a multi-platform interface (like any web-based content hosting solution).

There are also various wiki hosting sites / silos.


Main article: wiki-projects

IndieWebCamp projects related to wiki hosting/creation/editing:

See also wiki projects brainstorming.

Wiki Features We Use

At some unlikely point in the far future, we may decide to migrate the wiki off of MediaWiki. If this ever happens, we'll need to be sure whatever replaces it has roughly the same functionality that we use in MediaWiki. Below is a list to collect descriptions of MediaWiki features that we use. Feel free to add to it.

  • Wiki-style editing - Click "edit" to view page source and "save" to save changes immediately. Conflicts are not merged automatically, and a message is shown if someone else has edited the page in the mean time.
  • Wiki-style links - MediaWiki provides a syntax for quickly linking between wiki pages, e.g. [[events]].
  • Nickname templates - We often use sparkline templates to display someone's photo and name in a line of text such as Aaron Parecki. This is done by creating a template with the person's nickname and typing {{aaronpk}} in a line of text.
  • Signature on edits - Sometimes we add a signature to lines using ~~~~ which is replaced by the logged-in user's signature and a timestamp.
  • Content templates - Several pages (such as events and 2016/Guest_List) use templates to avoid duplicating complicated wiki markup on the page. The templates themselves are wiki pages and are editing by the community.
  • IRC notifications - When wiki pages are edited, we get notifications in IRC describing the change.
  • The ability to embed HTML in the wiki markup – needed e.g. to add microformats to events
  • The ability to upload images, e.g. clicking "embed file" icon inserts wiki link with [[File:Example.jpg]]. Clicking that wiki link takes you to the form to upload the image.

Wiki Features We Need

Sometimes, MediaWiki does not have a good way to do what we want, so we have to hack around it.

  • Hotlinked images - We often want to hotlink images to avoid uploading them to the wiki (which is only possible if the image can be CC0 licensed), but we also want to proxy the img src on the resulting page so that the site can be served over https even if the image is http

See also:



Suggestions and bug reports for improving the wiki. Please provide suggestions as github issues here:

consider adding live update modules to homepage e.g. like newsletter sections

We could make the homepage a lot more "live" and show more activity/recency by incorporating some set of live updated modules. Issue here for tracking discussion, actual iterative brainstorming on the wiki itself:

Create individual sub-issues if you want to work on or discuss the implementation of a specific module

Inconsistent/limited search results causing confusion

@dougbeal discovered a search bug and we were able to narrow it down.

From the homepage, searching for a term should return all pages that contain that term in the title or body. For example, searching "rocks" should return the wiki pages and and Instead it's returning only because it contains the word "rocks" in the body. This was making it difficult for him (and I'm sure others) to find pages on the wiki.

There appears to be a difference between the built-in MediaWiki search form at (in the main content area) and the search form that appears at the top right. If you search rocks in the top right form, it only shows the more-limited results. If you use the one in the main content area, you get the fuller, expected results. Note that the homepage, where Doug was searching from, only has the more-limited search form.

Debugging the URLs it appears the difference that causes this is the redirs=0 URL param.




Normalise licensing for projects in the IndieWeb GitHub org.

I am opening this issue here because there is no other centralised repository for organisation issues. (Asked about this on IRC.)

Below is a table of all 28 current repositories in the IndieWeb GitHub organisation, the licence they are made available under, and links to issues that were opened because of the licensing.

Many of those issues were opened by @marclaporte on several of the Apache licensed PHP projects is because he ran into trouble including these libraries in other projects. He suggests re-licensing or dual-licensing the respective repositories with MIT, so it would allow him to include these libraries. Through @sebsel I found the issue on indieweb/php-comments and asked why not make the move to CC0?

I would like to use this as a central issue to discuss wether it would be worth it to move all code in the IndieWeb GitHub organisation to the same licensing.

Personally, I would like to see a dual-licensed configuration of CC0 1.0 Universal and MIT. Why dual-license something that gets pledged to the public domain? Because some countries may not allow perpetualy signing away rights. Offering companies the easy out with a secondary licence might be the best thing to do, a bit like SQLite selling licences (read their reasons for obtaining a licence).

There is an important precedent for the move to CC0 on the php-mf2 repository.

What are people’s opinions on this?

Repo Licence Licensing issues
IndieWeb Week Website CC0 1.0 Universal‡
IndieAuth Client Apache License, Version 2.0 + MIT #9
php-mf2 CC0 1.0 Universal #76
WordPress IndieWeb MIT
link-rel-parser-php Apache License, Version 2.0 #5
Comments Presentation Apache License, Version 2.0 #13
verify-me Apache License, Version 2.0
Webmention Client (PHP) Apache License, Version 2.0 + MIT #30 Apache License, Version 2.0
Webmention Client (Ruby) Apache License, Version 2.0 none none
This Week in the IndieWeb Apache License, Version 2.0
blank-gh-site none
rel-me MIT*
Microformats2 (ruby) CC0 1.0 Universal CC0 1.0 Universal
Indie Web Camp branding CC0 1.0 Universal
php-mf2-shim BSD 3-Clause License†
LinkRelParser (Ruby) CC0 1.0 Universal
Representative H-Card Parsing Apache License, Version 2.0 #1
Date Formatter Apache License, Version 2.0 #6
php-original-post-discovery MIT
wiki Unlicense
jf2 validator Apache License, Version 2.0
IndieWebCamp Assets none none
newBase60py CC0 1.0 Universal

*: The licence had to be taken from composer.json. †: Guessing 3-Clause, did not do a full text comparison. ‡: The repo is available under CC0, but all contributions are dual-licensed CC0 and OWFa 1.0.


  • php-mf2-shim talks mentions MIT in its composer.json but provides the BSD licence.


restore "next IndieWebCamp" banner at top of home page

Improve notifications

Improvements to the notification system with Echo. Makes most sense if we decide to do #34

Improve discussions with Flow

Right now, discussion either happen on IRC or on the article page itself. This might not scale well beyond a certain level of participants. Flow is an improvement to Talk pages and adds some structure to conversations.

Improve comprehension with link popups

With so many new terms to discover, it can sometimes be disorienting to open up dozens of tabs. Popups shows an excerpt from the link being hovered on, without taking away the context of the page.

Short URLs for the wiki

In the spirit of permashortlink we could setup UrlShortener on the wiki, possibly on a shorter url.

expand Join the Indieweb with icons etc like What is the IndieWeb

Per comment from @gRegorLove : Suggestion: a graphic for "Getting Started" on the homepage could be good - similar size as the heart icon on there. See discussion

I think this would be good for that entire section. We could even lay them out horizontally (as three icons with short text underneath each, side by side) rather than just another vertical layout, since less text is needed, and that matches what other "call to action" home page UIs have like

Logins should use the person's authorization endpoint if specified

If the user has specified an authorization endpoint on their home page, the wiki should use that directly rather than letting handle it. This will change the wiki's use of to be only used for rel-me-auth handling.

If you've defined your own authorization endpoint then you will never hit when signing in.


Improve layout on mobile

Current layout looks very "desktop shrunk down" compared to wikipedia on mobile. The sidebar and header and footer need pinching to be legible/clickable, as do the event listings.


Prompt new users to create their user page with data from their h-card

When a user first signs in, the wiki can read their h-card from their website, and pre-populate a user page template. This would make it easier to get started and would avoid making new users learn MediaWiki syntax as their first step into the community.

(thanks for the suggestion @rikmendes)

Rewrite image URLs to a proxy service

In order to switch the wiki to https only, we need to rewrite all hotlinked images to a URL that is served over https.

Additionally, it would be great to use something like which archives a snapshot of the image that is hotlinked so that if the URL disappears we can still show the image on the wiki.

1 comment

wiki-login URLs with symbols like `/`, `?`, `&` and https-only

obfuscated wiki's userpage-title URLs, which containing symbols like /, ?, & and https-only (without redirect from http-counterpart) are being used as actual URLs on related services (like IRC)

leads to wrong URLs, henceforth 404s

example: -> ->

possible solution?

# 10:41 aaronpk you can hide the default title on your user page and add your own # 10:42 aaronpk add __NOTITLE__ in the page then just use regular header syntax

Embed WebmentionDressing

See aaronpk/self#3

Incorporate WebmentionDressing

There's an "iframe ready" gist now (demo), and it's really easy to theme (I think).

tl;dr you just put this in an iframe and use your path as the URL hash (#IndieAuth, #2014/Online, etc.)

If you're game (just nod), I can fork an alternative theme (maybe without bootstrap) and we can have a theme selection dropdown and a "fork and propose your own theme" link. Could be fun.

Improve date readibility

Currently the events page uses YYYY-MM-DD which has two problems. First, the year is first, so if you scan down the left edge you see only years which is not very useful. Second, there is month/day ambiguity between US and the rest of the world, so I'm not sure whether this is April 9th or September 4th.

Current: 2014-04-09 Desired: 09 April 2014

screen shot 2014-04-08 at 4 03 41 pm


Add "remember me" checkbox to login screen

Used to be there...not sure what happened to it. Probably is actually part of the IndieAuth MediaWiki plugin

Update Mediawiki version

The current Mediawiki version 1.17 is quite out of date. Need to update to the current version. The main challenge will be making sure the plugins and skin is compatible.


Add a custom icon to the site

This will mean I can tell which tabs are indiewebcamp in Chrome, and have other benefits listed in the handy Icon page:

Better mobile editing support

Add or change the theme to have mobile support for editing. - This means that on mobile view have a text box that is capable of being scrolled through that is not so wide that it forces the editor to scroll left and right across the screen. Use case: Ben Ward had trouble doing this during the morning of IndieWebCamp UK 2013.

Possible solution: Install and use this extension, to detect this skin (WP Touch)

1 comment


Ideas being iterated rather than a specific suggestion for improvement.

Categorize Pages

Problem statement: If we look at the this-week reports (e.g. 2016-07-29 this week) and summaries of wiki pages that have been edited, it's a long list and doesn't provide a lot of information about why any particular page is important / compared to any other page, or any other way of chunking / understanding the long list.


  • one possibility would be to present each page with an icon in front according to what "type" or "kind" of page it is.
  • another possibility is to use such types/kinds to cluster the list of changed pages by type/kind, thus avoiding a need to repeat icons over and over
  • either way we could also use the "page icon" or "emojicon" on each page in particular to provide an even more specific graphical hook/representation for easier/quicker understanding of what the pages were about



Suggestions that have been implemented.


See Also

Retrieved from ""
Personal tools
Recent & Upcoming