Page Name "."

[Soma]

While my co-worker is building pages for a website, I've came across a page that has name: "1.-title"

How's this possible? I thought only a-z 0-9 dashes or underscores. I figured it's possible with space  or number before ".".

[ryan]

That is a valid page name. Periods "." are an allowed character in ProcessWire page names. That's how we allow for page names like: mypage.html

You can create page names like that in the API. But PW tries to beautify it by removing ugly combinations like that with some JS on the front-end:

// remove ugly combinations next to each other
name = name.replace(/(\.-|-\.)/g, '-'); 

As you noted before, that beautification can be skipped by just hitting enter in the 'name' field to save the page. I'm guessing that's what they did? At that point, it goes to PW's pageName sanitizer, which is less restrictive and doesn't try to beautify or translate it… just make it valid. I would like to find a way to prevent the enter-to-save in the pageName field though.

[Pete]

Do you mean something like this ryan: http://psacake.com/web/ie.asp ?

I've used various bits of JS like this to stop people accidentally submitting forms before by having JS monitor for a particular key being pressed.

Although it's only tenuously related, other nice things I've done in the past like this include preventing users from inputting certain characters into fields at all - for example in fields where only a number was expected I prevented them from entering any characters apart from numbers and single period.

[ryan]

That is exactly what I'm looking for, but the problem is that event.keyCode is not cross browser, from what I understand.  Apparently this even changes between versions of browsers (including Firefox, not just IE). It's one of those things that seems a little too ambiguous with browser and versions so I've been avoiding it. I did experiment with adding a form submit event on focus (that returns false), and removing it on blur. This seems to work okay and might have to implement it like that, but this is one of those things that I worry will take a few commits before it's right.

[Soma]

Aah, thanks Ryan I didn't know, that makes sense. I don't know a way around that problem with enter. I just know it can be really tedious to implement such things cross browser.

[Pete]

I'll admit I've only been using it on IE8/9 and FF4+ but it's worked for me. That said, I should probably check and see what happens in Opera and Safari (I didn't bother originally as it was for an intranet system where only IE and occasionally FF is used to browse the system).

I just did a search to find the code in one of my projects and found that there's a mention of ui.keycode in jQuery UI, so maybe they've already solved that problem? Indeed I just found a StackOVerflow page on different ideas regarding this that might be of some use (or that you've possibly already read ): http://stackoverflow.com/questions/302122/jquery-event-keypress-which-key-was-pressed

[ryan]

Thanks Pete that's a good find. From what I understand here, it looks like jQuery normalizes it into e.which, and that's all that we'd need to check? I will give this a try. It sounds like the ui.keycode stuff is just translations of common keycodes, but useful nonetheless.