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
4591
Features / Re: New revs
« on August 24th, 2012, 04:54 PM »
rev 1675
(7 files, 4kb)
! Wuthering was a bit broken in modern browsers by my IE fixes. I know, known song -- should try everything thoroughly before I commit... Decided to simplify the code and use the IE code everywhere instead. It looks just the same and is shorter. (Wuthering/extra.css, Wuthering/extra.ie[-9].css)
! Fixed blockquote backgrounds in Warm. (Warm/extra.css)
! Fixed background in topic lists in Wine, Warm and Wuthering. A disappointing little oversight that pretty much broke these pages entirely... Not sure why no one reported it in the first place. (Wine/extra.css)
* Don't waste time trying to analyze CSS suffixes when there's none in the first place! (Subs-Cache.php)
* Simplified variables in editor CSS. (editor.css)
* Added a todo note to myself... (Class-CSS.php)
(7 files, 4kb)
! Wuthering was a bit broken in modern browsers by my IE fixes. I know, known song -- should try everything thoroughly before I commit... Decided to simplify the code and use the IE code everywhere instead. It looks just the same and is shorter. (Wuthering/extra.css, Wuthering/extra.ie[-9].css)
! Fixed blockquote backgrounds in Warm. (Warm/extra.css)
! Fixed background in topic lists in Wine, Warm and Wuthering. A disappointing little oversight that pretty much broke these pages entirely... Not sure why no one reported it in the first place. (Wine/extra.css)
* Don't waste time trying to analyze CSS suffixes when there's none in the first place! (Subs-Cache.php)
* Simplified variables in editor CSS. (editor.css)
* Added a todo note to myself... (Class-CSS.php)
4592
Off-topic / Re: PHPSESSID Brute force
« on August 24th, 2012, 08:10 AM »
Why would they be screwed I we just ask them to confirm their password, like in the admin area?
4593
Off-topic / Re: I know what. I can't figure out how to ask how.
« on August 24th, 2012, 12:44 AM »
Aeva Media does all of that, AFAIK. (Version 2.1x at least.)
And Wedge, of course. :P
If you're going to host on a different server, you'll have to provide a download link after uploading by FTP or something. Otherwise I don't really see how it could work...
And Wedge, of course. :P
If you're going to host on a different server, you'll have to provide a download link after uploading by FTP or something. Otherwise I don't really see how it could work...
4594
Off-topic / Re: PHPSESSID Brute force
« on August 24th, 2012, 12:43 AM »
Still reduces chances of session hijacking by 99%...
We don't need a solution for everything. We just need stuff that helps.
We don't need a solution for everything. We just need stuff that helps.
4595
The Pub / Re: Getting ready for an alpha release...
« on August 24th, 2012, 12:38 AM »
Just had a silly idea, but well...
Adding a 'mobile' variable to $context['browser'], similar to 'webkit', but being based upon $user_info['is_mobile'] instead. This would allow skinners to create index.mobile.css files for mobile devices.
However, all devices go through the mobile path, and thus are usually redirected to the Wireless skin, so it might be a bit overkill to additionally offer this keyword...
Anyway...
Adding a 'mobile' variable to $context['browser'], similar to 'webkit', but being based upon $user_info['is_mobile'] instead. This would allow skinners to create index.mobile.css files for mobile devices.
However, all devices go through the mobile path, and thus are usually redirected to the Wireless skin, so it might be a bit overkill to additionally offer this keyword...
Anyway...
4596
Features / Re: New revs
« on August 23rd, 2012, 07:48 PM »
rev 1674
(2 files, 1kb)
* Modified board/message index behavior to only set the board icon to its 'new' state if it directly has new topics in it. Sub-boards already have their own 'new' badge anyway! Smallest commit in days. Size doesn't always matter. (Boards.template.php, MessageIndex.template.php)
(2 files, 1kb)
* Modified board/message index behavior to only set the board icon to its 'new' state if it directly has new topics in it. Sub-boards already have their own 'new' badge anyway! Smallest commit in days. Size doesn't always matter. (Boards.template.php, MessageIndex.template.php)
4597
The Pub / Re: Getting ready for an alpha release...
« on August 23rd, 2012, 07:45 PM »I'd leave database changes for now, ultimately. You're right that it's very complicated.
As far as upgrading goes, I really wouldn't bother worrying about it for the alpha. Anyone that uses an alpha should be prepared for anything and everything, including manual DB changes, and shouldn't be using it on a production site anyway.
What could be done, sorta, is getting the new install.sql file, and doing a pseudo installation, i.e. running it with a setting of db_prefix = db_prefix + 'temp_install_whatever', and then compare the tables... (Or whatever.)
I'd suggest just committing the changes to Aeva and Subs-BBC.
That's why I want to be sure that it works as is, right now...
If anything, I know that footnotes are still buggy in some respect. I mean, when you accumulate multiple quotes with multiple footnotes in them.. It starts to fail. Kind of thing I haven't worked on lately. Was too busy on CSS crap...
Most things work as expected at this point in time. (Though it would be nice if we can get Aeva to use the no-cookies version of the YT embed code, and ideally using the iframe method rather than a Flash object)
Can you confirm this?
It's really easy to implement the new YT code, it's pretty much the same as in Google Maps (set type to html and use an iframe tag), only simpler :P
That is going to be dependent on the community. There was a thread on AAF discussing the fact that I had a lot less posts than Shawn and yet more likes. If the community notices enough to care, they'll figure out whether they want to make it competitive.
Change it, that's cool. We can worry about performance later.
That makes sense. It would solve a lot of troubles.Quote - shall the board icons be set to 'New' status if there are new topics in the corresponding board, or new topics in the corresponding board *and* its children...? Currently it's the latter, but I think the former would be best, if only because sub-boards have their own 'New' label...
That's the beauty of being an alpha, it doesn't have to be ready in any fashion.
4598
Features / Re: New revs
« on August 23rd, 2012, 07:35 PM »
rev 1673
(4 files, 5kb)
+ Added a new section to the stats page, 'most liked posters', which does what it says: it shows the authors who got the most 'likes' on their body of work. Now if this is going to be a controversial move, please tell us so. As of now, if seems rather harmless and may encourage quality posts. (Stats.php, Stats.template.php, Stats.language.php)
(4 files, 5kb)
+ Added a new section to the stats page, 'most liked posters', which does what it says: it shows the authors who got the most 'likes' on their body of work. Now if this is going to be a controversial move, please tell us so. As of now, if seems rather harmless and may encourage quality posts. (Stats.php, Stats.template.php, Stats.language.php)
4599
Features / Re: New revs
« on August 23rd, 2012, 07:30 PM »
rev 1672
(3 files, 3kb)
+ The Skin Selector will now provide the number of users for each skin (in addition to the global number for their theme.) That wedge_get_skin function is short and sweet, but getting the reference return to work was a PITA... If someone could look into the logic of it and spot any superfluous ampersands, that would be swell... (Themes.php, Themes.template.php)
* Spacinazi. Just two bytes... For a file we'll end up removing. (upgrade.php)
(3 files, 3kb)
+ The Skin Selector will now provide the number of users for each skin (in addition to the global number for their theme.) That wedge_get_skin function is short and sweet, but getting the reference return to work was a PITA... If someone could look into the logic of it and spot any superfluous ampersands, that would be swell... (Themes.php, Themes.template.php)
* Spacinazi. Just two bytes... For a file we'll end up removing. (upgrade.php)
4600
Features / Re: Plugin revs
« on August 23rd, 2012, 07:27 PM »
rev 45
(2 files, 3kb)
! [theme_selector] The skin selector was conflicting horribly with the admin area's theme section where $context['themes'] was also set with an extra param ('known'). Fixed it by renaming the variable, maybe we should add the known bit but I don't think so. (ThemeSelector.php)
* [mass_upload] Updated to latest version of Dragooon's code... I think... Oh, and there may be that extra bit about $.support.cors to detect XHR2, or whatever... (attachui.js)
(2 files, 3kb)
! [theme_selector] The skin selector was conflicting horribly with the admin area's theme section where $context['themes'] was also set with an extra param ('known'). Fixed it by renaming the variable, maybe we should add the known bit but I don't think so. (ThemeSelector.php)
* [mass_upload] Updated to latest version of Dragooon's code... I think... Oh, and there may be that extra bit about $.support.cors to detect XHR2, or whatever... (attachui.js)
4601
Off-topic / Re: PHPSESSID Brute force
« on August 23rd, 2012, 03:06 PM »For the second time... no.
Take one IP address, a couple of time stamps, md5 the lot. Now please tell me how you extract the IP address from this.
- We have the last login IP in the members table
- We have an associated PHPSESSID, right...? (If not, we can record it.)
- We know that some people might want to break the ID... But they don't have the same IP. Why not force IP changes to confirm the password or something?
4602
The Pub / Re: Getting ready for an alpha release...
« on August 23rd, 2012, 02:51 PM »
- I'm not sure whether mass database changes are ideal right now. But I also don't see myself making an upgrade script for all of that... Maybe we can write a script that would automatically parse install.sql, and compare it to your current one (maybe storing the latest used install.sql somewhere in the database in compressed form..?). It would just be a matter of doing a virtual diff of both files, finding the areas where the changes are done, and trying to do them in the database automatically.
But you wanna know...? I don't feel like I'm ever going to write that kind of script. This is where I'm getting crazy.
- I've added a 'fun' little experiment on the Stats page (go see it)... Since there was an empty area, I added a 'Top liked authors' box which has the benefit of showing more names than just Pete and I, ah ah! Well, it's funny because in the end, after all this time with likes enabled etc, it looks like we both have the same amount of posts (approx.), as well as the same number of likes! But I'm wondering whether it's fine to show this box. It's more of a philosophical matter. Do we want to encourage competition for people to get more likes..?
- could someone do tests on wedge.org's test board, posting various embeddable material and seeing if everyone's going all right? (i.e. no double-encoding of links, no broken stuff, works everywhere, works when posting in quick reply, quick modify, reply and modify...) Because wedge.org has been running a custom Aeva-Embed.php and Subs-BBC.php for quite some time now (including the removal and addition of an AWFUL lot of code), and I think it's going to be time to commit it...
- shall I count theme users per skin or per theme in the Skin Selector page? It only involves replacing "id_theme" with "id_theme, id_skin" in the SQL query for that -- but it might not help when it comes to performance...
- shall the board icons be set to 'New' status if there are new topics in the corresponding board, or new topics in the corresponding board *and* its children...? Currently it's the latter, but I think the former would be best, if only because sub-boards have their own 'New' label...
- just for the record: I'm currently reworking (quite heavily) the layouts for the Search page and Media page (homepage mostly). And I'm totally not happy, and I totally need to commit before we go alpha... :-/
Aaaaand, that's all for now.
And I haven't even had a look into my to-do-list for months, really... What fun to be had!
But you wanna know...? I don't feel like I'm ever going to write that kind of script. This is where I'm getting crazy.
- I've added a 'fun' little experiment on the Stats page (go see it)... Since there was an empty area, I added a 'Top liked authors' box which has the benefit of showing more names than just Pete and I, ah ah! Well, it's funny because in the end, after all this time with likes enabled etc, it looks like we both have the same amount of posts (approx.), as well as the same number of likes! But I'm wondering whether it's fine to show this box. It's more of a philosophical matter. Do we want to encourage competition for people to get more likes..?
- could someone do tests on wedge.org's test board, posting various embeddable material and seeing if everyone's going all right? (i.e. no double-encoding of links, no broken stuff, works everywhere, works when posting in quick reply, quick modify, reply and modify...) Because wedge.org has been running a custom Aeva-Embed.php and Subs-BBC.php for quite some time now (including the removal and addition of an AWFUL lot of code), and I think it's going to be time to commit it...
- shall I count theme users per skin or per theme in the Skin Selector page? It only involves replacing "id_theme" with "id_theme, id_skin" in the SQL query for that -- but it might not help when it comes to performance...
- shall the board icons be set to 'New' status if there are new topics in the corresponding board, or new topics in the corresponding board *and* its children...? Currently it's the latter, but I think the former would be best, if only because sub-boards have their own 'New' label...
- just for the record: I'm currently reworking (quite heavily) the layouts for the Search page and Media page (homepage mostly). And I'm totally not happy, and I totally need to commit before we go alpha... :-/
Aaaaand, that's all for now.
And I haven't even had a look into my to-do-list for months, really... What fun to be had!
4603
The Pub / Re: Getting ready for an alpha release...
« on August 23rd, 2012, 02:36 PM »
@John> Are you implying that Wedge will never be installed on a successful forum? :PQuote from Arantor on August 18th, 2012, 08:40 PM Additionally there are some fuck-ups...
For instance, let's take the group ID.
By design, SMF considers guests as group '-1'. Meaning that everytime the guest group has no reason to be stored in the database (simple example: the members table, they can't belong to the guest group...), we can safely use int(10) unsigned, but when it needs to be taken into account (example: permission tables), we have to use int(10) signed. I'm saying int(10) and not int(11) because if the negative number is never going to be < -10, there's no reason to account for the minus sign, but it doesn't matter as it's only for representation purposes in the command line as you said.
So, I don't even know if it's worth storing unsigned at all, because there are going to be situations where id_group > maxint/2 and thus will be stored correctly in some places (members), and badly in others (perms).Quote I thought we'd discussed that it'd be best to get rid of additional_groups and instead use a subselect..?
An alternative would simply be to limit the numbers of groups you can create, number of people you can put in them, and number of groups you can belong to. i.e. have to find some technical way of allowing you to join any group, but disallowing people from adding you to their groups after a while.
Of course, in a realistic environment, it's unlikely that more than 0.0000001% of all Wedge installs will ever need to have more than a few hundred spaces 'available' for storing groups and so on.Quote And these forums are precisely the ones that need the expanding...
And if they're big, they can afford the extra hardware to handle the extra weight :P
(And you can retort that they can also afford to hire us to augment their database field sizes and optimize everything even more. :lol:)
Also, it's worth noting that Dragooon's original database schema for SMG was... A little bit skewed towards integer fields. Many fields have an int(11) definition even for storing small numbers -- e.g. the width/height fields in media_files are integers when they could just as well be smallint(4), i.e. < 65536... I don't see any realistic scenario where an online uploaded image would be wider/taller than that.Quote My point exactly. :)
smallint ranges from -32768 to 32767 (0 to 65535 when unsigned)
mediumint has a range of +/- 8 million (16m when unsigned)
int has a range of +/- 2 billion (4 billion when unsigned)
For instance, let's take the group ID.
By design, SMF considers guests as group '-1'. Meaning that everytime the guest group has no reason to be stored in the database (simple example: the members table, they can't belong to the guest group...), we can safely use int(10) unsigned, but when it needs to be taken into account (example: permission tables), we have to use int(10) signed. I'm saying int(10) and not int(11) because if the negative number is never going to be < -10, there's no reason to account for the minus sign, but it doesn't matter as it's only for representation purposes in the command line as you said.
So, I don't even know if it's worth storing unsigned at all, because there are going to be situations where id_group > maxint/2 and thus will be stored correctly in some places (members), and badly in others (perms).
You cannot assign that many groups to users, because if you have that many, the additional_groups will overflow IIRC as it only has so much space.
An alternative would simply be to limit the numbers of groups you can create, number of people you can put in them, and number of groups you can belong to. i.e. have to find some technical way of allowing you to join any group, but disallowing people from adding you to their groups after a while.
Of course, in a realistic environment, it's unlikely that more than 0.0000001% of all Wedge installs will ever need to have more than a few hundred spaces 'available' for storing groups and so on.
And, also, I'm still not comfortable expanding ids just for the sake of it - it WILL have a performance penalty on indexes on larger forums.
And if they're big, they can afford the extra hardware to handle the extra weight :P
(And you can retort that they can also afford to hire us to augment their database field sizes and optimize everything even more. :lol:)
Also, it's worth noting that Dragooon's original database schema for SMG was... A little bit skewed towards integer fields. Many fields have an int(11) definition even for storing small numbers -- e.g. the width/height fields in media_files are integers when they could just as well be smallint(4), i.e. < 65536... I don't see any realistic scenario where an online uploaded image would be wider/taller than that.
I can see the use for millions of groups - user created contact lists. (Though the group column MUST remain signed in most places e.g. with permissions, where permissions are required to apply to guests which are group -1. I can't consider the need for literally billions of groups, though even with a signed mediumint, that's still a column running into the millions, which I can imagine could be the case.)
4604
Features / Re: New revs
« on August 23rd, 2012, 09:46 AM »
rev 1671 (keyboard shortcuts & post preview tweaks. Could have been split into two commits, had I been more careful...)
(10 files, 9kb)
+ Post pages now implement keyboard shortcuts while editing *for all browsers*: Alt+D (draft), Ctrl+B (bold), Ctrl+I (italics) and Ctrl+U (underline), along with the previous Alt+P (preview) and Alt+S (submit). Up until now, and that was also the case in SMF, they were only supported in non-Wysiwyg in Firefox, or everywhere in Wysiwyg but undocumented. It just needed a bit more work to make all shortcuts usable everywhere in non-Wysiwyg, the first action being to remove the is_ff test, ah ah. And of course, using proper jQuery-powered events. (editor-func.js, editor.js)
* Simplified the JS code for shortcuts and Ajax parsing in the editor. A LOT. Close to an unzipped kilobyte of code was happily stripped away from the file (which I reckon sounded better than 'over 150 bytes of gzipped code'.) Optimized post-Ajax code by using jQuery instead of getElementsByTagName. Event bubbling is handled in a single instruction by jQuery. Also, SMF seemed intent on doing a lot of stuff (it even mentions it in a comment) to simulate a Submit button click, when it could just have, ahem... called .click() on the button itself. Plus it's a mandatory method in HTML5, it handles onsubmit as well, and is available for all browsers in jQuery anyway. (editor.js)
* Updated language strings to reflect the current state of keyboard shortcuts. Removed the Opera and Firefox special cases, and stopped bothering with the accesskey stuff. I'm not removing the accesskey (you never know), but I'm not going to document them. (PersonalMessage.template.php, Post.template.php, Post.language.php, editor.css)
! Fixed post preview not working in IE 6/7 because of some bad CSS property targeting: just using 'border' could return 'undefined' if not set specifically, while 'border-color' always returns something. I could have gotten away with doing an implicit string conversion, but let's do it properly instead. (post.js)
* Improved post preview styling. (Post.template.php, editor.css, extra.ie*.css)
(10 files, 9kb)
+ Post pages now implement keyboard shortcuts while editing *for all browsers*: Alt+D (draft), Ctrl+B (bold), Ctrl+I (italics) and Ctrl+U (underline), along with the previous Alt+P (preview) and Alt+S (submit). Up until now, and that was also the case in SMF, they were only supported in non-Wysiwyg in Firefox, or everywhere in Wysiwyg but undocumented. It just needed a bit more work to make all shortcuts usable everywhere in non-Wysiwyg, the first action being to remove the is_ff test, ah ah. And of course, using proper jQuery-powered events. (editor-func.js, editor.js)
* Simplified the JS code for shortcuts and Ajax parsing in the editor. A LOT. Close to an unzipped kilobyte of code was happily stripped away from the file (which I reckon sounded better than 'over 150 bytes of gzipped code'.) Optimized post-Ajax code by using jQuery instead of getElementsByTagName. Event bubbling is handled in a single instruction by jQuery. Also, SMF seemed intent on doing a lot of stuff (it even mentions it in a comment) to simulate a Submit button click, when it could just have, ahem... called .click() on the button itself. Plus it's a mandatory method in HTML5, it handles onsubmit as well, and is available for all browsers in jQuery anyway. (editor.js)
* Updated language strings to reflect the current state of keyboard shortcuts. Removed the Opera and Firefox special cases, and stopped bothering with the accesskey stuff. I'm not removing the accesskey (you never know), but I'm not going to document them. (PersonalMessage.template.php, Post.template.php, Post.language.php, editor.css)
! Fixed post preview not working in IE 6/7 because of some bad CSS property targeting: just using 'border' could return 'undefined' if not set specifically, while 'border-color' always returns something. I could have gotten away with doing an implicit string conversion, but let's do it properly instead. (post.js)
* Improved post preview styling. (Post.template.php, editor.css, extra.ie*.css)
4605
Features / Re: New revs
« on August 23rd, 2012, 12:21 AM »
rev 1670
(5 files, 3kb)
* Converted the CSS variable code to accept the new hasBrowser system. I think it's all that was missing..? (Class-CSS.php)
! A bytesize optimization for IE resulted in select boxes being broken. Ah, where doeth my mind wander... (index.template.php)
! The .wrc class being so generic, should, I believe, or at least I should hope so, be setting its box-sizing to border-box so that its custom padding doesn't screw up any layout. Of course with my current luck, it'll probably end up breaking something else... As long as it's just a Ming vase, I'm fine with it. (index.css)
* Sometimes, I'll have a look at some code and think, 'what was that developer trying to do?'... And then I'll figure, 'okay, there's an easier way to do that...' One of these things happened today, with a bizarre substr test that could just be trimmed down to a '.indexOf(var) == 0'... SMF is like a gold mine. I always find something to dig into, and I'm ready to spend hours just to save a couple of gzipped bytes. My very own personal nuggets. (admin.js, script.js)
(5 files, 3kb)
* Converted the CSS variable code to accept the new hasBrowser system. I think it's all that was missing..? (Class-CSS.php)
! A bytesize optimization for IE resulted in select boxes being broken. Ah, where doeth my mind wander... (index.template.php)
! The .wrc class being so generic, should, I believe, or at least I should hope so, be setting its box-sizing to border-box so that its custom padding doesn't screw up any layout. Of course with my current luck, it'll probably end up breaking something else... As long as it's just a Ming vase, I'm fine with it. (index.css)
* Sometimes, I'll have a look at some code and think, 'what was that developer trying to do?'... And then I'll figure, 'okay, there's an easier way to do that...' One of these things happened today, with a bizarre substr test that could just be trimmed down to a '.indexOf(var) == 0'... SMF is like a gold mine. I always find something to dig into, and I'm ready to spend hours just to save a couple of gzipped bytes. My very own personal nuggets. (admin.js, script.js)