Additional invalid character for NAME
Support Ticket
Additional invalid character for NAME+issues
I've gotten this message before:
NAME: may not contain any of the following characters: / ~ |
Another character that should be invalid is period: .
Reason: a period in a name ends up confusing the processor, since it tries to interpret everything after the period as the render type of the page (e.g. htm/html, css, etc.).
Great inquiry! I've just added some new content to name variants to help provide a vocabulary to discuss the issues at hand. It's probably worth reading that card first before reading the rest of this comment.
Our name handling has evolved quite a bit in the last year or two, and it's perhaps a good time to revisit the restrictions above. I think in the long term all of the above characters should be allowed in canonical names, but periods (and the others above) will need special attention.
Each of the above characters got excluded because of processing issues that we really ought to be able to address. The slash was getting interpreted in the rails stack (or even deep in rack, if I remember correctly) before things got to wagn routing. The tilde has a special meaning in Wagn's RESTful web api: it's for using card's numerical ids. And the pipe has a special meaning in inclusion syntax.
That said, none of them should really cause issues in canonical names, so it seems like we just really need to be better about making sure these name variants don't show up in places where they cause trouble. For example, if you want a pipe in a cardname, fine, but you have to use a variant without the pipe when writing inclusions (easy enough; all you have to do is remove the pipe).
The same goes for the characters that are causing problems in links. And looking at the code, I *think* I know where the problem is arising and how to fix it.
Briefly, I think the only current issue is in linking to unknown cards. Correct me if I'm wrong, but everything works fine for existing cards, like Wagn 1.11. That link correctly uses the link name (Wagn_1_11), so the period doesn't cause any problem with the link. But if I link to a card that doesn't exist (like Wagn 1.11.23), then things will break for exactly the reason you mention.
As a solution, I think that whenever an unknown card's canonical name is different from its link name, the url should still use the link name, but should *also* send the canonical name as a query variable. (query variables do not present the format issue that you mention). So the broken link above would be corrected as follows: http://wagn.org/Wagn_1_11_23?card[name]=Wagn%201.11.23. I *think* that link will work now ( about to find out :) ).
Once we get that working, I think it will be safe to allow the tilde and the pipe. The slash, however, is still problematic, because we're planning to replace "+" with "/" as the default "joint" in compound names after we introduce DeckoSystems+names. It may be that at that time we decide that a name can include any character except the joint character. Or we may decide to make it possible to use the joint character in simple names if it's escaped. In any case, I think it will keep things simplest if we leave the slashes out of names for now so that we don't give ourselves a migration headache in the future.
I think joint should be joint, whether it is + or /, so not allowed in simple names. They would be space folded anyway, right? So, an embedded joint (/ or +) in a simple name would probably just be confusing, no?
pull request: https://github.com/wagn/wagn/pull/139
I don't know what "space folded" means, but if the joint were allowed in simple names, then they would not appear in link names or keys - only in canonical names.
The current pull requests assumes "/" are still disallowed and "+" still always means joint. The (totally non-urgent won't-do-anything-about-it-soon-regardless) question is whether it will ultimately be of great value to someone to have a slash in a simple cardname.
In the current system, an example case is "connec+pedia", which is the formal branding of that name. You can't currently create that card without creating nonsense parts.
In the proposed system (where slashes are joints), you can imagine someone wanting to do a card about an absolute or relative url, a company with a slash in the name, an emoticon, or even just a discussion of the use of a slash.
I doubt we'd ever be able to make it so clean that absolutely nobody ever gets confused, but there's certainly some value in an "everything is permitted" approach...
Meaning what we do with most special characters (except *, maybe?) we turn them into space equivalents and squeeze out extra ones and strip from the ends.
I see the use case, but wonder if it is really too marginal to worry over. Of course what is marginal for one is essential for another. Fortunately we can put this off unless someone wants it enough to pay for it :)
true. the pr stuff is far less marginal (the period thing has been a thorn in our side).
the pull request is merged. changing to "answered"