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
3166
Features / Re: New revs
« on April 21st, 2013, 11:32 AM »
rev 2066 -- making Wedge less buggy, one file at a time.
(1 file, 3kb)
! Fixed member recount. Since Pete doesn't seem to be available to tell me what's best, I've done a tentative fix that seems to work. (ManageMaintenance.php)
- Takes recycle board into account (and yes, I still want to remove that crap from Wedge...), since these boards still advertise themselves as wanting post counts, and we have to exclude them manually;
- adds a GROUP BY clause to ensure we get all members in the final recount query. I'm surprised Pete's original commit from nearly 2000 revs ago already didn't have it...
- updates post count as well for members that aren't found in the messages table anymore. At least, in the case of test boards, it can be useful.
(1 file, 3kb)
! Fixed member recount. Since Pete doesn't seem to be available to tell me what's best, I've done a tentative fix that seems to work. (ManageMaintenance.php)
- Takes recycle board into account (and yes, I still want to remove that crap from Wedge...), since these boards still advertise themselves as wanting post counts, and we have to exclude them manually;
- adds a GROUP BY clause to ensure we get all members in the final recount query. I'm surprised Pete's original commit from nearly 2000 revs ago already didn't have it...
- updates post count as well for members that aren't found in the messages table anymore. At least, in the case of test boards, it can be useful.
3167
Features / Re: New revs
« on April 20th, 2013, 08:03 PM »
rev 2065 -- I like nested stuff!
(7 files, 4kb)
+ Finally added support for mini-menus in thought threads ("In context" pages). Tough job... Also added privacy icons to them; I'm not sure why I forgot to show them in the first place... (Ajax.php, Thoughts.php, Thoughts.template.php, index.member.css, sections.css)
* Don't show a hard link to user's posts in their profile page if they never posted. Link remains available in the profile menu, but feel free to remove it as well. I don't mind either way... (Profile.template.php)
! Mini-menu would fail to position correctly when un-ignoring a post from an ignored user, and then attempting to open the 'More' link. (Display.template.php)
* Moved some inline styles to CSS. (Thoughts.template.php, sections.css)
* Multiple extends (extends ".class1, .class2") are cool, but not so much when .class2 doesn't do anything special... (sections.css)
(7 files, 4kb)
+ Finally added support for mini-menus in thought threads ("In context" pages). Tough job... Also added privacy icons to them; I'm not sure why I forgot to show them in the first place... (Ajax.php, Thoughts.php, Thoughts.template.php, index.member.css, sections.css)
* Don't show a hard link to user's posts in their profile page if they never posted. Link remains available in the profile menu, but feel free to remove it as well. I don't mind either way... (Profile.template.php)
! Mini-menu would fail to position correctly when un-ignoring a post from an ignored user, and then attempting to open the 'More' link. (Display.template.php)
* Moved some inline styles to CSS. (Thoughts.template.php, sections.css)
* Multiple extends (extends ".class1, .class2") are cool, but not so much when .class2 doesn't do anything special... (sections.css)
3168
Archived fixes / Re: Member recount
« on April 20th, 2013, 07:56 PM »I wouldn't use the first option as you will end up executing two update statements for each user
The second option seems better, count all posts based on user ID into an array and then run an update statement when the value in the array is greater then the value in the user post count filed.
Or you could use a single query to update all users similar to the below query.Code: [Select] UPDATE {user_table}
SET {post_count}=(
SELECT COUNT({post_id})
FROM {post_table}
WHERE {user_id_field}={user_id}
)
WHERE {user_id_field}={user_id};
3169
Features / Re: Choosing useless images to remove...
« on April 20th, 2013, 07:52 PM »
I agree, I prefer textual links handled nicely, rather than icons + texts in some situations...
Hell, even the mini-menus and moderation buttons in Wedge aren't exactly very pretty. Their icons lack unity. It shows less in mini-menus because I was a bitch and added an opacity hack to make it 'look like' they had unity, ah ah... (Well, as long as it works...)
In this particular case, I'm not only looking into removing notify.gif, but also removing the Notify link from all pages except Display pages...
Hell, even the mini-menus and moderation buttons in Wedge aren't exactly very pretty. Their icons lack unity. It shows less in mini-menus because I was a bitch and added an opacity hack to make it 'look like' they had unity, ah ah... (Well, as long as it works...)
In this particular case, I'm not only looking into removing notify.gif, but also removing the Notify link from all pages except Display pages...
3170
Archived fixes / Member recount
« on April 20th, 2013, 05:28 PM »
I was trying to recount members on my local install, which has the Wedge.org member database, but without any posts.
It turns out that, from looking at the source code, it first gets a list of members, then counts how many posts they have in the message table, then updates their counts.
However, if a user has no message at all in the table, their account will simply be ignored...
Two possible solutions:
- Set all members to 0 posts at the start of the process. Would make sense... Especially since this is already there as a 'fallback' for a strange reason.
- Load all message count entries into the member list, i.e. $members = array(member 1 => 65 posts, 2 => awaiting count, ...), and then after we're done counting, update all members one by one.
I would fix that myself, but as I know that @Arantor rewrote this a while ago, I'm wary of breaking anything.
Hmmm... Nice bug in mentions... I just typed @Arantor, and it showed me a loooong list of 'Arantor' names in the list... It's possibly due to Ajax being slow for me here, so it's getting multiple requests sent before even receiving them.
It turns out that, from looking at the source code, it first gets a list of members, then counts how many posts they have in the message table, then updates their counts.
However, if a user has no message at all in the table, their account will simply be ignored...
Two possible solutions:
- Set all members to 0 posts at the start of the process. Would make sense... Especially since this is already there as a 'fallback' for a strange reason.
- Load all message count entries into the member list, i.e. $members = array(member 1 => 65 posts, 2 => awaiting count, ...), and then after we're done counting, update all members one by one.
I would fix that myself, but as I know that @Arantor rewrote this a while ago, I'm wary of breaking anything.
Hmmm... Nice bug in mentions... I just typed @Arantor, and it showed me a loooong list of 'Arantor' names in the list... It's possibly due to Ajax being slow for me here, so it's getting multiple requests sent before even receiving them.
3171
Features / Choosing useless images to remove...
« on April 20th, 2013, 03:35 PM »
In the last couple of years, Pete and I removed a lot of images from the theme folder, that we considered to be useless.
I'd like to centralize discussion on icons we can/could/should remove from the package.
Starting with notify.gif... This is the icon next to the 'Notify' link in /do/recent/ (list of recent posts), as well as profile contributions, and search results.
I, FWIW, never, ever, ever, ever, ever clicked that button when outside of a topic display. I don't see *any* point in offering users to ability to subscribe to a topic when they're only seeing one post of it... Usually, people will want to click the message, read it in context, and decide whether or not they click Notify on the topic page...
I think no one would ever notice it if I decided to remove that icon, and the associated link. Only the link in Display should remain, and these buttons don't use icons.
What do you think..?
I'd like to centralize discussion on icons we can/could/should remove from the package.
Starting with notify.gif... This is the icon next to the 'Notify' link in /do/recent/ (list of recent posts), as well as profile contributions, and search results.
I, FWIW, never, ever, ever, ever, ever clicked that button when outside of a topic display. I don't see *any* point in offering users to ability to subscribe to a topic when they're only seeing one post of it... Usually, people will want to click the message, read it in context, and decide whether or not they click Notify on the topic page...
I think no one would ever notice it if I decided to remove that icon, and the associated link. Only the link in Display should remain, and these buttons don't use icons.
What do you think..?
3172
Archived fixes / Re: IE 6/7 + mini-menus = headache
« on April 19th, 2013, 07:12 PM »Something to keep in mind is that IE6 has less then 1% market share
However, over half of its users are located in Asia (including a whopping 25% market share in China...), and this isn't our primary target, so it's less of a concern for us.
and IE7 has between 6-9% market share depending which source you use.
From April next year XP is no longer supported so I can foresee a major drop in the usage of IE8 and below due to the fact that Windows 7 only supports IE9+.
Sure, we might get more upgrades from corporate users. But nowadays, most IE6 users are people who don't have a CLUE about what a browser is, their PC is a zombie filled with spyware, and they think their machine has gotten so slow because 'it's a few years old'... No, PCs don't get slower, as long as you clean them up from time to time.
Anyway, I don't think that there's a good reason to prevent our computer-impaired senior users from browsing a Wedge-based forum where they might be finding the exact information they needed to find.
If you take this into consideration with the release date you have in mind for wedge(if you've even thought about a release date yet) you can make a much better informed decision as to whether or not you'll even need to support IE8 and below for the release of wedge.
3173
Features / Re: New revs
« on April 19th, 2013, 07:03 PM »
rev 2064 -- the 'I can already smell someone reverting this...' commit :P
(3 files +1-1, 86kb)
* Updated jQuery to version 2.0 final. They managed to remove hundreds more bytes compared to the very recent beta 3... They're my heroes, definitely. (Load.php, jquery-2.0.0.min.js)
+ Added an optional $txt['lang_hreflang'] string, that can be set to 'force' a language's hreflang for SEO purposes. Not that it's very important, but I wanted to implement it in a clean way that didn't cause any harm to 'main' language files, so this is it... The string falls back to $txt['lang_dictionary'], i.e. the previous default. As of now, the 'code' array entry is no longer used anywhere, so (Load.php, index.template.php, index.english-uk.php)
(3 files +1-1, 86kb)
* Updated jQuery to version 2.0 final. They managed to remove hundreds more bytes compared to the very recent beta 3... They're my heroes, definitely. (Load.php, jquery-2.0.0.min.js)
+ Added an optional $txt['lang_hreflang'] string, that can be set to 'force' a language's hreflang for SEO purposes. Not that it's very important, but I wanted to implement it in a clean way that didn't cause any harm to 'main' language files, so this is it... The string falls back to $txt['lang_dictionary'], i.e. the previous default. As of now, the 'code' array entry is no longer used anywhere, so (Load.php, index.template.php, index.english-uk.php)
3174
Features / Re: New revs
« on April 19th, 2013, 06:31 PM »
rev 2063 -- thought system rewrite! Again!
(8 files, 8kb) -- BTW Pete, since you were wondering: re-indenting an entire block is seen as a full rewrite by SVN, hence your huge commit ;))
* Rewrote large parts of the thought system to improve its flexibility. Basically, every Ajax action will now refresh the entire thought list, which has a few advantages: no need to provide a hidden new_thought template, new thoughts from other users will also be shown in the refresh, and it should allow for thought menus in threaded view; which isn't implemented yet, but it'll come soon... The only drawback, of course, is the extra bandwidth use, but it's not like posting/editing thoughts is going to kill your server anyway... Or is it? Also of note, I moved the URL-breaking JavaScript code to its own function (breakLinks), so now you can call it from within your plugins if you ever do the same kind of manipulation. This adds 12 gzipped bytes, but since the thought rewrite shaved off exactly 58 bytes of JavaScript, this means we still save 46 bytes. Oh, and if you like breaking rules, check out the new code in Ajax.php, it's pretty... interesting. (Ajax.php, Thoughts.php, Thoughts.template.php, Welcome.template.php (it's only for the principle -- it needs a complete rewrite), index.member.css, and sections.css)
! Clicking the BCC link in PM pages would send you to the top of the page... (pm.js)
! Fixed a JS error that would show up when loading any SSI page, due to the notification check not finding the we_notifs variable declared anywhere. I'm a bit upset that it adds a couple of bytes to the filesize, but... I know, I know, I should find some help. (script.js)
! Fixed status icons being too tall in IE6. (sections.css)
! Fixed thought mini-menus overlapping one another in IE 6/7. This is due to an IE bug that I couldn't find any information about. I've documented everything over at wedge.org, but in the end I decided to 'simply' show these menus to the right of the button, rather than below, because we don't have menu arrows in oldIE anyway... Note that this is only a partial commit, and it might not work until I'm finished with the rest. (sections.css)
(8 files, 8kb) -- BTW Pete, since you were wondering: re-indenting an entire block is seen as a full rewrite by SVN, hence your huge commit ;))
* Rewrote large parts of the thought system to improve its flexibility. Basically, every Ajax action will now refresh the entire thought list, which has a few advantages: no need to provide a hidden new_thought template, new thoughts from other users will also be shown in the refresh, and it should allow for thought menus in threaded view; which isn't implemented yet, but it'll come soon... The only drawback, of course, is the extra bandwidth use, but it's not like posting/editing thoughts is going to kill your server anyway... Or is it? Also of note, I moved the URL-breaking JavaScript code to its own function (breakLinks), so now you can call it from within your plugins if you ever do the same kind of manipulation. This adds 12 gzipped bytes, but since the thought rewrite shaved off exactly 58 bytes of JavaScript, this means we still save 46 bytes. Oh, and if you like breaking rules, check out the new code in Ajax.php, it's pretty... interesting. (Ajax.php, Thoughts.php, Thoughts.template.php, Welcome.template.php (it's only for the principle -- it needs a complete rewrite), index.member.css, and sections.css)
! Clicking the BCC link in PM pages would send you to the top of the page... (pm.js)
! Fixed a JS error that would show up when loading any SSI page, due to the notification check not finding the we_notifs variable declared anywhere. I'm a bit upset that it adds a couple of bytes to the filesize, but... I know, I know, I should find some help. (script.js)
! Fixed status icons being too tall in IE6. (sections.css)
! Fixed thought mini-menus overlapping one another in IE 6/7. This is due to an IE bug that I couldn't find any information about. I've documented everything over at wedge.org, but in the end I decided to 'simply' show these menus to the right of the button, rather than below, because we don't have menu arrows in oldIE anyway... Note that this is only a partial commit, and it might not work until I'm finished with the rest. (sections.css)
3175
Archived fixes / Re: IE 6/7 + mini-menus = headache
« on April 19th, 2013, 07:52 AM »
If nobody chips in, then no one has the right to complain about my decisions to come. All right...?
3176
Features / Re: New revs
« on April 18th, 2013, 06:20 PM »
rev 2061 -- plenty of little bug fixes... As in r2060, I'm just cleaning up my stuff to make way for my upcoming CSS rewrites.
(7 files, 5kb)
! Missing global... Not that it really matters, as I'm not going to keep this image file around in the thought XML forever, eh... (Ajax.php)
! A recent Wess update slightly, but completely, broke support for multiple attribute selectors and the likes... Oops. (Class-CSS.php)
! The media admin page would give PHP strict warnings about a misused object. Used the opportunity to give more freedom to the admin page to resize its option descriptions. (ManageMedia.php, Media.template.php)
! Plugins that modified $txt strings would sometimes end up being ignored. Meh, it looks like I never actually committed the related fix I discussed in late January, and I even lost it at some point... (Subs.php)
! Validation error. Name attributes in anchors are deprecated... (MessageIndex.template.php)
* As discussed before, any class used in conjunction with .windowbg/.windowbg2 in the HTML itself, should use the 'final' keyword when its CSS uses these, as in '.windowbg.class-name'. This is because otherwise, all other classes that extends .windowbg will be added to the list... This saves over 50 gzipped bytes. Just with the extra keyword. (index.member.css)
(7 files, 5kb)
! Missing global... Not that it really matters, as I'm not going to keep this image file around in the thought XML forever, eh... (Ajax.php)
! A recent Wess update slightly, but completely, broke support for multiple attribute selectors and the likes... Oops. (Class-CSS.php)
! The media admin page would give PHP strict warnings about a misused object. Used the opportunity to give more freedom to the admin page to resize its option descriptions. (ManageMedia.php, Media.template.php)
! Plugins that modified $txt strings would sometimes end up being ignored. Meh, it looks like I never actually committed the related fix I discussed in late January, and I even lost it at some point... (Subs.php)
! Validation error. Name attributes in anchors are deprecated... (MessageIndex.template.php)
* As discussed before, any class used in conjunction with .windowbg/.windowbg2 in the HTML itself, should use the 'final' keyword when its CSS uses these, as in '.windowbg.class-name'. This is because otherwise, all other classes that extends .windowbg will be added to the list... This saves over 50 gzipped bytes. Just with the extra keyword. (index.member.css)
3177
Archived fixes / Re: IE 6/7 + mini-menus = headache
« on April 18th, 2013, 05:33 PM »
So... In order to fix IE6/7's crap, I can either add some custom CSS to make them, if not behave, at least remain usable... This is the solution I'm using currently; but alternatively, I could also add this JavaScript snippet I wrote...
Code: [Select]
Basically, it'll attribute a decreasing z-index, in DOM traversal order, to all .mimenu parents, i.e. the things that should have a 'position: relative' value.
I can confirm that it works... It solves the z-index issue in the thought list.
This also has the added benefit of fixing mini-menus without external help if plugins want to use them.
Still, I don't think it's worth adding 90 bytes of code just for oldIE, although it compresses to exactly 26 bytes. It's still 26 useless bytes for all other browsers... Well, it might be an opportunity to start caching JS like I'm doing with CSS, i.e. with the browser name in the filename, which would allow code to do @if ie[-8] instead of if (is_ie8down) for instance, and potentially remove all browser hacks from the JS code when your browser doesn't need them.
But Wedge doesn't have a lot of these hacks in JS, I removed a lot of them over time... So we wouldn't save a lot, while increasing the number of cached files exponentially, just as in the CSS cache folder. (Well, not that much actually... CSS cache has many more files to begin with, with multiple skins and all that...)
So, err... Worth it or not..?
var num = 100;
$('.mimenu').each(function () {
$(this).parent().css('z-index', num--);
});Basically, it'll attribute a decreasing z-index, in DOM traversal order, to all .mimenu parents, i.e. the things that should have a 'position: relative' value.
I can confirm that it works... It solves the z-index issue in the thought list.
This also has the added benefit of fixing mini-menus without external help if plugins want to use them.
Still, I don't think it's worth adding 90 bytes of code just for oldIE, although it compresses to exactly 26 bytes. It's still 26 useless bytes for all other browsers... Well, it might be an opportunity to start caching JS like I'm doing with CSS, i.e. with the browser name in the filename, which would allow code to do @if ie[-8] instead of if (is_ie8down) for instance, and potentially remove all browser hacks from the JS code when your browser doesn't need them.
But Wedge doesn't have a lot of these hacks in JS, I removed a lot of them over time... So we wouldn't save a lot, while increasing the number of cached files exponentially, just as in the CSS cache folder. (Well, not that much actually... CSS cache has many more files to begin with, with multiple skins and all that...)
So, err... Worth it or not..?
3178
Archived fixes / Re: IE 6/7 + mini-menus = headache
« on April 18th, 2013, 09:58 AM »
Done some more testing...
Really, the 'only' way to realistically fix the problem, is to remove all 'position: relative' declarations, and instead just use 'position: absolute' on children, and manipulate position with regular CSS rather than with explicit left/top declarations.
It was already done this way in the main menu until I rewrote it to use position:relative for bytesize. I guess I'd already had the same problem in the past, and 'fixed' it with a simple 'clear: left'... Dunno if it'll work for mini-menus, too...
Here's what I'll do. I'm going to try and see if I can do it for mini-menus; if it works, then I'll just maintain two separate codebases -- one for IE6/7, one for other browsers. Under @if blocks, naturally. That way, regular browsers get the bytesize crunching, and IE gets it to work.. (Barely. As usual with it...)
I'm just posting to say, "Hey; I'm still on this. I'm not slacking. God please have mercy on me."
PS: last night, I discovered I was having the problem with the search popup as well -- it was being overlapped by the main menu... Sigh. AND EVEN IN NON-IE BROWSERS. YAY. The main menu does NOT have position: relative currently. I fixed it 'by magic' -- setting the popup's parent to have z-index: 1 (0 doesn't work).
Really, the 'only' way to realistically fix the problem, is to remove all 'position: relative' declarations, and instead just use 'position: absolute' on children, and manipulate position with regular CSS rather than with explicit left/top declarations.
It was already done this way in the main menu until I rewrote it to use position:relative for bytesize. I guess I'd already had the same problem in the past, and 'fixed' it with a simple 'clear: left'... Dunno if it'll work for mini-menus, too...
Here's what I'll do. I'm going to try and see if I can do it for mini-menus; if it works, then I'll just maintain two separate codebases -- one for IE6/7, one for other browsers. Under @if blocks, naturally. That way, regular browsers get the bytesize crunching, and IE gets it to work.. (Barely. As usual with it...)
I'm just posting to say, "Hey; I'm still on this. I'm not slacking. God please have mercy on me."
PS: last night, I discovered I was having the problem with the search popup as well -- it was being overlapped by the main menu... Sigh. AND EVEN IN NON-IE BROWSERS. YAY. The main menu does NOT have position: relative currently. I fixed it 'by magic' -- setting the popup's parent to have z-index: 1 (0 doesn't work).
3179
Archived fixes / Re: IE 6/7 + mini-menus = headache
« on April 17th, 2013, 07:26 PM »
Okay... Given the lack of feedback... (I didn't expect anyone to be able to help... But at least some compassion please... :lol:)
I've decided that, while it'd be stupid to drop support for IE6/7 "just for that", I'll reconsider in a few months time, maybe in early 2014, when IE6 shares will be nothing to worry about, and IE7 shares should be much lower if automatic updates 'work'.
In the meantime, I've enabled a silly hack for thoughts... Instead of showing the menu below the action button, it's now shown on the right. Yeah, I told you, it's silly... But it works very, very well.
The only visible issue will be with the search popup, because it overlaps some <we:title> elements in the sidebar, which have position: relative set on them. (I don't remember exactly why, though... :^^;:) Perhaps I could just add a .sidebar .title { position: static } as a hack for IE6/7...
I've decided that, while it'd be stupid to drop support for IE6/7 "just for that", I'll reconsider in a few months time, maybe in early 2014, when IE6 shares will be nothing to worry about, and IE7 shares should be much lower if automatic updates 'work'.
In the meantime, I've enabled a silly hack for thoughts... Instead of showing the menu below the action button, it's now shown on the right. Yeah, I told you, it's silly... But it works very, very well.
The only visible issue will be with the search popup, because it overlaps some <we:title> elements in the sidebar, which have position: relative set on them. (I don't remember exactly why, though... :^^;:) Perhaps I could just add a .sidebar .title { position: static } as a hack for IE6/7...
3180
The Pub / Re: More RSS feeds
« on April 17th, 2013, 07:00 PM »
I think we discussed that in the past...
I don't remember the outcome of our conversation, though. Nor why we didn't implement anything in that respect...
I don't remember the outcome of our conversation, though. Nor why we didn't implement anything in that respect...