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
3361
Archived fixes / Re: Wuthering theme misses Facebook icon
« on March 26th, 2013, 12:43 AM »
I'm sure he can't, but I also haven't committed anything regarding new icons...
Even though I spent something like an afternoon optimizing all of these annoying images. (For instance, the Twitter icon is surprisingly heavy. Just re-saving it under the same format saves like 500 bytes..!)
Even though I spent something like an afternoon optimizing all of these annoying images. (For instance, the Twitter icon is surprisingly heavy. Just re-saving it under the same format saves like 500 bytes..!)
3362
Features / Re: New revs
« on March 26th, 2013, 12:19 AM »
rev 2021
(3 files, 4kb)
! Last rev's fix was overwriting the $data parameter in the issue() method. (Class-Notification.php)
! Fixed another use of ;id= which, as I said, may sometimes be forbidden by mod_security. Or is that a thing of the past..? (Notifications.template.php)
! Fixed $member[$row['id_member']], should have been $members[$row['id_member']] instead... Notice the extra 's'. This probably prevented scheduled tasks from working... (Notifications.php)
! Notification e-mail template was calling weNotif::getNotifie instead of weNotif::getNotifiers... (Notifications.template.php)
* Small clean-up... No need to call loadSource() twice in a row, just provide an array of source filenames. Removed some extra $scripturl's. Avoid self-referencing a static object by using its full name, use 'self' instead. Renamed some variables to avoid further confusion (and potential reference overrun... If you know what I mean. Never re-use a variable that was set as a reference earlier. I learned it the hard way long ago.) (Notifications.php)
@ Also, err... Should this notification e-mail template REALLY spit out HTML code...?! (Notifications.template.php)
(3 files, 4kb)
! Last rev's fix was overwriting the $data parameter in the issue() method. (Class-Notification.php)
! Fixed another use of ;id= which, as I said, may sometimes be forbidden by mod_security. Or is that a thing of the past..? (Notifications.template.php)
! Fixed $member[$row['id_member']], should have been $members[$row['id_member']] instead... Notice the extra 's'. This probably prevented scheduled tasks from working... (Notifications.php)
! Notification e-mail template was calling weNotif::getNotifie instead of weNotif::getNotifiers... (Notifications.template.php)
* Small clean-up... No need to call loadSource() twice in a row, just provide an array of source filenames. Removed some extra $scripturl's. Avoid self-referencing a static object by using its full name, use 'self' instead. Renamed some variables to avoid further confusion (and potential reference overrun... If you know what I mean. Never re-use a variable that was set as a reference earlier. I learned it the hard way long ago.) (Notifications.php)
@ Also, err... Should this notification e-mail template REALLY spit out HTML code...?! (Notifications.template.php)
3363
Features / Re: X-Content-Security-Policy
« on March 25th, 2013, 11:30 PM »
Should be good now...
This was due, ahem, to a bug in Dragooon's fix of today... :lol:
He was using $data to store member data, when it was already used as a function parameter.
I renamed it to $member_data and all should be fine.
Also enabled (temporarily?) self-made mentions. @Nao!
:edit: Works!
This was due, ahem, to a bug in Dragooon's fix of today... :lol:
He was using $data to store member data, when it was already used as a function parameter.
I renamed it to $member_data and all should be fine.
Also enabled (temporarily?) self-made mentions. @Nao!
:edit: Works!
3364
Features / Re: X-Content-Security-Policy
« on March 25th, 2013, 08:18 PM »
I know, I'm getting tons of errors, not sure why... I've disabled these errors for now, but they probably break the mentions system entirely.
(I'm busy IRL, damn RL really!!! No time to fix any of these things for now... -_-)
IMPORTANT: doing a mention will break your post! It won't be sent. Be careful!! I'll try to fix it tonight. I don't know why the post above worked, though ;)
(I'm busy IRL, damn RL really!!! No time to fix any of these things for now... -_-)
IMPORTANT: doing a mention will break your post! It won't be sent. Be careful!! I'll try to fix it tonight. I don't know why the post above worked, though ;)
3365
Features / Re: New revs
« on March 25th, 2013, 08:12 PM »
rev 2020 -- and I'd like to point out that if I'd committed rev 2019, I'd have made a reference to both Akira and Blade Runner, but alas it was not to be... :P
(8 files, 4kb)
! Fixed Wess parsing of calc() to actually add prefixes if needed... Also made the search process looser, as we don't really need to force a particular string end. (Class-CSS.php)
! Fixed a remaining reference to a removed field. (Class-Notification.php)
* Spacinazi. (ManageBans.php, ManageLanguages.php, Notifications.php, ScheduledTasks.php, Security.php, ManageLanguages.template.php)
(8 files, 4kb)
! Fixed Wess parsing of calc() to actually add prefixes if needed... Also made the search process looser, as we don't really need to force a particular string end. (Class-CSS.php)
! Fixed a remaining reference to a removed field. (Class-Notification.php)
* Spacinazi. (ManageBans.php, ManageLanguages.php, Notifications.php, ScheduledTasks.php, Security.php, ManageLanguages.template.php)
3366
Features / Re: X-Content-Security-Policy
« on March 25th, 2013, 07:54 PM »
Hmm... How about we set the data field to be filled by default with an empty array, i.e. "a:0:{}"..?
It's only six bytes. I've seen worse... I wouldn't recommend it, but I wouldn't be upset by this either.
Or, alternatively, we could force loading data into one (or all) of the three member profiles, and unserialize it, and defaulting it to an empty array. Problem solved, and no need to run another query. But you have to use member contexts, of course.
Also, keep in mind that we::$user['data'] contains the data array for the current member, *and* it's always defaulted to an empty array() if empty.
Re: JavaScript in admin, go crazy if you must. As I said before, non-admin areas are the ones I'm being careful with. In admin areas, comfort comes over performance or bandwidth concerns. By FAR! ;)
PS: my @Nao above didn't work, I guess it's because of the bug... I've uploaded a fixed version. Please @ me in return, @Arantor/@Dragooon/@whoever.
It's only six bytes. I've seen worse... I wouldn't recommend it, but I wouldn't be upset by this either.
Or, alternatively, we could force loading data into one (or all) of the three member profiles, and unserialize it, and defaulting it to an empty array. Problem solved, and no need to run another query. But you have to use member contexts, of course.
Also, keep in mind that we::$user['data'] contains the data array for the current member, *and* it's always defaulted to an empty array() if empty.
Re: JavaScript in admin, go crazy if you must. As I said before, non-admin areas are the ones I'm being careful with. In admin areas, comfort comes over performance or bandwidth concerns. By FAR! ;)
PS: my @Nao above didn't work, I guess it's because of the bug... I've uploaded a fixed version. Please @ me in return, @Arantor/@Dragooon/@whoever.
3367
Features / Re: X-Content-Security-Policy
« on March 25th, 2013, 08:36 AM »
I don't think gzipping would be a game changer for headers, though ;)
I'm more interested in saving a kilobyte per page, than a few bytes, as opposed to what everyone may think. I just can't help myself :lol:
@Everyone> Please @ me! I can't bother to manually modify the database to add more notifications to myself :P :edit: Oh well, that should be okay.
I'm more interested in saving a kilobyte per page, than a few bytes, as opposed to what everyone may think. I just can't help myself :lol:
@Everyone> Please @ me! I can't bother to manually modify the database to add more notifications to myself :P :edit: Oh well, that should be okay.
3368
Features / Re: Additional formatting of user names
« on March 24th, 2013, 08:22 PM »
Hmmmm I dunno.
If you feel like doing it, do it. I don't like that the icons are so big though. It'll take adjusting.
100% agreement on group colors.
What would be the class name? I'm thinking mgroup-ID. With a numeric id.
Which reminds me I wanted to test waters: how about we use only dashes in selector names instead of underscores? I have a feeling it would compress better... and it looks better, too.
PS: bugger, I could have seen an easy movie reference for rev 2019 :P
If you feel like doing it, do it. I don't like that the icons are so big though. It'll take adjusting.
100% agreement on group colors.
What would be the class name? I'm thinking mgroup-ID. With a numeric id.
Which reminds me I wanted to test waters: how about we use only dashes in selector names instead of underscores? I have a feeling it would compress better... and it looks better, too.
Posted: March 24th, 2013, 08:20 PM
PS: bugger, I could have seen an easy movie reference for rev 2019 :P
3369
Features: Posts & Topics / Re: Automatic Quote splitter
« on March 24th, 2013, 05:36 PM »
Oh bugger, I forgot there was a dedicated topic for that... Well, I said stuff about quote splitting in the New Revs Public Comments topic ;)
As for Pete's last post here -- okay, I don't have the faintest idea what you're talking about, but I suspect it's not too important..?
As for Pete's last post here -- okay, I don't have the faintest idea what you're talking about, but I suspect it's not too important..?
3370
Features / Re: X-Content-Security-Policy
« on March 24th, 2013, 05:34 PM »
Yup, I'm not tempted by this either... I was already frightened when you added a new header :lol: (But I figured, I've saved enough bytes in every page to allow for some increased security...!)
Perhaps as a plugin, if doable.
Perhaps as a plugin, if doable.
3371
Features / Re: New revs - Public comments
« on March 24th, 2013, 05:32 PM »
Was just wondering... When you did your add_linktree conversions, did you check whether $context was being used elsewhere in the functions..? It's likely they are of course (we've been putting so many things in that one :P), but I'm asking so I can know whether I should bother checking myself, or not ;)Quote from Arantor on March 21st, 2013, 06:53 PM Yeah, that's true...
Considering I'm the only one who'd be annoyed by the change (i.e. having to move my FTP updates to one extra folder), it's probably best to just ignore me and move them to their own folders. :)Quote How pretty it is depends on what you're ready to give up on, eh eh.
Personally, I'd say that the less Display is crowded, the prettier it is overall.
As always, my main concern is with reactivity. But as long as the main editor is there, and Ajax is called only when going for 'full editor', I don't really see any issues with it.
i.e., loading smileys and buttons through Ajax seems like a given to me, but the wysiwyg and non-wysiwyg editors, along with their shortcuts etc, should always be loaded.
Also... I've been considering the recent discussion on shift+enter. As I said, I allowed touch devices to run the function automatically on Enter (since it doesn't have shift), and it's a life-changer when trying to quote stuff. (Not likely to push me into doing it more regularly, but at least it makes my life less miserable, should I ever want to do it on mobile!)
I was wondering whether we shouldn't be inverting the process on desktop..? Enter splits quotes by default, and Shift+Enter prevents it. It's very tempting. But I think I won't do it, because of one main issue: imagine you're typing something, then doing [b], then typing more, and pressing Enter... Oh! You didn't want to close the tag, did you..? I don't see how to avoid that. Maybe, hmm... Maybe keeping a copy of the original post and checking whether the line we just split was present in the original post. If it was, smart-split. Otherwise, ignore the split.
I can't think of a cleaner way, hm...Quote reqWin(this.href) is wrong code. Perhaps inherited from an old version of Wedge..? Can't remember how I used to do it. (I fixed it manually. I have tons of compatibility-related updates I'll commit at some point for plugins... 29 files, half of which are from WedgeDesk.)Quote Probably, yeah...
I'd still like for you to look into your code for WD and tell me if you can think of a better way of doing it. The onclick stuff, I mean.Quote :thanks:Quote I can understand you don't like the idea... And, I'll just say, I agree I'd rather not do it that way.
I'm thinking, *maybe* we could have a 'special setting', such as $txt['parent_language'] = 'english' or something, that says Wedge shouldn't worry about missing files, and instead look for the file inside the 'english' folder. What do you think..?
And yes. I know US English isn't UK English's parent, it's the other way around. Now get off my lawn :P
The only real issue with doing it vs not doing it is that we already have about 40 files per language, multiplied by the number of languages installed by Shitastico and friends when translations are available (remember, SMF has around 70 language packs) and that can start to cause other issues.
Considering I'm the only one who'd be annoyed by the change (i.e. having to move my FTP updates to one extra folder), it's probably best to just ignore me and move them to their own folders. :)
Yes, if you want to load the JS files and code dynamically, followed by all the requisite event handling. It's doable but it's really not pretty.
Personally, I'd say that the less Display is crowded, the prettier it is overall.
As always, my main concern is with reactivity. But as long as the main editor is there, and Ajax is called only when going for 'full editor', I don't really see any issues with it.
i.e., loading smileys and buttons through Ajax seems like a given to me, but the wysiwyg and non-wysiwyg editors, along with their shortcuts etc, should always be loaded.
Also... I've been considering the recent discussion on shift+enter. As I said, I allowed touch devices to run the function automatically on Enter (since it doesn't have shift), and it's a life-changer when trying to quote stuff. (Not likely to push me into doing it more regularly, but at least it makes my life less miserable, should I ever want to do it on mobile!)
I was wondering whether we shouldn't be inverting the process on desktop..? Enter splits quotes by default, and Shift+Enter prevents it. It's very tempting. But I think I won't do it, because of one main issue: imagine you're typing something, then doing [b], then typing more, and pressing Enter... Oh! You didn't want to close the tag, did you..? I don't see how to avoid that. Maybe, hmm... Maybe keeping a copy of the original post and checking whether the line we just split was present in the original post. If it was, smart-split. Otherwise, ignore the split.
I can't think of a cleaner way, hm...
WedgeDesk has a bunch of reqWin(this), reqWin(this.href) and a couple of weird reqWin instances.
I have a vague memory of those being related to showing attachments in a popup window, but Zoomedia would be infinitely better in this case.
I'd still like for you to look into your code for WD and tell me if you can think of a better way of doing it. The onclick stuff, I mean.
I'll try :)
The 'correct' behaviour is for loadLanguage to complain bitterly if a given language file doesn't exist - even if there will be a suitable fallback, it is still going to complain about the missing file. The only problem is that a small percentage of the language files for English UK will be identical to English US (e.g. so far the Home language file is in that category), so I need to include a placeholder for those so that I don't write exceptions directly into loadLanguage for a fringe language case. I don't like it either but it's the least worst alternative.
I'm thinking, *maybe* we could have a 'special setting', such as $txt['parent_language'] = 'english' or something, that says Wedge shouldn't worry about missing files, and instead look for the file inside the 'english' folder. What do you think..?
And yes. I know US English isn't UK English's parent, it's the other way around. Now get off my lawn :P
3372
Features / Re: New revs
« on March 24th, 2013, 04:02 PM »
rev 2018 -- woohoo, no more references! :P Back to quick descriptions of my changes...
(12 files, 44kb, mostly spaces-to-tabs in install.sql)
* Updated notification code to use the data field in the members table. Thanks Dragooon! (install.sql, Class-System.php, Notifications.php,
! Notifications markAsRead wasn't using the proper $id_member variable. Thanks myself! (Class-Notification.php)
* Harmonized notifications to use returnAjax(), for consistency. And because that's shorter. ;) (Notifications.php)
* All sorts of Naoisms -- spacinazi, indenazi, commenazi, bytenazi, you name it. Also fixed $context['skeleton'] to be initialized as an array, as pointed out by John. (Class-UnitTest_tidyhtml.php, install.sql, Class-FTP.php, Load.php, Display.template.php, ManageLanguages.template.php, Who.template.php, respond.js, suggest.js)
(12 files, 44kb, mostly spaces-to-tabs in install.sql)
* Updated notification code to use the data field in the members table. Thanks Dragooon! (install.sql, Class-System.php, Notifications.php,
! Notifications markAsRead wasn't using the proper $id_member variable. Thanks myself! (Class-Notification.php)
* Harmonized notifications to use returnAjax(), for consistency. And because that's shorter. ;) (Notifications.php)
* All sorts of Naoisms -- spacinazi, indenazi, commenazi, bytenazi, you name it. Also fixed $context['skeleton'] to be initialized as an array, as pointed out by John. (Class-UnitTest_tidyhtml.php, install.sql, Class-FTP.php, Load.php, Display.template.php, ManageLanguages.template.php, Who.template.php, respond.js, suggest.js)
3373
Archived fixes / Re: Initializing the Wedge templating magic
« on March 24th, 2013, 12:04 PM »
Yes, PHP is a loose type language. So it doesn't matter per se.
Still, you're right John, skeletons are now an array at this stage. The '' initialization code was added in rev 997, in the first implementation of the skeleton system, back when it was a string to be parsed. Now it's done before anything else, and $context['skeleton'] holds a list of parsed mini-skeletons.
As such, I modified the declaration to reflect this. Thanks!
Still, you're right John, skeletons are now an array at this stage. The '' initialization code was added in rev 997, in the first implementation of the skeleton system, back when it was a string to be parsed. Now it's done before anything else, and $context['skeleton'] holds a list of parsed mini-skeletons.
As such, I modified the declaration to reflect this. Thanks!
3374
Features / Re: Quick popup actions
« on March 23rd, 2013, 11:23 PM »
I'm all for going Ajax everywhere.
It's much easier to do than you're suggesting. Heck, we can even do it without any template changes! We just need to ensure the popup contents is restrained to a single <div id>. (Or <whatever id>.)
As a reminder for those who didn't realize: the search box's popup is called through Ajax.
Dunno about logins though... Will browsers correctly remember the passwords once entered? I think so, but it warrants caution.
Also, I think that notifications should be ajaxified, too. I'm hoping to be able to work on them tomorrow, or at worst, monday. Doing my best to save data... Hmm, probably should call the ajax link when hovering the notifications icon/text, rather than on click -- this will save like half a second, and might increase the chances of you seeing the popup upon click.
It's much easier to do than you're suggesting. Heck, we can even do it without any template changes! We just need to ensure the popup contents is restrained to a single <div id>. (Or <whatever id>.)
As a reminder for those who didn't realize: the search box's popup is called through Ajax.
Dunno about logins though... Will browsers correctly remember the passwords once entered? I think so, but it warrants caution.
Also, I think that notifications should be ajaxified, too. I'm hoping to be able to work on them tomorrow, or at worst, monday. Doing my best to save data... Hmm, probably should call the ajax link when hovering the notifications icon/text, rather than on click -- this will save like half a second, and might increase the chances of you seeing the popup upon click.
3375
Off-topic / Re: Lint checker
« on March 23rd, 2013, 02:45 PM »Yes, because you never make typos at 4am :P