Wedge

Notification code is up and fixed, I also fixed the Move thing, which had a broken preview, even in the SVN version.

Oh, and btw... Why is the Move notifier called 'move', when others have a 's' at the end..? (likes, mentions)
We should standardize these, too...

And also strtolower the entire class names, because, well, I'm definitely not into these...

I'm still not satisfied with the friggin' sidebar...

I fixed most of my problems, but for performance reasons, I decided to give up the parallax scrolling thing, and it suddenly makes the whole thing very dull, hmmm....

It's still better, on mobile, than whatever is currently available in Wedge, but when it comes to desktop, it's really no good. If I tried to implement some kind of trick to make it as easy to open the sidebar (i.e. an emulated swipe with the right button clicked, or something), I might interfere with mouse gestures, which isn't good...

I'll probably upload *everything* I have in store for now, i.e. all the notification stuff and this sidebar, for a couple of days, so you guys can tell me whether you like them or not, although I might go ahead and commit the notification stuff, already.

Am I supposed to install it and try to break the site, or something..? ;)

Oh, speaking about that one... All of the notifiers I've got under my hand, return false for this, so I changed the default value to return false, this way, we don't have to reproduce the method every time, eh eh...I don't have your Quote notifier, so I don't know what it has, and you'll have to rewrite it yourself, I guess...So I should use id_msg in id_object by default, right..?

Dragooon, can you tell me something? It may not be you, maybe someone else, but I noticed that one notification type (the default, I think) uses id_object to store the topic ID and $data['id_msg'] to store the message ID, while another uses id_object for id_msg, and $data['topic'] (in mentions, I think) for id_topic...

That doesn't make sense to me, because both point to a post, so which is the better one..? Which makes the most sense, in id_object? I would say id_msg, right..? But that's not the default...

Autoload: we could easily call the file Class-wedit.php, it doesn't look as good, but it's not much of a problem..?

Per-album: it's the best solution, because one might want to have 'likes' on a regular album, and 'ratings' on an audio album with multiple tracks that the author wants to know who prefers what, etc... (I feel like I made a grammar mistake in that sentence, hmm...)

AND: see, that's where it goes right over my head... I still have no clue about how indexes work, and not that I care much, either...

Email: let's start with just raw text e-mails, all right..?

---

Other: I'm still lost with these notification objects... An example: getProfile.
Notifications.php does $subscriber->getProfile($memID).
Class-Notifier.php does abstract public function getProfile($id_member)
Likes.php does public function getProfile($id_member), but it doesn't use $id_member...
Notifications.template.php does weNotif::getNotifier($notifier)->getProfile() (without an id_member)...

All in all, I'm a bit lost, but it gets worse with this: I need to have a 'default' getProfile, and I don't know how to declare it.
I changed Class-Notifier's to remove the abstract keyword, but I need to access the current notifier's name, so how do I do it..?


Where do I get $notification from..? Do I have to declare it in the param list, and then get rid of $memID and stuff which is never used anyway, or... What?

How complicated...

But, my ultimate goal is to enable notifications to be as simple as possible, and this is one of the obstacles on my way. ;)

I finally decided against doing the sidebar menu on non-mobile devices, I added the rules to the screen density media query, rather than the screen width media query. The latter applies to any device with a small screen, including a resized desktop browser window, while the former only applies to devices with a screen that has more pixels than visible, i.e. not a regular monitor. (Mac & iPads have a high density, too, but I can't test these...)

Could easily rebuild the filename from the requested filename, it's just a matter of setting the convention..?I don't think we have the same definition of an autoloader, though... You're talking about spl_autoload_register, right..? I was thinking of something entirely Wedge-made, myself...Per-album option, then..?If I was MySQL (but I am not), I would do it this way...
- gather all of the AND elements in the WHERE.
- go through each of them, see if there's a matching index, if yes, use index, otherwise, skip the test for now, and look for the next test that has an index.
- when the loop is finished, if it's still TRUE, then go back to the beginning, and run a regular unindexed sort on all remaining entries, until we get FALSE.

Wouldn't it, err... Make more sense, to run queries this way...?
But as I said, I'm not MySQL... These guys probably know better than me, don't they..?I think I'll let you work on this one, hmm... ;)

Of course, ideally the notif table would be as empty as possible, so it wouldn't be much of a problem. (Thinking about it, do we have an OPTIMIZE query for this one at any point..? Because, I don't think we do, and it'd be useful...)Do what? Ditch attachments..? Nope. I'm always thinking, "this is Wedge 2.0 material... I'll just write a frigging script to convert all current attachments to media items, and be done with it..."Yes, true enough, I fixed the Highslide license issue years ago, but it took me weeks of work to rebuild my very own (Zoomedia), and I'm not looking forward to rewriting the rest of the code for our licensing purposes, I reckon...Hmm...? There's a mod for SMF that advises against using AeMe..? Really?As I told you before (I think), I always feel like it's "my area", but since I haven't even started work on it yet, feel free to do it, after all, I can always alter your changes later, it's really not a big deal, and it'd get me started, I guess...! (Replacing JWPlayer with MediaElementJS is something that really scares the bejesus out of me, I'll admit... And it's not even that big a deal, I suppose...)I think I did it a few days ago, I'm not 100% sure though, I'll have to check...This one really annoys me... Especially since we can't do anonymous functions, because PHP 5.3, while the most commonly used version, is still not overwhelmingly spread, and PHP 5.2 is still installed on something like 43-45% of all servers, so it's a no-no, unfortunately...
Ah, yes, I remember now... Well, I guess I tried to make a concession, by only lowercasing the first letter, and not all, and I figured renaming it to 'wenot' immediately might confuse you, I guess...Hmm, they do..?
Okay, let's take Likes.php as an example... I'll list the functions that are currently in my own version (I removed getPreview, as it's for topics only, will re-add it to non-topics, I guess...!)

   public function getURL(Notification $notification) --> this could be handled by the parent, for topics by default...
   public function getName() --> all right...
   public function getText(Notification $notification, $is_email = false) --> this one's pretty mandatory (see how I added $is_mail, too?)
   public function handleMultiple(Notification $notification, array &$data, array &$email_data) --> does it really need to be in here..?
   public function getProfile($id_member) --> this is going to be the same everywhere, maybe we could just standardize it...? $txt['we' . getName() . '_likes'], etc...? That way, we can put it in the main object... Yeah, that'd be nice...
   public function getEmail(Notification $notification, array $email_data) --> same here, could be standardized, I say...

All in all, there's not much to be done in a notifier, and if you're writing a notification for a thought, I'd even dare to say, it's the same: you'd want to have the 'default' code in a parent object, and the actual notifiers would just need to trust it, is all.
The issue, though, might be to create a new parent object for thought notifications, or media notifications, and I don't know how best to do that, especially, hmm, if we can't determine first-hand what type the notification is, can we...?Less headaches for you, maybe... ;)Yes...http://academy.hubspot.com/blog/bid/109587/
Things like that...
Basically, HTML e-mail = higher chance of being flagged as spam, and thus not seen by the end user.

HTML e-mail is fine for a marketing newsletter campaign, where you're precisely trying to attract someone's attention, but it's no good for something that's utilitarian, and it also makes it look less 'personalized', because you can't help thinking that it's an advertisement, even if it isn't.

Also, HTML takes more bandwidth (for your server...!), tends to irritate people more, is less accessible, and is opened to tons of issues, like you have to do inline styles, which I hate, etc, etc...

All in all, it's really best to do plain text, and I'm going to go that way, but I'll still keep the HTML versions anyway, so if in the future you want to offers users to ability to choose between plain text and HTML (with plain text as default), you can always do it... Okay?