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
7561
Features / Re: These two bytes may not matter to you...
« on October 4th, 2011, 09:39 PM »
It's not much but it adds up.
7562
Features / Re: These two bytes may not matter to you...
« on October 4th, 2011, 09:19 PM »
Download size and time to upload for users... Enough of a reason for me.
7563
Features / Re: The calendar
« on October 4th, 2011, 09:03 PM »
You seem to have an answer to everything when it comes to plugins. That's refreshing :)
7564
Features / Re: New revs - Public comments
« on October 4th, 2011, 07:29 PM »
In the meantime, could you look into these bugs? IRL time... >_<
I'm curious about the skeleton error... It shouldn't be happening. I'm sure it can be spotted just by looking at the source code.
Another error: go to the admin area, Maintenance, click on Repair. You're redirected to the main page without a confirmation or whatever... (The task still runs though, AFAIK. Although it didn't reassociate my restored posts with my newly re-created board #1... I guess it's the kind of error that doesn't happen to EVERYONE, meh...)
I'm curious about the skeleton error... It shouldn't be happening. I'm sure it can be spotted just by looking at the source code.
Another error: go to the admin area, Maintenance, click on Repair. You're redirected to the main page without a confirmation or whatever... (The task still runs though, AFAIK. Although it didn't reassociate my restored posts with my newly re-created board #1... I guess it's the kind of error that doesn't happen to EVERYONE, meh...)
7565
Features / Re: New revs
« on October 4th, 2011, 07:22 PM »
rev 1055 (janitor commit)
(10 files, 13kb)
+ Added "FileETag none" to the cache folder's htaccess, hopefully this should satisfy YSlow regarding cache optimization. (cache/.htaccess)
! An interesting SMF comment typo... Been in plain view in the single most important file for who knows how long. Finally gone... (index.php)
! Other, less amusing typos. (ManagePlugins.php)
* Added a short description for the dynamic plugin's functions. (Subs-Cache.php)
* Saving a couple of bytes off all HTML pages. Whatever... Also in the admin CSS. (index.template.php, admin.css)
! Spellcheck and Cancel buttons were broken in IE6 through IE8. (index.ie*.css)
- Removed another holiday. (other/install.sql)
(10 files, 13kb)
+ Added "FileETag none" to the cache folder's htaccess, hopefully this should satisfy YSlow regarding cache optimization. (cache/.htaccess)
! An interesting SMF comment typo... Been in plain view in the single most important file for who knows how long. Finally gone... (index.php)
! Other, less amusing typos. (ManagePlugins.php)
* Added a short description for the dynamic plugin's functions. (Subs-Cache.php)
* Saving a couple of bytes off all HTML pages. Whatever... Also in the admin CSS. (index.template.php, admin.css)
! Spellcheck and Cancel buttons were broken in IE6 through IE8. (index.ie*.css)
- Removed another holiday. (other/install.sql)
7566
Features / Re: New revs - Public comments
« on October 4th, 2011, 07:01 PM »
A few bugs to take care of in the recycle bin... (I'm still of the opinion that this thing should go anyway :P)
- If you're trying to restore posts, you get the "empty skeleton" error message.
- Even worse -- if you're trying to restore posts *when there are no other boards available* (or possibly even if there are other boards, just not the original post board), the messages just disappear!
Well, they're not deleted, but they're given their original board ID back, and since there's no board at that address, the posts just become invisible. Nasty bug!
(This happened after I clicked 'Delete board' to see if there was some kind of confirmation request... Well, there isn't. Something else to fix!)
- If you're trying to restore posts, you get the "empty skeleton" error message.
- Even worse -- if you're trying to restore posts *when there are no other boards available* (or possibly even if there are other boards, just not the original post board), the messages just disappear!
Well, they're not deleted, but they're given their original board ID back, and since there's no board at that address, the posts just become invisible. Nasty bug!
(This happened after I clicked 'Delete board' to see if there was some kind of confirmation request... Well, there isn't. Something else to fix!)
7567
Features / Re: The calendar
« on October 4th, 2011, 06:15 PM »
If it's still core it doesn't guarantee it'll work better. We may simply not test it...
7568
Features / Re: The calendar
« on October 4th, 2011, 05:01 PM »
I could care less about whether the calendar is core or not. However, if we make it a plugin, it could be interesting to implement 'dependencies' in the plugin system (if not already done...), where one plugin would only be enablable (technobabble?) if another one (specified by ID) is there.
(Oh, and official plugins should have the 'Wedge' ID, BTW. Calendar would be <Wedge:Calendar> for instance. Or <wedge:calendar>. (I'm all for lowercase everywhere. (And parenthesis.)))
(Oh, and official plugins should have the 'Wedge' ID, BTW. Calendar would be <Wedge:Calendar> for instance. Or <wedge:calendar>. (I'm all for lowercase everywhere. (And parenthesis.)))
7569
Features / Re: These two bytes may not matter to you...
« on October 4th, 2011, 04:35 PM »
Well... Readability is important -- when you're planning to maintain the thing!
But do you think you're going to?
I was looking for similar software, thanks for pointing to it. I manually passed all of the getid3 files to it, stripping comments and whitespace (but not doc comments because getid3 uses this in its parser... Geeky for sure, but a horrible way of doing things!), and keeping just the header comment.
Normal version: 702kb, zips to 133kb
Minified version: 522kb, zips to 98kb
Not bad...! Although I'll have to test it, I guess... It's an interesting alternative, and it only took 15 minutes or so to convert all of the files. Something I *can* do on each major release for sure...
Okay, speaking about minification. I've been thinking about many things...
- doing on-the-fly minification (i.e. not cached...) on inline JS and CSS. Do you think it's realistic? I'm not sure myself, but I could cook up a simplified minification function, although I wouldn't know how to deal with strings. Hmm. Still, just as an example, if I manually minify the noi_resize() code, I save something like 60 to 80 bytes off the page, and a reasonable ~20 bytes when gzipped. Considered it's to be found on every single page...
- media cache: I'm always tempted to add a htaccess for the media folder, just so I don't get the pagespeed warning when it can't find a far-future expiration date. Problem is -- if you replace the files with a newer version, if the files have the same name, then the generated name has the same name as well. And that's only for thumbnails... Previews and full pics are accessed through PHP, so I can't "regenerate" a new filename for them, it won't help at all.
Need I worry about caching media items at all...?
- considering using YepNope to load jQuery and subsequent code. YepNope is 1.6kb minified and gzipped, so it's not exactly super-light, but at least it would trick pagespeed into thinking no other JS is executed at page load time, so I'd be likelier to get it to a perfect score... Main problem is, I doubt I'll be saving any time here. The only 'big' script we have to load is jQuery, the rest is negligible (except maybe for script+theme). At best, jQuery will load in parallel while YN is loading other JS files, and thus will be able to execute everything at the same time instead of waiting to load script+theme and other scripts after jQ is loaded. Still, if jQ is integrated into the main local file, it's even more pointless. At worst, YN wastes time executing itself when both jQ and local scripts are already cached... :-/
- Considering using "FileETag none" in all htaccess files. I'm not a specialist though... But as soon as we have an expiration date, ETags aren't useful at all. I'm not sure if it should be done for all files.
- IP packets carry the cookie, as everyone knows. My question would be, does it carry it only in the first packet of the page, or on every single freakin' packet? In which case it'd be in our interest to make cookie size as small as possible...
- I noticed that by default, avatars are loaded into the attachment folder. I *know* AeMe will change the entire system, but since I still don't know when I'll deal with this, I'd like us to consider creating a 'custom' folder in /avatars/ and upload all avatars there by default -- and obviously, set Wedge by default to show clear URLs for these avatar images. We save *by default* as many HTTP requests (to PHP FFS!) as there are avatars on the page.
But do you think you're going to?
I was looking for similar software, thanks for pointing to it. I manually passed all of the getid3 files to it, stripping comments and whitespace (but not doc comments because getid3 uses this in its parser... Geeky for sure, but a horrible way of doing things!), and keeping just the header comment.
Normal version: 702kb, zips to 133kb
Minified version: 522kb, zips to 98kb
Not bad...! Although I'll have to test it, I guess... It's an interesting alternative, and it only took 15 minutes or so to convert all of the files. Something I *can* do on each major release for sure...
Okay, speaking about minification. I've been thinking about many things...
- doing on-the-fly minification (i.e. not cached...) on inline JS and CSS. Do you think it's realistic? I'm not sure myself, but I could cook up a simplified minification function, although I wouldn't know how to deal with strings. Hmm. Still, just as an example, if I manually minify the noi_resize() code, I save something like 60 to 80 bytes off the page, and a reasonable ~20 bytes when gzipped. Considered it's to be found on every single page...
- media cache: I'm always tempted to add a htaccess for the media folder, just so I don't get the pagespeed warning when it can't find a far-future expiration date. Problem is -- if you replace the files with a newer version, if the files have the same name, then the generated name has the same name as well. And that's only for thumbnails... Previews and full pics are accessed through PHP, so I can't "regenerate" a new filename for them, it won't help at all.
Need I worry about caching media items at all...?
- considering using YepNope to load jQuery and subsequent code. YepNope is 1.6kb minified and gzipped, so it's not exactly super-light, but at least it would trick pagespeed into thinking no other JS is executed at page load time, so I'd be likelier to get it to a perfect score... Main problem is, I doubt I'll be saving any time here. The only 'big' script we have to load is jQuery, the rest is negligible (except maybe for script+theme). At best, jQuery will load in parallel while YN is loading other JS files, and thus will be able to execute everything at the same time instead of waiting to load script+theme and other scripts after jQ is loaded. Still, if jQ is integrated into the main local file, it's even more pointless. At worst, YN wastes time executing itself when both jQ and local scripts are already cached... :-/
- Considering using "FileETag none" in all htaccess files. I'm not a specialist though... But as soon as we have an expiration date, ETags aren't useful at all. I'm not sure if it should be done for all files.
- IP packets carry the cookie, as everyone knows. My question would be, does it carry it only in the first packet of the page, or on every single freakin' packet? In which case it'd be in our interest to make cookie size as small as possible...
- I noticed that by default, avatars are loaded into the attachment folder. I *know* AeMe will change the entire system, but since I still don't know when I'll deal with this, I'd like us to consider creating a 'custom' folder in /avatars/ and upload all avatars there by default -- and obviously, set Wedge by default to show clear URLs for these avatar images. We save *by default* as many HTTP requests (to PHP FFS!) as there are avatars on the page.
7570
Plugins / Re: Plugin development
« on October 4th, 2011, 10:30 AM »
With a limit to 5 users, though! But it's nice to know.
7571
Features / Re: New revs - Public comments
« on October 4th, 2011, 10:28 AM »
Have no idea what I'll do next about this... I guess I'll just refuse to jog at all until I find a solution for my knees. As I said, I could only run for 5 minutes before I was pretty much unable to *walk* at all. Then I simply looked ridiculous for the remaining 55 minutes :P
7572
The Pub / [Archive] Re: Logo Madness
« on October 4th, 2011, 07:18 AM »Hmmm, I've wondered today about making badges based on my avatar-interpretation-of-logo, where I'd create a grey-scale base that would look like a base that supported the logo (as though the logo were placed into a slight recess in the surface).
Then, I'd write a PHP script to accept a colour, it would tint the background, insert the text I give it, then overlay the logo into place to make new badges.
It seems like a lot of effort but that's the sort of crazy thing only I would do, because that way I'd be able to spin new badges out for whatever teams/colours we want :)
* Arantor has funky crazy ideas late at night.
While we're on this topic, I'm attaching a few stupid logos I 'tried' a few days ago. They don't 'perfectly' click with me, but I still think they're worth reposting. I liked reusing Segoe UI Light for these tests, too.
7573
Plugins / Re: Personal plugin showcase (yes, I'm an attention grabbing git)
« on October 3rd, 2011, 10:52 PM »
LOL. Technically i had a quick skin selector in my to-do list. I guess I can drop it now ;)
Is it the same HTML as the dropdown I made on the admin area? If yes we might wanna consider putting it into a sub function...
Is it the same HTML as the dropdown I made on the admin area? If yes we might wanna consider putting it into a sub function...
7574
Features / Re: New revs
« on October 3rd, 2011, 09:48 PM »
rev 1054
(2 files, 10kb, 1 day of work >_<)
* Renamed *skeleton* functions to use the skeleton_ prefix. (Subs-Template.php, Load.php)
* loadBlock() and loadLayer() should now return the name of the layer or block they modified, or false if failed. (Subs-Template.php)
! Fixed loadBlock() not working when providing a block name and an 'after' or 'before' position, due to a recent addition that checked for a valid layer first. (Subs-Template.php)
! The layer removal code didn't work, due to how references work. Fixed some unsets and added a skeleton_remove_item() helper function to the ones you should be using (removeBlock and removeLayer). (Subs-Template.php)
! More reference errors in skeleton_insert_layer(). (Subs-Template.php)
(2 files, 10kb, 1 day of work >_<)
* Renamed *skeleton* functions to use the skeleton_ prefix. (Subs-Template.php, Load.php)
* loadBlock() and loadLayer() should now return the name of the layer or block they modified, or false if failed. (Subs-Template.php)
! Fixed loadBlock() not working when providing a block name and an 'after' or 'before' position, due to a recent addition that checked for a valid layer first. (Subs-Template.php)
! The layer removal code didn't work, due to how references work. Fixed some unsets and added a skeleton_remove_item() helper function to the ones you should be using (removeBlock and removeLayer). (Subs-Template.php)
! More reference errors in skeleton_insert_layer(). (Subs-Template.php)
7575
Off-topic / Re: Doctor Who
« on October 3rd, 2011, 07:22 PM »
Apparently a thriller show with John Simm and Phil Glenister. Life on Mars is back :)