Drop distinction between style name and style path

[naderman]

If we want to, we can probably still load some display name from the config file on the acp/ucp pages, but I really think that the standard way to refer to a style should simply be a proper directory name. We should definitely not store the display name in the db or use it to reference to the style anywhere other than to display it to a user.

[brunoais]

^
That is more like what I'm after. The name (with all the UTF-8 characters) is for the user to see something "pretty". For all the rest, the name does not matter, it's equal to the directory name.

[ecwpa]

Now that you mention it, if the board administrator disable the option for users to pick a style, shouldn't that option be hidden to users then? Same goes for boards with only one language. Those are 2 options doing nothing on a lot of boards.

Yes, I agree. Please create a ticket on our tracker at http://tracker.phpbb.com that we should remove that option if only one style is available.

Done. This is my first time I think, hope I did it right.

[naderman]

Yup looks good, thank you!

[Arty]

Submitted patch.

I didn't limit style names to anything, except that directory should not have a dot in first character. As long as path is a valid directory, doesn't start with dot and it has style.cfg in it, it should be valid. I think that if admin wants to create style with Cyrillic or some other letters, I don't see a point in not allowing admin to do that.

But I can add limitation for style names if its needed.

[naderman]

Well the reason to add those limitations, is to avoid issues in support with different filesystems (which are not UTF-8), web servers that use something other than UTF-8 for paths, and browsers that urlencode in non-standard ways. So I would recommend we limit style names to [A-Za-z0-9-_]+ to avoid all of these issues.

We can still implement a pretty display name, when we load meta data from composer.json files, and just display that in UCP in ACP where appropriate but it would not be stored in the database.

[brunoais]

^
I'll buy that one.

[Arty]

Good point, I'll update patch.

[Arty]

Added regexp to patch. This also makes includejs bug with style paths like 'test#123' (bug #1 from that ticket) obsolete.

[Oleg]

(17:35:03) nx-: i kind of don't like spaces in directory names
(17:35:14) naderman: me neither
(17:35:15) nx-: but
(17:35:18) nx-: this is irrelevant
(17:35:25) nx-: style display name should be specified in style config
(17:35:33) naderman: yup
(17:35:36) naderman: as discussed there
(17:35:37) nx-: the code should use the name of the directory which is the same as "style name"
(17:35:38) nx-: i guess
(17:35:48) naderman: yes

Keep in mind that some file systems are case sensitive and some are not.

(17:36:35) nx-: don't forget case sensitivity
(17:36:46) naderman: right
(17:36:50) naderman: might want to make the regex
(17:36:54) naderman: lower case only
(17:37:01) naderman: will avoid any problem of the kind
(17:37:05) nx-: so what's the conclusion on allowed chars?
(17:37:17) naderman: [a-z0-9_-]+
(17:37:24) naderman: as in that regex
(17:37:27) naderman: so a-z0-9_-
(17:37:30) naderman: are the allowed chars
(17:37:36) naderman: (since just now, before A-Z was included too)
(17:37:41) nx-: works for me i suppose

I'm ok with restricting style names to lower case for now, we can always expand the regex if needed.