Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
5401
Archived fixes / Re: Time offset (auto detect)
« on April 21st, 2012, 11:09 PM »
- admin area. That's where you forgot Africa ;)
- we don't ask for language but we have the browser's default language at that point... Including regional languages :) eg Quebec.
- then selective Ajax maybe? Ie select continent then we load their timezone list via Ajax. Although it makes it hard to at a default zone with the browser language.
- we don't ask for language but we have the browser's default language at that point... Including regional languages :) eg Quebec.
- then selective Ajax maybe? Ie select continent then we load their timezone list via Ajax. Although it makes it hard to at a default zone with the browser language.
5402
The Pub / Re: The Cookie Law (in the UK at least)
« on April 21st, 2012, 11:03 PM »
I still think we should try tracking guests through their ip if feasable ;)
5403
Archived fixes / Re: Thoughts not display @ on initial post
« on April 21st, 2012, 10:59 PM »
I can probably make it show everything as needed though. This hack was a quick fix when I developed the feature. I just don't remember why I failed to make it work even though it sends the thought back via Ajax...
5404
Features / Re: New revs - Public comments
« on April 21st, 2012, 10:09 PM »The thing about legacy strings is that they're sometimes used in composite form elsewhere e.g. $txt['something_' . $something]
so while it might not be obviously used, it may end up being used anyway, as you mentioned, though some of them will just have to be tested to see if the string isn't used, heh.
The time offset stuff is deprecated, but I didn't remove it pending finishing (or reverting) the timezone stuff.
5405
Archived fixes / Re: Time offset (auto detect)
« on April 21st, 2012, 10:08 PM »Actually, Africa IS listed. I see West Central Africa (UTC+1), South Africa Standard Time (UTC+2) plus places like Cairo that are in Africa last I checked.
Yes, it is 580+, but there are dozens that are legacy and deprecated.
XenForo and phpBB do it. Hell, even Windows, Mac OS X and Ubuntu do it.
If you want to revert it, revert it.
There are three solutions: providing a fuck off big list to users that requires minimal work from us but looks ugly (like in the admin panel), providing a much shorter and more manageable list (like in the profile area, like XenForo, like phpBB, like Windows, like OS X, like Ubuntu) or we can revert to this unintuitive pile of crap that doesn't even work properly for countries that don't have hour-boundary places (like SMF)
5406
Plugins / Re: Message view count.
« on April 21st, 2012, 09:28 PM »
If you think a post is worthy enough to track its view count, then... Just post it as a new topic ;)
Logic rules! :)
Logic rules! :)
5407
Features / Re: New revs
« on April 21st, 2012, 09:26 PM »
rev 1556
(21 files, 12kb) (hopefully I didn't break anything...)
* Translation. (ManageSettings.french.php)
* Continued moving barely used strings from index to satellite language files, and removed outdated or deprecated entries such as 'message_lowercase' or 'search_end_results'. I'm surprised that 'no_matches' doesn't seem to be used anywhere though...! (Reminder.php, Subs-Auth.php, LANGUAGES: Admin, index, Login, ManageTopics, Profile)
* Made media permissions help text into a proper popup. (ManageMedia.template.php, LANGUAGES: Media, Help)
+ Added micro-documentation for the new %@ time format. (Help.language.php)
* French version doesn't use periods at the end of post options, so removed it from a couple of entries. Maybe this should be done for English too...? (Post.french.php)
- Removed a colon and a line-break that bothered me. (ManageMedia.php, Profile.template.php)
(21 files, 12kb) (hopefully I didn't break anything...)
* Translation. (ManageSettings.french.php)
* Continued moving barely used strings from index to satellite language files, and removed outdated or deprecated entries such as 'message_lowercase' or 'search_end_results'. I'm surprised that 'no_matches' doesn't seem to be used anywhere though...! (Reminder.php, Subs-Auth.php, LANGUAGES: Admin, index, Login, ManageTopics, Profile)
* Made media permissions help text into a proper popup. (ManageMedia.template.php, LANGUAGES: Media, Help)
+ Added micro-documentation for the new %@ time format. (Help.language.php)
* French version doesn't use periods at the end of post options, so removed it from a couple of entries. Maybe this should be done for English too...? (Post.french.php)
- Removed a colon and a line-break that bothered me. (ManageMedia.php, Profile.template.php)
5408
Features / Re: New revs - Public comments
« on April 21st, 2012, 09:04 PM »
Oh sorry, missed that :)
I'm currently looking into the index language file. (Also translated the moderation filter stuff.)
It's very interesting... There are plenty of strings that simply aren't used anymore in Wedge (and probably in SMF too), and they're still in the index file...
Obviously I'm removing them, but we'll have to be careful whether or not they were actually used by modified in such a way that they can't be found with a simple search on the name :)
For instance, $txt['time_offset'] is no longer used anywhere but in the Profile template, so I'm moving it over there.
Also, template_profile_timeoffset_modify() seems to be a leftover from the previous system. Did you keep it "just in case" or was it an oversight?
I'm currently looking into the index language file. (Also translated the moderation filter stuff.)
It's very interesting... There are plenty of strings that simply aren't used anymore in Wedge (and probably in SMF too), and they're still in the index file...
Obviously I'm removing them, but we'll have to be careful whether or not they were actually used by modified in such a way that they can't be found with a simple search on the name :)
For instance, $txt['time_offset'] is no longer used anywhere but in the Profile template, so I'm moving it over there.
Also, template_profile_timeoffset_modify() seems to be a leftover from the previous system. Did you keep it "just in case" or was it an oversight?
5409
Features / Re: New revs - Public comments
« on April 21st, 2012, 08:14 PM »Why the fuck is that string there? I certainly didn't put it there.
It was already in SMF2, if you want to have a look!
Mind you, this is related to what I've been saying about splitting some of those files - the view I hold is that index should hold stuff that's used everywhere or on the 'majority' of pages. Stuff in topics, for example, would be OK there.
Thanks for doing it in the latest rev, BTW...!
I just have a note about the moderation filter for link count... They won't take [URL] tags into account, will they...? i.e. they're case-sensitive here. Is it as desired?
5410
Features / Re: Things to do before the Mayan apocalypse: membergroups
« on April 21st, 2012, 03:32 PM »
Sorry I've been too busy irl since yesterday to deal with this topic. Will do later.
Jut wanted to mention that in order to get a single entry even with a left join, you can use group_concat() which is Mysql 4.1+.
Dunno about performance but it's certainly a simple way to reproduce the existing feature.
Just wanted to post this to save you time thinking about a solution :)
Jut wanted to mention that in order to get a single entry even with a left join, you can use group_concat() which is Mysql 4.1+.
Dunno about performance but it's certainly a simple way to reproduce the existing feature.
Just wanted to post this to save you time thinking about a solution :)
5411
Features / Things to do before the Mayan apocalypse: membergroups
« on April 20th, 2012, 10:37 AM »
(Again, see the 'general' topic for more details on these Mayan topics.)
- Custom membergroups: this one is harder because it has so many ramifications. I'm going to try and address most of them. So, basically:
1/ Add an id_owner (id_member) field to the membergroups table.
2/ Add an interface for users to create membergroups. Very simply: take the admin interface for that, and remove the second half of the membergroup creation page. There are many options that shouldn't be available for non-admin members, and 99% of them are in the second half, very conveniently.
3/ Add more membergroup types. Things like 'hidden' and such are good, but the first membergroup a user creates should be considered their 'friend list' (what I call 'contact list'.)
4/ Add more membergroup fine-tuning. This is a thing I have in Noisen and am really fond of -- I can determine whether people can see all or part of my friends list. Some of my friends I chose to keep in a 'hidden' state so that they would benefit from being in my friends list, without being visible as one of my friends. Perhaps this could be 'simplified' (for code) into two groups: a regular 'friends' group and a hidden 'friends' group... I'd rather have an extra field for that, though. And it's just an example.
5/ Now for the hard parts...
(a) Write some UI for group selection in privacy settings. Not too complicated when it comes to setting privacy from the posting page, but I also want to be able to set privacy on the fly through a select box, like I'm doing on Noisen.com (although it's not a select box there, it's actually a rewrite of the icon selector). The difficulty is not in writing the thing, but in making it so that it's *easy* to understand and use.
(b) And the single most frightening thing for me... Dealing with the aftermath of being able to create membergroups for anything. Basically, from my experience on Noisen, I know that people aren't going to spend their days creating membergroups, but if they end up doing it, it could easily break Wedge if not handled correctly. Do you remember when Facebook had a limit on how many friends you could have? I think it was 5000. It was a lot though, and I doubt any forum would be penalized by having such a high limit on the number of friends. I'm still going to assume that 10k users are going to add Mike42 to at least one of their membergroups, and Mike42 is going to add 10k users to his own 'friends' group (reciprocal friend additions -- that'd be asynchronous in Wedge, i.e. not mandatory, unlike SMF.)
So, we have a members table where the additional_groups field for Mike42 contains 10k comma-separated group IDs... Which probably makes it even impossible to store additional_groups into a TEXT field. (I guess MEDIUMTEXT would do...)
Even then -- it's going to kill performance, whatever we do about it. So we need 3NF for membergroups too. We discussed it at length but, yet, nothing has come of it. I'm getting wary of it, Pete is getting wary of it... I even recently read an old discussion on sm.org where Pete (yes, you Pete :P) actually discussed how 3NF could kill performance if table joins were used everywhere.
Now we have 3 ways of dealing with this... Either we just set a (relatively) low limit on the number of people you can put into a custom membergroup, and/or number of groups you can be put into, in which case I guess staying with the current SMF way of doing things is all right, or we add 3NF and still keep the additional_groups field and up the limit (but not too much), or we do it entirely 3NF and get rid of additional_groups, get rid of any limits and scream at the performance issues later...
- Custom membergroups: this one is harder because it has so many ramifications. I'm going to try and address most of them. So, basically:
1/ Add an id_owner (id_member) field to the membergroups table.
2/ Add an interface for users to create membergroups. Very simply: take the admin interface for that, and remove the second half of the membergroup creation page. There are many options that shouldn't be available for non-admin members, and 99% of them are in the second half, very conveniently.
3/ Add more membergroup types. Things like 'hidden' and such are good, but the first membergroup a user creates should be considered their 'friend list' (what I call 'contact list'.)
4/ Add more membergroup fine-tuning. This is a thing I have in Noisen and am really fond of -- I can determine whether people can see all or part of my friends list. Some of my friends I chose to keep in a 'hidden' state so that they would benefit from being in my friends list, without being visible as one of my friends. Perhaps this could be 'simplified' (for code) into two groups: a regular 'friends' group and a hidden 'friends' group... I'd rather have an extra field for that, though. And it's just an example.
5/ Now for the hard parts...
(a) Write some UI for group selection in privacy settings. Not too complicated when it comes to setting privacy from the posting page, but I also want to be able to set privacy on the fly through a select box, like I'm doing on Noisen.com (although it's not a select box there, it's actually a rewrite of the icon selector). The difficulty is not in writing the thing, but in making it so that it's *easy* to understand and use.
(b) And the single most frightening thing for me... Dealing with the aftermath of being able to create membergroups for anything. Basically, from my experience on Noisen, I know that people aren't going to spend their days creating membergroups, but if they end up doing it, it could easily break Wedge if not handled correctly. Do you remember when Facebook had a limit on how many friends you could have? I think it was 5000. It was a lot though, and I doubt any forum would be penalized by having such a high limit on the number of friends. I'm still going to assume that 10k users are going to add Mike42 to at least one of their membergroups, and Mike42 is going to add 10k users to his own 'friends' group (reciprocal friend additions -- that'd be asynchronous in Wedge, i.e. not mandatory, unlike SMF.)
So, we have a members table where the additional_groups field for Mike42 contains 10k comma-separated group IDs... Which probably makes it even impossible to store additional_groups into a TEXT field. (I guess MEDIUMTEXT would do...)
Even then -- it's going to kill performance, whatever we do about it. So we need 3NF for membergroups too. We discussed it at length but, yet, nothing has come of it. I'm getting wary of it, Pete is getting wary of it... I even recently read an old discussion on sm.org where Pete (yes, you Pete :P) actually discussed how 3NF could kill performance if table joins were used everywhere.
Now we have 3 ways of dealing with this... Either we just set a (relatively) low limit on the number of people you can put into a custom membergroup, and/or number of groups you can be put into, in which case I guess staying with the current SMF way of doing things is all right, or we add 3NF and still keep the additional_groups field and up the limit (but not too much), or we do it entirely 3NF and get rid of additional_groups, get rid of any limits and scream at the performance issues later...
5412
Features / Things to do before the Mayan apocalypse: floating topics
« on April 20th, 2012, 10:36 AM »
(See the 'general' topic for details on the purpose of these topics...)
- Floating topics: again that issue... It's something I was very adamant to do when I started work on Wedge. As a reminder: being able to specify a topic type that would be beyond just 'topic', such as 'gallery item'... I guess I kinda lost myself in it for two reasons.
The first is that I also wanted to (and actually started to implement, long ago) have boards be 'floating' as well... Meaning a board can be a blog (which is already done as you can see), or a website (I have yet to start work on this but basically the main difference with a blog is the message index). From that point on, topics change their nature based on what the board is. So at some point I considered simply adding 'gallery album' to the board types. Which absolutely makes sense when you think about it... And I kinda let go of my 'floating topics' concept in the meantime.
What happened after that, is that tumblr showed up, with their 'post types', and WordPress took their idea too. "Hey!", I thought. "That's my floating topic idea!"... Well, it's not like it was the most original idea in the world anyway (I have plenty of original ideas, many of which found their way into the Wedge codebase, but I'm not calling dibs on every single good idea :P), but at that point I started to wonder what was best... Which is possibly why I just left it aside. If I'm going to be 'realistic' in my targets, I think I should stick to 'floating boards' from now on. There are always ways to make a meta-board in the future (hey, that's a floating board item too :P) that would reunite all of its sub-boards' topics into the message index anyway...
- Floating topics: again that issue... It's something I was very adamant to do when I started work on Wedge. As a reminder: being able to specify a topic type that would be beyond just 'topic', such as 'gallery item'... I guess I kinda lost myself in it for two reasons.
The first is that I also wanted to (and actually started to implement, long ago) have boards be 'floating' as well... Meaning a board can be a blog (which is already done as you can see), or a website (I have yet to start work on this but basically the main difference with a blog is the message index). From that point on, topics change their nature based on what the board is. So at some point I considered simply adding 'gallery album' to the board types. Which absolutely makes sense when you think about it... And I kinda let go of my 'floating topics' concept in the meantime.
What happened after that, is that tumblr showed up, with their 'post types', and WordPress took their idea too. "Hey!", I thought. "That's my floating topic idea!"... Well, it's not like it was the most original idea in the world anyway (I have plenty of original ideas, many of which found their way into the Wedge codebase, but I'm not calling dibs on every single good idea :P), but at that point I started to wonder what was best... Which is possibly why I just left it aside. If I'm going to be 'realistic' in my targets, I think I should stick to 'floating boards' from now on. There are always ways to make a meta-board in the future (hey, that's a floating board item too :P) that would reunite all of its sub-boards' topics into the message index anyway...
5413
Features / Things to do before the Mayan apocalypse: general
« on April 20th, 2012, 10:35 AM »
Okay, I was going through our to-do-lists and so on... And I'm a bit upset that there are so many things that I want to be done with, and are either barely implemented, or not at all...
I'm not going to list Pete's fave areas (plugins etc), so it's really just about the things I personally want to have for the Beta version (i.e. possibly post-alpha, but preferrably pre-alpha.)
- Blogs (1): need to implement tags (if I re-use my Noisen codebase, it's not going to take long but maybe it'd be better to have a 3NF implementation rather than my limited tag field in the topic table...),
- Blogs (2): need to finish the message index layout (currently it still looks too much like a topic index... needs to be closer to what I did at http://nao.noisen.com), things like that.
- Gallery: well, there's the delicate issue of using AeMe to handle attachments... Frankly, as I said before, this isn't going to be in beta, or even in gold, but I'm still considering it for Wedge 2.0, as long as I write a quick converter inside the admin area. This isn't my priority though... Heck, we could even 'get away' with implementing an attachment viewer inside the gallery area. :)
- Custom boards: ability for users to create their own boards, or blogs. This one shouldn't be hard to implement. It's already in the Noisen codebase and only needs some tightening... Mainly, separating the UI from the Admin area and move it to the Profile area (which would give us yet another opportunity to rename it to 'Account area'...)
I think I'm done for now... I may have forgotten stuff. I have two more items to discuss but they're so big, I'll create two separate topics
Please discuss any items you want in this list.
I'm not going to list Pete's fave areas (plugins etc), so it's really just about the things I personally want to have for the Beta version (i.e. possibly post-alpha, but preferrably pre-alpha.)
- Blogs (1): need to implement tags (if I re-use my Noisen codebase, it's not going to take long but maybe it'd be better to have a 3NF implementation rather than my limited tag field in the topic table...),
- Blogs (2): need to finish the message index layout (currently it still looks too much like a topic index... needs to be closer to what I did at http://nao.noisen.com), things like that.
- Gallery: well, there's the delicate issue of using AeMe to handle attachments... Frankly, as I said before, this isn't going to be in beta, or even in gold, but I'm still considering it for Wedge 2.0, as long as I write a quick converter inside the admin area. This isn't my priority though... Heck, we could even 'get away' with implementing an attachment viewer inside the gallery area. :)
- Custom boards: ability for users to create their own boards, or blogs. This one shouldn't be hard to implement. It's already in the Noisen codebase and only needs some tightening... Mainly, separating the UI from the Admin area and move it to the Profile area (which would give us yet another opportunity to rename it to 'Account area'...)
I think I'm done for now... I may have forgotten stuff. I have two more items to discuss but they're so big, I'll create two separate topics
Please discuss any items you want in this list.
5414
Off-topic / Re: QapTcha
« on April 20th, 2012, 07:54 AM »
Basically a bot could even implement it's own pseudo code to emulate whatever js does.
Too bad eh :)
This should be moved to a private place as it mentions Wedge specific security.
Too bad eh :)
This should be moved to a private place as it mentions Wedge specific security.