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.

Topics - Nao
16
The Pub / IE 11 and its funny developer tools...
« on March 16th, 2014, 04:30 PM »
So, I installed my Windows updates a few hours ago (for those curious, it did take about an hour... :lol:), and in the lot, I forgot to uncheck IE 11, so it kindly installed it for me.

I figured, what the hell, let's try it again, last time I tried out the beta, and removed it because they'd removed browser modes.

Okay, so...
- These new dev tools, where did they build the UI..? Did they actually have plans to build a UI for it?! It absolutely sucks. Everything is optimized towards reducing productivity. We're talking about a finished product that's supposed to overtake Chrome and Firefox and everything... Ah ah ah. Just launch it, then start scrolling. YEAH, smooth scrolling. Did I say SLOW, too? Smooth is nice. But if the user has disabled smooth scrolling in *Windows animations*, why the hell would they want that in another program..?

- Browser mode... Okay, they renamed that to Document mode. Yeah, super. They made it much harder to trigger (IE10: press F12, click the select box, select, done. IE11: press F12, scroll down the icon list, determine that the last one is the right one, then go through the list of select boxes, choose the one that NO LONGER says Browser and says "Edge" instead of "IE 11" making it even harder to find, and then select in the dropdown.)

- Okay, so I'm actually trying it out on my local website.

- IE 11: nice... Except that a child div having an opaque background will override its parent's border-radius. Opera has the same problem, but we're talking about a browser whose engine was last updated in 2012. Also, it doesn't seem to properly support display: flex, even though IE 10 does. Well, as far as I can remember, it did in my IE 10 install...

- IE 10: looks okay. Except for the flex thing.

- IE 9: at that point, all hell breaks loose.

- And then I realize that not only do I have to switch Document Mode to 9, but I also have to switch the user agent to 9. Manually, for each and every browser change!! If I don't, IE8 becomes ridiculous, as it no longer loads the html5shiv, and thus doesn't recognize <aside> tags for instance, and breaks the sidebar layout.

- Funny fact: if you close the dev tools, IE will automatically reload the IE 11 version. Which is so nice for making life easier for developers... Not.

Anyway... Apart from that, it looks okay, but I'd like to know if any of you who haven't installed IE 11 can see the same header in Wilde as in the screenshot below. That is: normally, the Unwedge title should be at the BOTTOM of the banner, rather than the top.
17
Features / Poll: changing paths
« on March 3rd, 2014, 12:34 PM »
Advantages of changing paths:
- You can move your source files to a non-accessible path, meaning no one can see their contents, even if you server fails.

Advantages of keeping paths the same across all copies of Wedge:
- Moving your Wedge install to another folder is a no-brainer, because all paths are automatically updated.
- Seriously, even if someone could see your source file contents... Who cares? They can already see them on GitHub anyway!

To me, the only file that MIGHT warrant being moved to a non-web space is Settings.php, and even SMF doesn't support that... If you're not modifying your Settings.php file (i.e. keeping away from the admin area), you could consider turning Settings.php into a file saying "include (__DIR__ . '../../somewhere/Settings.php')", but because Wedge may not have write access to said path, it's not realistic to expect it to handle this kind of redirection easily.
It might be possible to create a hardlink to that file, but I'm not sure it wouldn't simply be shown in the same circumstances at a regular file.

Can anyone think of a GOOD reason to move your folders around..?

PS: media and attachment folders are a special case, though. It's likely that I'll keep the ability to move them around, because of potential disk space concerns.
18
Features / Poll: dropping oldIE
« on March 3rd, 2014, 12:21 PM »
I already had a similar poll last year, but want to make sure the new guys have a say in this!
19
Features / Stuck on a programming model...
« on February 24th, 2014, 03:57 PM »
I could do with some ideas here.

Okay, so a couple of weeks ago, I decided to shorten the {db_prefix}members table, by moving some of its 'optional' fields into the data field (which is a do-it-all column that holds a serialized array.)

Among the fields I moved, 'message_labels' had for my account a value of "À répondre", which is a label I made which means "pending reply". As you can see, there are accents in that string...

Now, imagine this. I'm trying to keep it simple:
$data = array('member_labels' => 'À répondre');
$data_field = serialize($data);
Then insert $data_field as the 'data' field in the members table.

All right..?
Now, do the reverse. unserialize($row['data']), basically.
Unserialize error. Ouch.
Why so?
Because, apparently, the string was turned into a different format between the moment it was serialized, and the moment I attempted to unserialize. This only happens for data fields that contain accents or other weird characters, so English users probably never saw this happen. A serialized string first holds the size of a string, then its contents. If the string is modified in the meantime, then the size won't match, and this will trigger an unserialize error.
  • Now, I attempted to 'correct' this by turning my serialized strings into JSON strings instead. But by default, PHP decodes these into stdClass objects, which sucks, because I either have to specifically recast them as arrays, or add a parameter in json_decode.
    Okay, I can live with that... But other tables in Wedge also hold a 'data' field, which in turn is also a serialized string. Does it mean I should use json_encode instead everywhere...?

    That was my first solution. The advantage of JSON is that it makes shorter strings, but they're also slightly slower to decode. Not that much, mind you...

    Okay, next solution?

  • Call westr::utf8_to_entity() on every array I'm going to serialize. Unfortunately, it's also a slow function, and to be sure, we need to call it on every single data sub-field, which could eventually waste a lot of time. This is the currently (half-) implemented solution.
  • Try to find a solution to that storage problem. I didn't try this first, because honestly I suck at handling UTF in databases. But logic dictates that if you store a UTF8 string and retrieve it, as long as the database is UTF8, it should return the same UTF8 string. Unfortunately, it doesn't seem to do that. Is this a bug in the Wedge codebase? SMF codebase? Or a problem with my database?
Honestly, I'm looking into the last solution because it'd be the easiest to implement in the end, but I'm all ears when it comes to other alternatives, or ANYTHING that could help with this situation, really. Did any of you ever get into trouble with something of this kind..?
Yes, I did google this, and found stuff, but nothing helpful, unfortunately. People seem to assume that you shouldn't serialize a string for transmission through a database system, because "you're never sure what you're going to get back"... Heck, YES I know what I should be getting back. I should be getting the same string...! Some people suggest simply rewriting the serialized string's sizes through a preg_replace_callback, but this is too CPU-intensive to my taste, and I'd like to find a logical solution, instead of a dirty hack.

Feel free to chip in, if only to say which solution you'd prefer. Thanks!
20
Importing into Wedge / Importing member fields into members.data?
« on February 16th, 2014, 01:11 AM »
This is mainly for @TE...

I'm looking into moving some {db_prefix}members columns into {db_prefix}members.data, where they'll be serialized and stored with other variables.

A few reasons for that...
- Well, there are 60 or 70 columns in that table... Not exactly EASY to browser through.
- I think I could save about a dozen (or at least half a dozen) columns by moving them to data.
- Basically, anything that (1) doesn't have an associated index, (2) doesn't need to be updated for anyone but the current user.

For now, I've moved 'mod_prefs' to data['modset'], and 'secret_question/secret_answer' to an array called secret_qa.
What I've been doing is: enter this into my new Upgrade script (not yet committed), where Wedge will get the existing entries, then convert them to data variables, and then remove the columns when it's done.

I guess it works fine if you're on a current install of Wedge: the upgrade script will pick it up, and then upgrade your table automatically.
But what if you're installing a new version..? The upgrade script won't run, because the database is in the new format, and it doesn't need to run. So... What to do?

(a) Leave the database with all these extra fields, because it's only annoying when browsing through phpMyAdmin, but 10 less fields won't make a big difference in either convenience or performance. (I'm not saying it won't; I'm giving you an opportunity to say whether you think it will.)

(b) Leave the database as is, at Wedge install time. Also set the database version to zero, basically... And let Wedge process it. But this means the import process needs to be done immediately after installing. Ouch... (Because, otherwise, Wedge will then start the upgrade process, and then delete the columns after it's gotten zero results on secret_* etc.)

(c) Add some code in the import script to make it possible to easily import an member field into the members.data field.

What do you think, guys..? (Especially Thorsten!)
21
Archived fixes / Some thoughts on notifications
« on February 7th, 2014, 11:18 AM »
Just wanted to discuss two things in notifications... The user side has many questions, so get prepared!

- On the code side: yesterday, I was a bit disappointed that it took so long (about an hour) for me to re-figure out how the system worked. I was expected to re-use Like_Notifier for thoughts, but it wasn't possible because thoughts don't have a topic ID. I'm okay with that, as most notifications won't have this problem anyway, but still... Isn't this whole OOP code a TAD too complicated..? I know that Dragooon (who wrote the original code) likes it, but I'm just wondering if there couldn't be a simpler way of doing things. Or, at the very least, ensuring there are LESS files to play with... Seriously, I still can't grasp why there's Class-Notifier, Class-Notification, Notification and Notify PHP files. I'd be willing to accept two files, but four is a bit much for me...
As I'm not planning to add class auto-loading to Wedge (first and foremost because I don't like the idea! Laziness is for users, not developers!), we could at least merge all classes into one file. Like I did for Class-Skeleton.php, which has both the dynamic weSkeleton class, and the wetem static class which is build on it, and renders the whole damn page.

- On the user side: should I make notifications closer to the Facebook system..? Well, I don't know, but if there's one thing that I don't think is questionable in usability over at FB, it's notifications. I'm okay with them. In fact, current notifications in Wedge are closer to FB's than Dragooon's original implementation. But there are things that I want to get opinions on.

a) Is it better to decrease the notification count once you've previewed a notification and it's marked as read, OR to reset it to zero when you've opened the notification popup, like on Facebook..? Notifications would still show as unread and all, and I could even still show the unread count once the popup is opened, but maybe it would be easier to catch your attention when the counter turns orange from gray, rather than increasing from 6 to 7 while staying orange. I tend to remember my latest number of notifications, but... Well, I'm still at 25 unread notifications, and 20 unanswered PMs. (So, if you're wondering why I'm not answering your PM(s)... Please, I prefer forum posts, where it's easier for me to keep track of things, and reply with my phone if needed! The mobile skin has yet to do things about the PM template, it's just not usable on mobile right now.)

b) There's currently a small bug in grouped notifications. Again, this feature was implemented by Dragooon, and I haven't touched it at all (I think), and I think it's a good thing and all, but I'd rather see, in addition to what's already shown, the number of likes I've gotten since last time on a particular post, instead of just the name of the first liker. I think it would be swell. I don't remember if that number is stored, though, but I can always do something about that... However, UI-wise... If more than 1 like, should I show a name at all? Maybe '2 persons liked your post', and then if you click Preview, Wedge shows you a list of all recent likers, and then the preview of the post...? Or just show like now, just one name, and a number next to it? That would need explaining... Or show "Dragooon and 2 others liked your post"? But that one implies additional language strings, and for each of the notification types.

c) Should I add a 'Mark all as read' button at the bottom of the notification popup...?

d) I'm still planning for a 'Mark unread' button to show up below post previews in notifications, to revert an automatic markread. And a 'Mark read' below PM previews, to force a markread, obviously. What else should be there next to these options..?
22
The Pub / Preparing for an 'official' public alpha...
« on February 6th, 2014, 02:36 PM »
So, basically, could we establish a list of what I forgot to fix, implement or generally do to the codebase in order to make a viable public release..?

Thanks! There are so many topics right now, I feel it'll be faster if everyone chips in!
23
Features / What's the purpose of non-database sessions?
« on February 3rd, 2014, 07:10 PM »
I think I've got the hang of manipulating sessions in database fields (I had to do that in order to implement session-based caching :P), but now I'm playing with non-database sessions, and having problems, namely my sessions are automatically regenerated every X seconds, making it impossible for me to connect to my test admin area, lol.

I was getting started on fixing this, when suddenly it hit me... What's the point?! If this bug wasn't found before, maybe that's because no one ever uses file-based sessions.

I'm tempted to just remove the feature, which will make one line less to read at install time. What do you think, guys..?
24
Features / On the desirability of automatic updates..?
« on January 31st, 2014, 10:12 PM »
In reply to:
http://wedge.org/pub/bugs/8393/errors-when-checking-detailed-version-info/msg293427/#msg293427

Believe it or not, it's actually in my plans... :P

However, it might require some time.
Remember when Aeva used to update its sitelist by itself every day..? Well, for a long time I've had the same idea in mind for Wedge, but with technical difficulties (notably the amount of bandwidth needed to account for version checks.)
When I heard of Github Releases, I figured, is it possible to get a URL to these files, directly..? And yes, it is. By using their well-documented API, one can do up to 60 requests per hour (or 5000 if you provide an ID token) from a certain IP, so it's a piece of cake for Github to 'accept' a daily request from even thousands of different servers, checking whether a new release was posted.
If a release is available, I can then get the URL to the zip or tarball, and then proceed to warn the user about it. Should they choose not to ignore the update, they could press a button to automatically download it to the server, and optionally (if supported), unzip it somewhere. Then, if that works, either apply the files automatically (move from tmp folder to core, assets, etc.), or offer the user to log into their site by FTP, and move the files they want to move.

Technical problems:
- This doesn't account for deleted files... But the automatic upgrade script could account for these, though, and make sure to try and delete them, if they can be harmful to Wedge.
- I don't know much about unzipping tarballs. I think there are plenty of functions for that kind of action available in Wedge, though...
- What if the automatic update process fails? Will it break a forum..?
- What if users don't have correct PHP file permissions for unzipping, etc..?
25
The Pub / On refactoring the installer flow...
« on January 24th, 2014, 05:17 PM »
Quote from havok on January 23rd, 2014, 03:00 PM
deleting the folder with go daddy admin panel was leaving some residual files. when i used 3rd party ftp to delete the folder worked like a charm. back up and running
 :eheh:
I was actually working, a few hours ago, on making the install process easier for everyone.

The idea is to:
- ship Wedge WITHOUT these folders: /attachments, /media, /install/Settings.php, /install/Settings.php.bak
- modify index.php so that on each page load, it checks for these files. If it finds them, cool. If it doesn't, it actually recreates them from scratch, not from an existing file or folder, but simply by creating files and writing text to them. (Yes, it works fine. And it avoids the eternal problem of ensuring these folders are all writable.)
- if Settings.php isn't found, run the install process.

This is pretty great. But causes three major problems to me.
  • By running the install process, I *thought* that it would be simple to just include /install/install.php, but in fact it's more complicated than that, as Wedge expects the installer to be in the root... So, I'll probably (?) have to copy the install.php file to the root automatically, and then run it from the root.
  • More importantly, what happens if someone else visits your empty website after you uploaded it by FTP and before you went to the root? Because the Settings.php file was already re-created, you'll just find an error page because the DB data is wrong, while the other visitor will be presented with the installer tool. Meh... Of course, not possible.
  • I don't know if I should be wasting time making multiple folder/file existence tests for each page load: the aforementioned files, but also generally the /install folder. If it's found while Wedge is up and running, should we attempt to delete it..? And if it fails, does that mean Wedge will permanently try to delete that folder on each page load...? :-/
Opinions welcome, really.
26
The Pub / What I HATE in Wedge!
« on January 22nd, 2014, 01:36 AM »
If you have anything nasty to say about Wedge, post it here!
You can't please everyone, so I'm expecting some negative feedback. If many people agree on something, then maybe it's time to do... something about it.

You don't have to install Wedge of course, but if you do, you'll be able to say what you hate about the admin area, of course.
27
The Pub / What I LIKE in Wedge!
« on January 22nd, 2014, 01:36 AM »
If you have anything nice to say about Wedge, post it here!
Did you enjoy a particular feature that you think makes it stand out from the rest? Did you notice a little something that was never advertised anywhere, but that made you fall in love with Wedge?

You don't have to install Wedge of course, but if you do, you'll be able to say what you like about the admin area, of course.
28
The Pub / Wedge repo -- installation feedback
« on January 21st, 2014, 04:13 PM »
I was in the process of writing the blog post about it all. (Yesterday, I spent like an hour writing the README for the repo[1], so it felt comparatively faster.)
Anyway, yeah, the importer will be ready when it's ready, and since it still worked a few weeks ago, I'm guessing it doesn't require a lot of work, and I could even fix it now, but... Really, REALLY, all I want is to finish that pesky movie I was watching.
 1. Hopefully you don't find its humor too lacking in taste... That's what happens when you're over-stressed :P
29
Development blog / That'll do.
« on January 21st, 2014, 04:08 PM »
And here it is. I wanted to postpone it even more... But you don't deserve it. If anything goes wrong, I'll deserve it. In the meantime, please enjoy this; some of you have been waiting over three years for this moment.

https://github.com/Wedge/wedge

Read the README for instructions.
I will attempt to release a public alpha once I get some feedback confirming that everything's working all right.

https://github.com/Wedge/plugins

This is the official plugin repository. Most of these were written by Pete, John and Shitiz. The current license for them is the Wedge license; eventually, though, my goal is to make it clear which plugins are under more permissive licenses. Perhaps I'll even be able to make them all MIT, or something. If you write a plugin and don't want to share it under the MIT license, you can always push it elsewhere.

https://github.com/Wedge/languages

This one isn't a new repo, I introduced it recently on this blog, but what's new is that all of its files are now governed by the MIT license.

Lastly, if you're planning to make the switch to Wedge from an active SMF forum, please remember this:
  • There is currently no 'proper' importer available. Pandos confirmed to me that the official importer is broken, so I'll look into it ASAP.
  • Said official importer will be pushed to the Wedge/tools repo (or its own repo) when available. I'm planning to have it around by next weekend at the latest.
  • If Thorsten looks into it before I do (I know he loves this kind of thing), then he may fix the importer before I do. See? A programmer's logic is no more complex than yours.
  • It's still an alpha, even three years in. Meaning nothing is set in stone, and if a change I make breaks your forum, you can't complain to me. And if it makes it better, then you can't complain either. That was the whole point, after all.
Now, please allow me for a short break, before I jump into new adventures with you all.

30
The Pub / Last minute frights
« on January 19th, 2014, 11:37 PM »
So, I'm supposed to release tomorrow...

Today, I changed another set of files (/cache became /gz, and /css and /js were integrated into it), because I didn't like having so many root folders just for caching.
I also screwed up another commit, with a change that was too random and broke other stuff. In the future, these changes will be reverted the usual way, but I much prefer being able to amend a commit. I'll just have to learn, I guess, that I shouldn't push until everything's tested...

My main issue is with the update process. Now I have this /core folder where I log into. Then I have to determine what files I should update. I'm totally lost, because the folder names are no longer distinguished by starting with an uppercase char or something like that.
Voilà. I just don't like the new update process. I find it harder, or longer, than the previous one. But I can't revert either, because this new folder structure has some actual *meaning*. I wanted to remove themes, so I'll have to live with the fact that I can't rely on the Themes folder structure any more.

Believe me... It's hard.

And tomorrow, I'm supposed to set the database structure in stone. I'm supposed to say, "okay, I'll never change it anymore, except for big additions for which I'll write some sort of script."
But the more I look at the SQL file, the more I find things to change.

For instance, MySQL 5.0.3 supports the BIT data format. Ever heard about that..? Me neither. TINYINT(1) is used for booleans in Wedge (and SMF), but it still uses one byte per entry. The BIT(1) format allows the use of 8 times less space. So, yes, it's VERY tempting to start using BIT(1) everywhere, since Wedge will always support it... But... There's a but... WHAT if one of these columns actually has more than two values? Like, for instance, "wedge_screwed_up.IamABoolean = (0, 1, 2)", where "2" was added by a SMF developer to account for a problem that couldn't be solved with binary thinking. It still fits into TINYINT, but not into BIT. Making it prone to bugs in Wedge.

There are dozens of TINYINTs, and I don't know if it's worth double-checking every table to make sure it doesn't use these columns in a weird way.
I can always change everything to BIT(1) later, little by little, but...

It just goes to show that I don't feel ready for a public release. Really, really, I feel like I'm freezing.