Note: CaseInSensitivity was a design decision from the very first version (see DB schema disussion below) and it is now (R1.01b) implemented (or at least believed to be). However, there is a configuration constant to revert to old behaviour (even if this setting doesn't affect the database).

Andy: The ewiki_link_regex_callback function is case sensitive while the database layers for MySQL and Windows *FlatFiles are not. This causes a page like *CaseSensitivityTest to be detected as a needed page by the regex but loaded when requested by clicking on the "?" because *caseSensitivityTest exists.

I suggest we make the MySQL database layer case sensitive by making the pagename column BINARY and thus case sensitive. The case of *FlatFiles on Windows is unfortunate but I think a fix for that would be more trouble than it's worth. The needed change for MySQL is in ewiki.php, ewiki_database($action == "INIT") to become:

CREATE TABLE " . *EWIKI_DB_TABLE_NAME ."
  (pagename VARCHAR(160) BINARY NOT NULL,
  version INTEGER UNSIGNED NOT NULL DEFAULT 0,
  ...

milky: This is an important decision: should ewiki be case-sensitive or not. My idea (as stated in the README) was to make ewiki insensitive on letter cases, because it looks more simple to me, if a page is accessible as *ThisPage and as ThisPAGE - there should be no two different pages with the same name. Another important thing to mention is: most other Wikis are case-sensitive, because this is much easiert to accomplish (and this is how most of ewikis' code still works today).

So in fact it was no fault from me to make the SQL tables ignore the case, but it is a lot harder to make db_flat_files cope with it (for UNIX systems, and it would be also hard for DOS filesystems). Therefor I didn't manage to deploy all the required code across ewiki to make it work.

The most stupid thing about all this is, that once ewiki is case-insensitive this behaviour cannot be reverted easily. The only solution to this was to encapsulate the page name string comparisions into separate function calls (utilized at least by _link_regex_callback). There arise various questions, when I try to think about this feature and its implementation problems:

• should the case of WikiLinks be reverted to the default page name, when rendered (so [wikilinks] got to [WikiLinks])
• for flat_files, should they be saved in all-lowercase
  • would break backwards compatibility
  • was the fastest solution (else multiple directory reads were required)
  • make dbff the only database which was not case-insensitive

There were probably some discussions about this in WardsWiki:, or somewhere else; let's have a look at there, if to really get case-insensitive (which I believe to be much more user-friendly).

AndyFundinger: WardsWiki: is case sensitive, but I found no disscussion. I have some users that definately want to specify and change the case of words (product names) so I prefer making everything case sensitive. If we do go case insensitive can we at least consider making it part of the *NextMajorVersion since it would break databases?

milky: I also didn't find much discussions about this issue. And I also think it is not very likely to find another Wiki that actually is case-insensitive, two obvious reasons:

1. case-sensitivity is the way to go for most professional programmers (see C and UNIX), and case-insensitivity is therefor often considered bad style (BASIC and Windows) - and because Wikis now are often used by the technical aware folks, they were often designed with case-sensitive pagenames
2. more important nevertheless is the fact, that case-insensitivity is hard to reach (it was so for ewiki, and this is the case for WardsWiki: too), so there is currently no other Wiki engine out there that actually could support it (except a DOS filesystem denoted one)

The main reason for me to make ewiki case-insensitive is, that I strongly believe this to be far more user friendly (perhaps this doesn't hold true for UNIX people). And also interesting: this makes ewiki stand out from the over hundred of other Wiki engines.

Anyhow, I'd like to support both in ewiki (reliable for SQL databases at least), and there is some more work to do. The database creation code should be kept case-insensitive targeted like it currently is, but we could add the BINARY flag into the actual SELECT queries so we'll get it back. The obviously overcomplicated ewiki_array() implementation is just there to allow reverting to case-sensitivity.

found some notes in PhpWiki:case insensitive bRaCkeT links, where a normalize() was recommended, which I would say we could implement just for configurability reasons ;)