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
616
Archived fixes / Re: Unable to click/hover on menus
« on July 26th, 2014, 06:15 PM »
Nothing here for me...
617
Features / Re: Language revs
« on July 24th, 2014, 09:01 PM »
[Commit revision d4c5f21]
Author: Pandos (Signed-off)
Date: Tue, 22 Jul 2014 09:39:41 +0200
Stats: 1 file changed; +1 (insertion), -1 (deletion)
[Commit revision d13c9a7]
Author: Nao
Date: Thu, 24 Jul 2014 21:01:48 +0200
Stats: 1 file changed; +1 (insertion), -1 (deletion)
Date: Tue, 22 Jul 2014 09:39:41 +0200
Stats: 1 file changed; +1 (insertion), -1 (deletion)
- A little Typo in install.german.php.
[Commit revision d13c9a7]
Date: Thu, 24 Jul 2014 21:01:48 +0200
Stats: 1 file changed; +1 (insertion), -1 (deletion)
- Merge pull request #23 from Pandos/de
- A little Typo in install.german.php.
618
Features / Re: New revs
« on July 24th, 2014, 08:56 PM »
[Commit revision 00f721c]
Author: Nao
Date: Thu, 24 Jul 2014 20:53:29 +0200
Stats: 1 file changed; +1 (insertion), -1 (deletion)
[Commit revision 9fe368e]
Author: Nao
Date: Thu, 24 Jul 2014 20:55:51 +0200
Stats: 1 file changed; +10 (insertions), -4 (deletions)
Date: Thu, 24 Jul 2014 20:53:29 +0200
Stats: 1 file changed; +1 (insertion), -1 (deletion)
- Casenazi. (Subs-Post.php)
[Commit revision 9fe368e]
Date: Thu, 24 Jul 2014 20:55:51 +0200
Stats: 1 file changed; +10 (insertions), -4 (deletions)
- Sbox now allows select boxes to be opened programmatically, rather than through a click. This should help you hide the display area entirely and just show the drop down list. You'll see why it's interesting later. (sbox.js)
- Casenazi. (sbox.js)
619
Features / Re: New revs
« on July 24th, 2014, 08:52 PM »
[Commit revision 96fe4a8]
Author: Nao
Date: Thu, 24 Jul 2014 20:51:58 +0200
Stats: 1 file changed; +8 (insertions), -3 (deletions)
Date: Thu, 24 Jul 2014 20:51:58 +0200
Stats: 1 file changed; +8 (insertions), -3 (deletions)
- Caching IP to host data for only 10 minutes isn't going to cut it. If your server is very slow, users will always get a long slowdown every 10 minutes, so I'm upping this to 24 hours, and hopefully it won't clutter the cache folder with IP data. Seriously, I had to go through a xdebug session just to get to the bottom of this and understand why my local server was so slow when accessed remotely, and so fast from my localhost (answer: 127.0.0.1 is easy to translate.) (Subs.php)
- If the IP to host process is really slow and the admin never went to the admin page for this (which is unlikely, but on a first launch maybe...), disable hostname lookups by default. Once the setting is changed manually, it'll never be overridden again. BTW, totally untested... Don't complain too much, I'm doing this between two bottles for little Charlie. (Subs.php)
620
Development blog / Re: Alphababy!
« on July 12th, 2014, 08:34 PM »
Our little Charles M. Deberdt was born on July 10 :)
And as expected, I'm putting Wedge aside until I have more time for it. I'm still working on privacy and contact lists (and oddly, redoing some of the sendmail code), but you shouldn't expect any commits for another few days, because I'm... Committed to someone else! ;)
And as expected, I'm putting Wedge aside until I have more time for it. I'm still working on privacy and contact lists (and oddly, redoing some of the sendmail code), but you shouldn't expect any commits for another few days, because I'm... Committed to someone else! ;)
621
Features / Re: New revs
« on July 8th, 2014, 02:17 PM »
[Commit revision 2a97066]
Author: Nao
Date: Tue, 08 Jul 2014 14:17:33 +0200
Stats: 2 files changed; +5 (insertions), -1 (deletion)
Date: Tue, 08 Jul 2014 14:17:33 +0200
Stats: 2 files changed; +5 (insertions), -1 (deletion)
- Don't show the postlist_before block on blog posts with no comment, avoiding the awkward double line of page indexes. (Display.php, Display.template.php)
622
Features / Re: New revs
« on July 8th, 2014, 12:15 AM »
[Commit revision 41149a9]
Author: Nao
Date: Tue, 08 Jul 2014 00:12:29 +0200
Stats: 1 file changed; +4 (insertions), -4 (deletions)
[Commit revision 8e03f6d]
Author: Nao
Date: Tue, 08 Jul 2014 00:15:34 +0200
Stats: 1 file changed; +1 (insertion), -1 (deletion)
Date: Tue, 08 Jul 2014 00:12:29 +0200
Stats: 1 file changed; +4 (insertions), -4 (deletions)
- While we're on the 'logic' side... Saving a single variable test, because I said so. (Subs-Post.php)
[Commit revision 8e03f6d]
Date: Tue, 08 Jul 2014 00:15:34 +0200
Stats: 1 file changed; +1 (insertion), -1 (deletion)
- Time for bed uh..? (Subs-Auth.php)
623
Features / Re: New revs
« on July 8th, 2014, 12:08 AM »
[Commit revision 54bcada]
Author: Nao
Date: Tue, 08 Jul 2014 00:08:47 +0200
Stats: 1 file changed; +30 (insertions), -3 (deletions)
Date: Tue, 08 Jul 2014 00:08:47 +0200
Stats: 1 file changed; +30 (insertions), -3 (deletions)
- So, I just found this situation where a private topic can be visible to guests. Yay, I win. The board list will show a link to it (although not actually browsable) if it's the last updated topic in the board. I've decided to 'fix' this by forcing a query_see_topic, and if the topic is private, do an extra query (which shouldn't be TOO slow, but I'm no specialist) that will return the proper last viewable post for you. This will only happen if the last post is private, so it shouldn't be too much of an issue. (Subs-BoardIndex.php)
- Feedback is warmly welcomed!!
624
Features / Re: New revs
« on July 7th, 2014, 11:58 PM »
[Commit revision e2ee0d9]
Author: Nao
Date: Mon, 07 Jul 2014 23:58:26 +0200
Stats: 2 files changed; +17 (insertions), -14 (deletions)
Date: Mon, 07 Jul 2014 23:58:26 +0200
Stats: 2 files changed; +17 (insertions), -14 (deletions)
- Privacy icons are now called through a generic function, which lets us add a hover title indicating what type of privacy setting is being used. (Security.php)
- Simplified thought template, and used the above function. Actually, it's the only place for now where I'm showing privacy icons at all... (Thoughts.template.php)
625
Features / Re: New revs
« on July 7th, 2014, 11:00 PM »
[Commit revision 5f4fe10]
Author: Nao
Date: Mon, 07 Jul 2014 23:00:43 +0200
Stats: 1 file changed; +11 (insertions), -26 (deletions)
Date: Mon, 07 Jul 2014 23:00:43 +0200
Stats: 1 file changed; +11 (insertions), -26 (deletions)
- Simplified the logic in rebuiltModCache(), along with a minor optimization suggested by John via Pandos. (Subs-Auth.php)
626
Features / Re: New revs
« on July 7th, 2014, 05:10 PM »
[Commit revision e5446bf]
Author: Nao
Date: Mon, 07 Jul 2014 17:10:09 +0200
Stats: 1 file changed; +1 (insertion), -1 (deletion)
Date: Mon, 07 Jul 2014 17:10:09 +0200
Stats: 1 file changed; +1 (insertion), -1 (deletion)
- wesql::fetch_rows was probably broken on newer MySQL servers. (Class-DB.php)
627
Features / Re: Language revs
« on July 6th, 2014, 11:23 PM »
[Commit revision 981660b]
Author: Pandos (Signed-off)
Date: Mon, 19 May 2014 15:34:25 +0200
Stats: 1 file changed; +2 (insertions), -2 (deletions)
[Commit revision ac3fd37]
Author: Nao
Date: Sun, 06 Jul 2014 23:23:43 +0200
Stats: 1 file changed; +2 (insertions), -2 (deletions)
Date: Mon, 19 May 2014 15:34:25 +0200
Stats: 1 file changed; +2 (insertions), -2 (deletions)
- $txt[media_posted_on] will use the EXIF Date of the picture instead the posted on date. So changing this string to the proper descritption.
- Also change the string $txt[media_upload_file_too_big] to a more accurate wording in German.
[Commit revision ac3fd37]
Date: Sun, 06 Jul 2014 23:23:43 +0200
Stats: 1 file changed; +2 (insertions), -2 (deletions)
- Merge pull request #18 from Pandos/de
- $txt[media_posted_on] will use the EXIF Date of the picture instead the ...
628
Features / Re: Language revs
« on July 6th, 2014, 11:22 PM »
[Commit revision f33767f]
Author: Pandos (Signed-off)
Date: Sun, 06 Jul 2014 19:02:32 +0200
Stats: 2 files changed; +18 (insertions), -8 (deletions)
[Commit revision ad9ea77]
Author: Nao
Date: Sun, 06 Jul 2014 23:21:59 +0200
Stats: 2 files changed; +18 (insertions), -8 (deletions)
Date: Sun, 06 Jul 2014 19:02:32 +0200
Stats: 2 files changed; +18 (insertions), -8 (deletions)
- German translation for the new elements of the contact list feature.
[Commit revision ad9ea77]
Date: Sun, 06 Jul 2014 23:21:59 +0200
Stats: 2 files changed; +18 (insertions), -8 (deletions)
- Merge pull request #22 from Pandos/de
- German translation for the new elements of the contact list feature.
629
Bug reports / [Topic privacy] Re: Messages are readable by guests
« on July 6th, 2014, 03:05 PM »
Okay, I think I've found the reason for the problem...
- SMF 2.0 has these bits: topic.approved, and message.approved. If topic is not approved, the first message isn't either, IIRC, so in Recent Messages, the query basically checks for whether the message being retrieved is approved. If yes, then it shows it.
- However, in Wedge, we add topic privacy to the mix. Wedge moved it to {query_see_topic}, and I replaced all of the topic approved tests with a {query_see_topic}. BUT, here's the thing, a topic can be approved and its messages are still undesirable to the end user. So, in addition to {query_see_topic} on topic approvals, I should be doing it selectively on message approvals, replacing them with something else that takes topic privacy and message approval into account.
Not easy... So, I guess the safest way would be for me to go through the Noisen patch, and take it upon myself to ensure everything is implemented. I don't like the idea, but... It's better than a useless topic privacy feature, right..? ;)
- SMF 2.0 has these bits: topic.approved, and message.approved. If topic is not approved, the first message isn't either, IIRC, so in Recent Messages, the query basically checks for whether the message being retrieved is approved. If yes, then it shows it.
- However, in Wedge, we add topic privacy to the mix. Wedge moved it to {query_see_topic}, and I replaced all of the topic approved tests with a {query_see_topic}. BUT, here's the thing, a topic can be approved and its messages are still undesirable to the end user. So, in addition to {query_see_topic} on topic approvals, I should be doing it selectively on message approvals, replacing them with something else that takes topic privacy and message approval into account.
Not easy... So, I guess the safest way would be for me to go through the Noisen patch, and take it upon myself to ensure everything is implemented. I don't like the idea, but... It's better than a useless topic privacy feature, right..? ;)
630
Bug reports / [Topic privacy] Re: Messages are readable by guests
« on July 6th, 2014, 01:45 PM »
There... Should work now.
I thought I'd moved all of the query_see_topic queries over from Noisen.com, but this clearly shows it wasn't the case.
Because privacy is crucial, it's important that any queries with {db_prefix}messages or {db_prefix}topics in them use {query_see_topic} at some point, UNLESS (1) privacy doesn't matter (no message title or body being shown), or (2) we already know we're within bounds (e.g. a query_see_topic query was launched earlier, and we're working on its results.)
That's still a lot of queries to go through (about 500). I have no idea how I managed to implement that in Noisen... Oh, wait. I didn't have a baby coming up, or a partner leaving me to fix his own stuff, or a public source to be scrutinized by everyone.
For the anecdote, Noisen.com had (and still has) an 'infamous' topic which I created with a very severe privacy ("just me"), and I challenged anyone to tell me the secret word that was in it... Nobody ever found it, meaning my code is just flawless, or they didn't care ah ah.
Please, Pandos and anyone else -- make sure to report anything fishy! Do it my way-- create a test topic, and try to find its content, anywhere!
I thought I'd moved all of the query_see_topic queries over from Noisen.com, but this clearly shows it wasn't the case.
Because privacy is crucial, it's important that any queries with {db_prefix}messages or {db_prefix}topics in them use {query_see_topic} at some point, UNLESS (1) privacy doesn't matter (no message title or body being shown), or (2) we already know we're within bounds (e.g. a query_see_topic query was launched earlier, and we're working on its results.)
That's still a lot of queries to go through (about 500). I have no idea how I managed to implement that in Noisen... Oh, wait. I didn't have a baby coming up, or a partner leaving me to fix his own stuff, or a public source to be scrutinized by everyone.
For the anecdote, Noisen.com had (and still has) an 'infamous' topic which I created with a very severe privacy ("just me"), and I challenged anyone to tell me the secret word that was in it... Nobody ever found it, meaning my code is just flawless, or they didn't care ah ah.
Please, Pandos and anyone else -- make sure to report anything fishy! Do it my way-- create a test topic, and try to find its content, anywhere!