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
2791
Features / Re: New revs
« on June 26th, 2013, 11:08 PM »
rev 2170 -- committing whatever is committable in my local install, which is easier said than done right now, uh...
(6 files, 7kb)

* Refactored debug junk area at the bottom of all pages, for several reasons: I wanted it to be shorter (it's now on average 3 lines only), so that infinite scrolling works better for admins, and to be readable when queries were expanded, which wasn't the case until now, uh. (Subs-Template.php, Stats.language.php)

! Fixed potential wrong redirection when expanding/collapsing queries. (ViewQuery.php)

! Fixed plugin CSS caching. Thanks John! (Subs-Cache.php)

* Added another bot to BadBehavior. Per Arantor's suggestion. (Security.php)
2792
Features / More sidebar complications...
« on June 26th, 2013, 10:04 PM »
So, I was requesting the other day, whether I could do some tests in here... I'm afraid it's not ready for testing yet, though.

Here's what I'm, hmm, trying to do...

See the Google+ or Facebook apps on mobile? They both have (and aren't the only ones) the 'navigation drawer' feature, which is something Google standardized for Android apps, where you swipe the screen to show a sidebar, and swipe it again to hide it.

Thing is, this is something that makes sense on mobile, and it reminded me that the original sidebar for Wedge was very similar to that... If you'll remember, if you didn't have enough room on the screen, it moved your sidebar to the extreme left, only showing a small portion of it, and when hovering that portion, it would bring it into view (position: absolute), with a nice animation and all.

Honestly, I can't for the life of me remember why I gave up on it, but here we are.

The main advantage of the current responsive sidebar, is that you can easily see its contents by just scrolling your mouse wheel, so it doesn't require much action on your part; that is its advantage, and really, its only one...

I've been doing LOTS of tests trying to get it right, started with a few lines of CSS, then added a few lines of JS, then expanded it even more, added more goodies, etc, the usual stuff, and now my current code is, like, 200 gzipped bytes added to the script file... Hmm. It's a lot to me, but I know I shouldn't be too worried about this kind of increase, especially since we still have 7.5KB for the entire script file, and it can easily go up to 10KB without me getting too worried, so... Whatever.

Here's what it's been doing until today... Hovering the left portion of the screen (about 30px wide) would bring the sidebar into view, position: fixed, with a scrollbar if too long, and a subtle but nice animation effect (basically, on mobile you get the bare animation, but on desktop you also get a parallax scroll effect on the whole page, which is nice really.)

There are two points where I'm currently stuck.

1/ The convenience. Of course, none of the sidebar information is vital, but still... it's a bit annoying, having to hover something so far on the left... Would like opinions on whether this is important, or not...

2/ The main menu. Up until today, I didn't touch it, but then I suddenly decided that it would be nice, at least on mobile, to automatically move the main menu to the sidebar. I got it working, but it's really hard.

(a) All items are developed, as intended, but I realized that as an admin, I have way too many entries, and it forces me to scroll wayyyy down just to be able to view the actual sidebar content...

(b) It's probably best to collapse them, then, but it suddenly implies an extra tap for mobile users. Swipe left to open sidebar, tap the menu item you want, then tap the option you want. The only advantage, I guess, is that since we're in the sidebar, I can easily control the menu item sizes, and thus you'll never have to zoom in to ensure you're tapping the right item, I guess... Opinions..?

(c) It also occurred to me that I could open *two* sidebars, eh... For instance, have the sidebar show up on the left, but at the same time, have the main menu unfold in a new sidebar on the right. This implies, however, that the sidebar can never fill more than half (or 60%) of the screen, otherwise you can only have one, or the other. I like the idea, though...

(d) Any .note classes will be hidden from view, obviously, if the menu is hidden by default... I mean, you won't get to see the number of admin errors, or PM number, or unseen media number. I could shove these up somewhere in the visible UI, but it doesn't make a lot of sense, or it might be more work than deserved, I don't know...

Okay, I'll end this long post here, given how my previous long post asking for feedback scared the hell out of everyone, I suppose it's for the best, eheh... :P

I'll post screenshots once I'm satisfied with the layout, but it certainly won't be today, and perhaps not tomorrow either, that's how much I'm NOT happy with it, but you know how much of a perfectionist I can be, so...

PS: in case you missed these, there are two uncommitted features that made their way into wedge.org last week: (1) infinite scroll now works on mobile, (2) previewing a notification will now mark it as read automatically, yay.
2793
Archived fixes / Re: Can't Post Thoughts on IE10 on Win8
« on June 24th, 2013, 11:46 PM »
A quick end-user solution is to set IE10 to IE9 compatibility mode.

Heck, I could even force IE9 compat mode on IE10, because, well... I don't really care if IE10 doesn't get all the bells and whistles Microsoft implemented, eh..?
2794
Plugins / [Plugin] Re: Notifications system (1.0)
« on June 24th, 2013, 11:29 PM »
Quote from Arantor on June 22nd, 2013, 05:33 PM
It is, under certain conditions. Firstly, the parent class must be loaded (or invokable through an autoloader) before the child class, and secondly whatever invokes the child class will need the full class name and that seems a bit long for the current system.
It's a bit fucked up... First of all, the notifiers aren't auto-loading, they're explicitly loaded and invoked in the initializer, and a hook is used to allow for other notifiers to plug into it. Seriously..? :-/
Wouldn't it be simpler to, I don't know... Force Notification::issue to require getNotifiers('Likes likes') or 'Likes:likes', or whatever structure that calls for the file to be loaded if not already done..?
Same for any situations where the 'likes' notifier is requested, anyway.
Quote
Autoloading is currently tricky because the class names don't really match the filenames but we could do something with it if we wanted.
Hmm, I think they do..? (Once you ucfirst them, of course...)
Quote
See, there's more potential for likes than we're currently using; there's no reason why we couldn't attach likes to media items, for example. I know media items have ranking, but I can see the use for likes on media items as an additional option.
It's actually quite tempting to ditch media ratings in favor of likes, but in that situation, things like fox.noisen.com lose some of their interest, at least for me -- since I like giving very precise ratings to these audio files. But really, in 95% of the cases, a like would even be preferable, because it's much easier to 'grasp' for users, who these days are so incredibly lazy... :P
Quote
Quote
(BTW, I'm surprised that id_object doesn't even get its own key..?!)
It'd be better served as a key on (notifier (6), id_object) really from what I remember.
Dunno if it matters that much -- if id_object is included as "AND id_object ...", MySQL will prioritize the first test (if it's keyed) before this one, right..?
Posted: June 24th, 2013, 11:14 PM
Quote from Dragooon on June 22nd, 2013, 06:13 PM
I want it to be impartial, plus you got a huge freaking gallery inside the forum so I'd doubt that it's just a forum :P.
Oh, you have no idea how many times I regretted including AeMe by default in Wedge... :^^;:
Not because it's not maintainable -- it is -- but for two reasons:
- too many 'loose licenses' in the code, meaning it's currently not compatible with Wedge's, and it will eventually force me to change most of the libraries to make it work, while I wouldn't have had to do it (so soon), had it been a plugin...
- my original plan was to ditch the attachment system, and replace it with media items uploaded to a default, fallback 'attachments' folder. Hmm... Well, I never got around to do that. Too much attachment code, too many things to change entirely. I could have done it at the beginning... But three years later, I'm just wary of huge code overhauls, and I don't see myself ever doing it, which is a pity...
Quote
And it was a good idea, and it should be extensible. Maybe a crazy plugin author gets a good idea and implements something else for their notifier, it doesn't hurt to keep that option open.
And a good idea from John, I think..!
Quote
Notifications.php is the "controller" here, it handles the notifications logic. If you have a better name go ahead, but I've thought a lot about my code and to me it makes perfect sense.
Why is Notifications a plural, and Class-Notification a singular, for instance..? :P
Why is weNotif called that way (Wedge standard is "wefirstletters", all lowercase[1]), and why is it an object to begin with?
Quote
Hm, maybe. Notification::issue kind of made sense to me since Notification class is sort of the "model" for doing the DB interactions with individual Notification rows. Although it can be made different, not sure.
issue_notification, really, and everything that's in the issue method...

Code: [Select]
Notification::issue($id_author, WeNotif::getNotifiers('likes'), $_REQUEST['msg'], array(
'topic' => $topic,
'subject' => $subject,
'member' => array(
'id' => we::$id,
'name' => we::$user['name'],
),
));

Possible change...

Code: [Select]
issue_notification($id_author, 'Likes likes post', $_REQUEST['msg'], array(
'topic' => $topic,
'subject' => $subject,
'member' => array(
'id' => we::$id,
'name' => we::$user['name'],
),
));

With the second member meaning: Likes.php notifier file, 'likes' notifier name, 'post' type.
This way, I can easily do a notification for a thought, with 'Likes likes thought' for instance... Likes.php could then get the 'thought' request, and if it doesn't support it, make a request to something, so that it autoloads it... From a plugin, for instance. But I'm not a specialist of object management, so... It's a bit over my skill level, I guess.
After that, in the database, either store as 'likes_thought', or as 'likes' with an extra field called 'type', as I suggested... Thus, id_object would immediately reflect the type of item it relates to; really, if you want to get all notifications related to post #123, you can't simply search for anything with id_object=123, since this would also return all notifications for thought #123 or media item #123, wouldn't it..?

Ah well...
I'm currently holding my changes, been doing so for a week now, I don't know where to go...

(Mind you, this isn't the only thing I've been stuck on; I'm very, extremely stuck on getting infinite scrolling to work 100%, and despite several internal rewrites, I still can't get it to behave better than it currently does.)

(I made it work on mobile devices, though... Which is an achievement of sorts, but it needs more love :P)

Also, I modified your template to ensure that the periodical e-mail doesn't use any HTML, which it did in your version, hmmm... Who cares, this e-mail has yet to be sent to anyone, anyway... :P
 1. Suggesting we should go for 'wenot', although it carries a bit of negativity... :lol:
2795
Archived fixes / Re: Can't Post Thoughts on IE10 on Win8
« on June 23rd, 2013, 01:00 AM »
@godboko, do you have Avast installed on your machine? Or any antivirus? Can you try disabling it when liking a thought?
2796
Archived fixes / Re: Can't Post Thoughts on IE10 on Win8
« on June 22nd, 2013, 12:13 PM »
IE10 is just a filthy sack of shit, just like earlier versions. The apple doesn't fall far from the tree...

Anyway:
http://bugs.jquery.com/ticket/12790

This is jQuery's bug ticket for this issue, and they indicate that Microsoft doesn't seem to give a damn. I'm tempted to revert my changes, and just use $.post(), because really, really, Microsoft, go to hell.
Since we're never going to make money with Wedge, and we spent three years on it already, and I wasted months on IE compatibility, I don't want to spend an extra minute on their vomit.
2797
Plugins / [Plugin] Re: Notifications system (1.0)
« on June 22nd, 2013, 11:52 AM »
Quote from Dragooon on June 20th, 2013, 07:08 PM
Why would you want to have it return topic stuff by default?
Because that's what most notifications will be about... This is a forum, right..?
Quote
The thing is, I don't want to pre-define a lot of behaviour, mostly because then authors don't touch and the experience becomes bad again. Plus I don't want to add pre-defined behaviour for "special" object types, that goes against my model. I want it to be absolutely "core", in the sense it should be as unassuming as possible. I'm assuming a few cases (mostly such as getIcon in which it returns the avatar)
Perhaps because I imposed this one upon you... ;)
Quote
because they are more or less global and can apply to all.
Then it should be called getAvatar and not even be extensible... ;)
Quote
That is why in my view getObjectType is absolutely redundent and not a good idea. I don't think having multiple notifiers is a bad thing, mostly because it gives every notifier an equal chance to implement the same experience for themselves and we don't define anything for them (any notifier that is in the core can't do anything more or less than any other notifier that might be a plugin)
There are many problems in your implementation. There are good ideas, too, but there are problems. I didn't look much into your system until recently, because it was a lot to take in, and I should have really.
First of all, the different files are still fuzzy even to me. Class-Notification.php and Notifications.php are too much alike in their naming. I've come to learn that basically, Notifications.php should have been called Subs-Notification(s).php, since it's a helper class, but having the action handler within it makes little sense. This is probably why support for class::method wasn't added until recently to Wedge's action router, and it was added specifically for your code... Not a biggie, but it makes one wonder whether this was well thought out..? Maybe it should not be a class at all in the first place...

Also, maybe Notification::issue shouldn't be a method. Maybe it should be issue_notification(...), and this redirects to your Notification object, or something... Notification::issue implies that the notif object is loaded, which shouldn't be needed, at least not at all times. I don't know. Maybe it should, but it's just strange to me.

Notifiers are stored in the database with a plural in the name. A single notifications should be sorted as a 'like' or 'mention', not as a 'likes' or 'mentions'...

I have a hard time understanding why id_object gets its own database field. I mean, is that only for a case where you'd want to mark all notifications from a single topic as read once you read that topic..? But (1) there's no way to be sure the user has read the entire topic anyway, (2) I don't even think the code is currently checking unread notifications for a topic being read. Or is it..?

I could possibly agree with having different notifiers for the same notification type, but would have to be reassured on a couple of points...
- Could be done as an extra plugin, e.g. a class named Thought_Like(s)_Notifier, that extends Likes_Notifier, and can override all of its functions. Is that even doable..? (This would allow someone else to release a plugin that adds like notifications to their own plugin-created data types, without having to rewrite the notifier at all.)
- Could be done within the same notifier class, e.g. when returning the notifier name, getName() should return 'like' or 'like_thought', depending on the origin. Of course, this implies that the notifier keeps track of what type it is, internally.
- Doesn't disrupt all existing SQL queries that rely on id_object to filter items, especially since right now these queries seem to imply that id_object is always a topic.
(BTW, I'm surprised that id_object doesn't even get its own key..?!)

I think that's all for now, uh...
2798
Archived fixes / Re: Can't Post Thoughts on IE10 on Win8
« on June 21st, 2013, 04:20 PM »
Uh, what specified prefix..?!
Even then... Wedge is returning HTML, not XML... That's totally crazy.
Remind me

'Like', not surprised you can't, since it's still doing a Post, rather than a Get.
Can you push Like in Desktop mode, Metro mode, and Private mode, just to be sure..?

So, yeah, basically, this is the problem I saw mentioned elsewhere, and moving to $.get fixed it, but I certainly don't like the idea of expecting all variables to be put into the URL in plain sight, but... Whatever...

Pete, what do you think..? $.get or $.post?
2799
Features / Re: More useless nonsense
« on June 20th, 2013, 06:48 PM »
Quote from Arantor on June 20th, 2013, 06:22 PM
Yes it is. The question is not 'should we remove it', at least not immediately. It becomes 'why do they do it differently?' XF does it differently because they believe the majority of owners don't care and would rather use GA to do it anyway.
I'd say, they don't do it because they started their stuff from scratch, and there are tons of things they couldn't bother to implement before they actually went 'gold'...
Quote
There's a very, very good reason for that: bots are not counted. Bots account for a *surprising* percentage of users.
Does Google keep track of all existing bots anyway..? :P

And yes, this is probably the reason, but I'm thinking that they were very, very liberal with what a bot is...
2800
Plugins / [Plugin] Re: Notifications system (1.0)
« on June 20th, 2013, 06:20 PM »
The problem is that I often find myself stuck in object hell...

Example: want to have getPreview() return whatever the notifier wants, but have it return topic stuff by default. Moved code from Notifications.php to Class-Notifier.php, with no special treatment... And, I don't even know if it's the correct target. I suppose it is, but sure..? Nope.

Also, I really think it's best to store the object type in its own field in the database, rather than in the data field. Makes it easier to avoid duplicate entries... And to me, it's better than creating multiple notifier names, one for each object type... Urgh!
2801
Archived fixes / Re: Can't Post Thoughts on IE10 on Win8
« on June 20th, 2013, 06:00 PM »
'kay, just reload your homepage, should be updated now...
Tell me if it's still giving you errors, or not!
2802
Plugins / [Plugin] Re: Notifications system (1.0)
« on June 20th, 2013, 05:20 PM »
There's a filter for unread notifs (default), and a filter for all notifs, including read ones... Just in case you want to quickly access a notification you previewed and closed too quickly, for instance...

As for feedback, I just left it a couple of days, to see if anyone had anything to say, but I guess I'll have to make my decisions myself, eh... ;)
2803
Features / Re: More useless nonsense
« on June 20th, 2013, 10:30 AM »
Quote from Arantor on June 19th, 2013, 09:27 PM
@Nao: Why bother? It's not a stat that is meaningful. Dropping the line entirely means saving queries and stuff.
I can live with the line being removed from the homepage. There's already the record being indicated there, so it's okay to remove the record from the homepage; I can also live with the record being removed from the Stats page, as long as the Online stats are kept in the daily stats.
I'm okay with the 'current day' connection number being removed too, since it can be found in the daily stats, so whatever.
I'm also okay with the daily online stats being hidden from view if you're not allowed to see them.

All in all, it's important to take into account that some admins, at some point in their forum's existence, will rely on these statistics to find more strength to work on their contents. It may be right or wrong, but it doesn't matter: if it's important to some people, we shouldn't remove it entirely.
Granted, it will NOT be important to even a minor portion of regular users, so it's all right to remove everything from *their* view, but admins..? They should still be able to see that.

Regarding guests, I think we agreed a long time ago (although you before me!) that it's okay not to start sessions for guests, and not record them in any kind of statistics, but I'd still like to record them in the Who's Online page, as per their IP address, and show what page they're currently visiting, and whether they're a bot or not. Again, this is the kind of thing that admins may want to know. It's only of interest in the Who's Online page, so I'm pretty sure we can save some processing work outside of these pages, apart of course from recording activity to the log_online table or something.
Still, I'm not sure what takes the most processing time for guests-- session work, or database write work..?
Quote from Arantor on June 19th, 2013, 09:27 PM
I would note that XenForo not only doesn't have that figure, doesn't even track it historically and no-one asks for it that I can find.
xenForo doesn't get everything right...
I, for one, would never have bought it. I'd have bought IPB, had I been forced into buying some forum software. Had I been forced into using some other forum software, though, I wouldn't have bought anything, I would have forked SMF into something cool with a media gallery, a rewritten JS/CSS engine, things like that... Hmm, that's a good idea, actually. I should do that...

So, in short: I chose SMF because I liked it better than the competition. While I have no qualms with removing things from SMF that were short-sighted, I don't think that "just because someone else does it differently", it's reason enough to question a feature that's already in SMF and Wedge, and don't forget that removing stuff will also get you support requests like, "My forum ain't working properly!", "How do I put this feature back into Wedge?", or "You should remove your stupid [Wedge-specific new feature that we all like but take some adjusting to] instead of [SMF-specific old feature that this person liked], sucker! I'm off to [SMF fork that just started and is obviously not going to take off, but whatever your fancy], and [expletive] you!"

I, for one, would like to minimize the number of support requests, be they paid or not...

That's, basically, all I had to say about the subject, I think...
Quote from Arantor on June 19th, 2013, 09:27 PM
See, here's the thing. Those people who don't care about the visitor count aren't going to care that it's gone, and those people who do actually care aren't going to use it anyway because they're going to integrate Google Analytics and/or Piwik or similar.
Back in the day, when I cared about stats, I never used GA, for two reasons:
- it always gave very small numbers, like 10x smaller than SMF gave me, so I didn't trust it much,
- I always got NSL issues with their script, and at the time, it tended to make Opera go cwaaaazy...

So, I was quite happy to have a simple stats page.
2804
Archived fixes / Re: Can't Post Thoughts on IE10 on Win8
« on June 20th, 2013, 10:14 AM »
Well, so that would be a jQuery problem...
Only, it shouldn't happen either way. 4:13166 is e.querySelectorAll(), which is a perfectly valid DOM method, so... Whatever?!

Maybe this could be solved by using $.get instead of $.post on some areas, as it seems related to an 'unfixable' bug in IE10+jQuery that was reported over there. I'm not exactly sure, though... Are you ready to test even more when I apply the change..? :P
2805
Features / Re: More useless nonsense
« on June 19th, 2013, 06:21 PM »
Have an argument in its defense. Please wait until I'm on my PC.

In the meantime... why not simply show this only to admins..? Problem solved...