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 - Arantor
166
Archived fixes / (SMF bug) Admin registering a user, email does not send a link to the forum
« on April 25th, 2012, 10:38 PM »
It's not something I think you'd encounter that often but a user that I look after just reported this to me in SMF and I see no reason why we would have touched this thus far.
If you register a user from the admin panel, it will email them with the username and password but it actually won't email them a link to the forum >_<
And because of how the templates are set up, well, it's a bit more complex. I'm going to document the SMF code fix here because that's what has to be done first, but then we can fix it in Wedge just after since the code should be virtually if not actually identical.
We need to create somewhere we can actually inject the $scripturl into. Themes/default/languages/EmailTemplates.english.php:
Code: [Select]
Replace with:
Code: [Select]
The line's a bit crap but I deliberately did not want to leave it as the closing element on the line, for all the fun and games the trailing . would leave.
Other thoughts:
After finding loadEmailTemplate, I discovered that {SCRIPTURL} is a replacement that's already handled natively there, though I have to admit I didn't think it was, and started digging into where the replacements were defined in Subs-Members.php for that email. Though I have to say, loadEmailTemplate is in a funny place and it makes me wonder about doing other things with restructuring internal facilities, perhaps like moving all the email functions into one place and invoking that when needed rather than this other slightly weird hierarchy of things needed. (Subs-Post.php, primarily, for all the email related stuff, even sending PMs)
If you register a user from the admin panel, it will email them with the username and password but it actually won't email them a link to the forum >_<
And because of how the templates are set up, well, it's a bit more complex. I'm going to document the SMF code fix here because that's what has to be done first, but then we can fix it in Wedge just after since the code should be virtually if not actually identical.
We need to create somewhere we can actually inject the $scripturl into. Themes/default/languages/EmailTemplates.english.php:
'admin_register_immediate' => array(
'subject' => 'Welcome to {FORUMNAME}',
'body' => 'Thank you for registering at {FORUMNAME}. Your username is {USERNAME} and your password is {PASSWORD}.
{REGARDS}',
),Replace with:
'admin_register_immediate' => array(
'subject' => 'Welcome to {FORUMNAME}',
'body' => 'Thank you for registering at {FORUMNAME}. Your username is {USERNAME} and your password is {PASSWORD}.
You can reach {FORUMNAME} by visiting {SCRIPTURL} in your browser.
{REGARDS}',
),The line's a bit crap but I deliberately did not want to leave it as the closing element on the line, for all the fun and games the trailing . would leave.
Other thoughts:
After finding loadEmailTemplate, I discovered that {SCRIPTURL} is a replacement that's already handled natively there, though I have to admit I didn't think it was, and started digging into where the replacements were defined in Subs-Members.php for that email. Though I have to say, loadEmailTemplate is in a funny place and it makes me wonder about doing other things with restructuring internal facilities, perhaps like moving all the email functions into one place and invoking that when needed rather than this other slightly weird hierarchy of things needed. (Subs-Post.php, primarily, for all the email related stuff, even sending PMs)
167
Archived fixes / Drafts being saved is not shown in QR
« on April 25th, 2012, 08:38 PM »
I now have 53 pages of drafts (at 15 per page!) that have been saved where the AJAX call is being made to save a draft but the response is not properly being handled, so not only does the 'remove draft' button not appear, but the draft is also not purged on posting because the id is never injected into the form.
168
Test board / Characters in CP-1252 that don't work, apparently
« on April 25th, 2012, 07:33 PM »
80 € U+20AC € Euro reserved control
82 ‚ U+201A ‚ Low-"9" opening quotation mark Break Permitted Here
83 ƒ U+0192 ƒ1 or ƒ Florin/script f/folder No Break Here
84 „ U+201E „ Low-"99" opening quotation mark Index
85 … U+2026 … Ellipsis Next Line
86 † U+2020 † Single dagger Start of Selected Area
87 ‡ U+2021 ‡ Double dagger End of Selected Area
88 ˆ U+02C6 ˆ Circumflex ^ accent (combining?) Character Tabulation Set
89 ‰ U+2030 ‰ o/oo per mille Character Tabulation with Justification
8A Š U+0160 Š1 or Š S + caron accent Line Tabulation Set
8B ‹ U+2039 ‹ Single left angle quote < (guillemet) Partial Line Down
8C ΠU+0152 ΠOE ligature Partial Line Up
8E Ž U+017D Ž2 or Ž Z + caron accent Single Shift Two
91 ‘ U+2018 ‘ "6" opening quotation mark Private Use One
92 ’ U+2019 ’ "9" closing quotation mark/apostrophe Private Use Two
93 “ U+201C “ "66" opening quotation mark Set Transmit State
94 ” U+201D ” "99" closing quotation mark Cancel Character
95 • U+2022 • Solid bullet Message Waiting
96 – U+2013 – En-dash Start of Guarded Area
97 — U+2014 — Em-dash End of Guarded Area
98 ˜ U+02DC ˜ Tilde ~ accent (combining?) Start of String
99 ™ U+2122 ™ Trademark TM reserved control
9A š U+0161 š1 or š s + caron accent Single Character Introducer
9B › U+203A › Single right angle quote > (guillemet) Control Sequence Introducer
9C œ U+0153 œ oe ligature String Terminator
9E ž U+017E ž2 or & #382; z + caron accent Privacy Message
9F Ÿ U+0178 Ÿ Y + diaeresis/umlaute accent Application Program Command
82 ‚ U+201A ‚ Low-"9" opening quotation mark Break Permitted Here
83 ƒ U+0192 ƒ1 or ƒ Florin/script f/folder No Break Here
84 „ U+201E „ Low-"99" opening quotation mark Index
85 … U+2026 … Ellipsis Next Line
86 † U+2020 † Single dagger Start of Selected Area
87 ‡ U+2021 ‡ Double dagger End of Selected Area
88 ˆ U+02C6 ˆ Circumflex ^ accent (combining?) Character Tabulation Set
89 ‰ U+2030 ‰ o/oo per mille Character Tabulation with Justification
8A Š U+0160 Š1 or Š S + caron accent Line Tabulation Set
8B ‹ U+2039 ‹ Single left angle quote < (guillemet) Partial Line Down
8C ΠU+0152 ΠOE ligature Partial Line Up
8E Ž U+017D Ž2 or Ž Z + caron accent Single Shift Two
91 ‘ U+2018 ‘ "6" opening quotation mark Private Use One
92 ’ U+2019 ’ "9" closing quotation mark/apostrophe Private Use Two
93 “ U+201C “ "66" opening quotation mark Set Transmit State
94 ” U+201D ” "99" closing quotation mark Cancel Character
95 • U+2022 • Solid bullet Message Waiting
96 – U+2013 – En-dash Start of Guarded Area
97 — U+2014 — Em-dash End of Guarded Area
98 ˜ U+02DC ˜ Tilde ~ accent (combining?) Start of String
99 ™ U+2122 ™ Trademark TM reserved control
9A š U+0161 š1 or š s + caron accent Single Character Introducer
9B › U+203A › Single right angle quote > (guillemet) Control Sequence Introducer
9C œ U+0153 œ oe ligature String Terminator
9E ž U+017E ž2 or & #382; z + caron accent Privacy Message
9F Ÿ U+0178 Ÿ Y + diaeresis/umlaute accent Application Program Command
169
The Pub / Number of 'online users'
« on April 22nd, 2012, 01:57 AM »
You're probably aware of the count at the bottom of the board index/info center as to the number of 'online users' on the site and in particular the peak number online per day.
I'm wondering what people would say about removing that. You're probably thinking it's a big deal, but hear me out before you shout me down in flames, I think removing it would have some merit.
1. The figure is inaccurate. It's counting the 'number of unique visitors at a time'. Except multiple search bots bump that figure up, since Google, Bing and Baidu all send multiple bots at a time visiting the site.
2. If you do care about the statistics, odds are you'll be using Google Analytics or similar anyway, which will give you quite different figures.
3. The number of signed in users at once can always be obtained with relative accuracy but the number of guests, not so much.
4. Making the requirement for sessions on guests go away solves the bulk of the EU Cookie Law problem, as well as all of the PHPSESSID problems for search engines.
5. It would also make things quite a bit leaner on the DB side, with a lot of stuff just not having to be done dealing with sessions etc.
On the other hand, we are talking about a stat that people do rely on for gauging activity, and one that people frequently attempt to lie about on their forums to make them appear busier than they actually are. (Something I will strongly discourage in any event, it's unnecessary and you will be found out in the end)
Nao has suggested using IP addresses to identify users, and while I'm against the idea on several grounds (notably concerning privacy and technical accuracy), the odds are it would give you as meaningful a number as the current number is.
Add to that, that you can tweak the boundaries of 'what's online being based on' (e.g. number of users in the last 10 minutes vs number of users in the last 30, is obviously going to skew things) and people then proceed to lie about that. Seems to me that by cutting all that out and being done with it, you actually gain more than you lose, since really you're just losing a number that means basically squat in the real world.
There is a side concern: those of you who regularly watch Who's Online to see what people are doing, you'd be restricted to signed-in users only. I realise that some of you will have concerns over this, like those who sit and watch Who's Online for those trying to register, only to go look up on SFS or similar... I'm not convinced that's a particularly useful pastime anyway, but that would be cut out.
So, all that considered, you lose the ability to watch guests, watch what they're looking at 'right now' (though of course you can review the server logs if you're that bothered, and of course other stats are still maintained like topic view count), and you'd lose this vague stat, but you'd gain speed, some SEO boosts of sorts and you'd be far closer to compliance with the EU cookie laws that are coming in.
Let me know what you think, and we'll go from there.
I'm wondering what people would say about removing that. You're probably thinking it's a big deal, but hear me out before you shout me down in flames, I think removing it would have some merit.
1. The figure is inaccurate. It's counting the 'number of unique visitors at a time'. Except multiple search bots bump that figure up, since Google, Bing and Baidu all send multiple bots at a time visiting the site.
2. If you do care about the statistics, odds are you'll be using Google Analytics or similar anyway, which will give you quite different figures.
3. The number of signed in users at once can always be obtained with relative accuracy but the number of guests, not so much.
4. Making the requirement for sessions on guests go away solves the bulk of the EU Cookie Law problem, as well as all of the PHPSESSID problems for search engines.
5. It would also make things quite a bit leaner on the DB side, with a lot of stuff just not having to be done dealing with sessions etc.
On the other hand, we are talking about a stat that people do rely on for gauging activity, and one that people frequently attempt to lie about on their forums to make them appear busier than they actually are. (Something I will strongly discourage in any event, it's unnecessary and you will be found out in the end)
Nao has suggested using IP addresses to identify users, and while I'm against the idea on several grounds (notably concerning privacy and technical accuracy), the odds are it would give you as meaningful a number as the current number is.
Add to that, that you can tweak the boundaries of 'what's online being based on' (e.g. number of users in the last 10 minutes vs number of users in the last 30, is obviously going to skew things) and people then proceed to lie about that. Seems to me that by cutting all that out and being done with it, you actually gain more than you lose, since really you're just losing a number that means basically squat in the real world.
There is a side concern: those of you who regularly watch Who's Online to see what people are doing, you'd be restricted to signed-in users only. I realise that some of you will have concerns over this, like those who sit and watch Who's Online for those trying to register, only to go look up on SFS or similar... I'm not convinced that's a particularly useful pastime anyway, but that would be cut out.
So, all that considered, you lose the ability to watch guests, watch what they're looking at 'right now' (though of course you can review the server logs if you're that bothered, and of course other stats are still maintained like topic view count), and you'd lose this vague stat, but you'd gain speed, some SEO boosts of sorts and you'd be far closer to compliance with the EU cookie laws that are coming in.
Let me know what you think, and we'll go from there.
170
Off-topic / Random idea: non-generic default avatars
« on April 9th, 2012, 02:56 PM »
http://www.phoboslab.org/log/2008/12/instant-avatars
I think it might be cool to have this as an option, perhaps replacing an empty avatar by default. Not sure I want it in Wedge core but could be a neat plugin.
Of course, I'd probably rethink the distribution method slightly and have it be a setup whereby it would generate the avatars for users on the first call and thus make them stored thereafter.
I think it might be cool to have this as an option, perhaps replacing an empty avatar by default. Not sure I want it in Wedge core but could be a neat plugin.
Of course, I'd probably rethink the distribution method slightly and have it be a setup whereby it would generate the avatars for users on the first call and thus make them stored thereafter.
171
The Pub / The Cookie Law (in the UK at least)
« on April 5th, 2012, 06:55 PM »
http://www.theregister.co.uk/2012/04/05/eprivacy_directive_web_analytics/
For those who haven't been following it, essentially this is about cookies and that cookies not being used for 'essential functionality' need to be obtaining permission from the user first.
I'm not quite sure how the hell they intend this to be enforced, but the fact is that site operators in the UK do need to bear this in mind, and any European operator should at least be mindful since it is planned to be rolled out across the EU in some fashion.
Interestingly this was raised some time ago on sm.org, about whether SMF would consider it and I was less than enthused at the response there (since it is a valid matter of concern, just not for them, of course)
The question for us is whether the cookie in Wedge is considered an essential function or not. I'm ignoring the fact that we could just ignore cookies and push the SID via the URL of course, which would be an incredibly bad move, and as far as I'm concerned, I can satisfactorily argue the use of cookies for members as essential functionality - for the security aspect alone.
For guests the matter is a lot more complicated. The cookie there is still the session identifier, but for guests the purpose is merely to indicate uniqueness of session, as a vague form of analytics to figure out how many users are currently on the site (as entirely unique sessions will not do this)
I find the whole concept a bit ridiculous, actually, because as I said you could ignore cookies entirely and still pass all the data between pages internally - but it does essentially exclude Google Analytics, which is of course the point.
This last point does bother me, actually. Firstly, I don't know how it's going to work if I make a plugin of GA, because I don't think it will really pass their rules, and that I'm subject to these rules. Secondly, I have the uncomfortable feeling we're going to start seeing sites that actively demand GA to be running to work, or that they'll run their own full-on analytics.
For those who haven't been following it, essentially this is about cookies and that cookies not being used for 'essential functionality' need to be obtaining permission from the user first.
I'm not quite sure how the hell they intend this to be enforced, but the fact is that site operators in the UK do need to bear this in mind, and any European operator should at least be mindful since it is planned to be rolled out across the EU in some fashion.
Interestingly this was raised some time ago on sm.org, about whether SMF would consider it and I was less than enthused at the response there (since it is a valid matter of concern, just not for them, of course)
The question for us is whether the cookie in Wedge is considered an essential function or not. I'm ignoring the fact that we could just ignore cookies and push the SID via the URL of course, which would be an incredibly bad move, and as far as I'm concerned, I can satisfactorily argue the use of cookies for members as essential functionality - for the security aspect alone.
For guests the matter is a lot more complicated. The cookie there is still the session identifier, but for guests the purpose is merely to indicate uniqueness of session, as a vague form of analytics to figure out how many users are currently on the site (as entirely unique sessions will not do this)
I find the whole concept a bit ridiculous, actually, because as I said you could ignore cookies entirely and still pass all the data between pages internally - but it does essentially exclude Google Analytics, which is of course the point.
This last point does bother me, actually. Firstly, I don't know how it's going to work if I make a plugin of GA, because I don't think it will really pass their rules, and that I'm subject to these rules. Secondly, I have the uncomfortable feeling we're going to start seeing sites that actively demand GA to be running to work, or that they'll run their own full-on analytics.
172
Off-topic / Another reason to dislike reCaptcha
« on April 4th, 2012, 01:49 PM »
Regular readers here will know that I dislike reCaptcha, a lot.[1]
Putting aside the fact that it is worryingly flawed,[2] we have an interesting new vector for it.
I give you: http://www.theregister.co.uk/2012/04/04/google_recaptcha_street_view/
Specifically, it's using street numbers, and possibly street names, off Street View as things it's expecting you to decipher, to improve their database. Very effective crowdsourcing, potentially, but also it makes a mockery of any anti-spam considerations it may once have had.
Putting aside the fact that it is worryingly flawed,[2] we have an interesting new vector for it.
I give you: http://www.theregister.co.uk/2012/04/04/google_recaptcha_street_view/
Specifically, it's using street numbers, and possibly street names, off Street View as things it's expecting you to decipher, to improve their database. Very effective crowdsourcing, potentially, but also it makes a mockery of any anti-spam considerations it may once have had.
| 1. | And that I only wrote a reCaptcha plugin to prove the viability of the CAPTCHA hooks, and to avoid people whining about not having it, not because *I* wanted it. |
| 2. | It shows you two words, one of which it actually doesn't know itself, and has been known to display numbers, and even mathematical equations and Hebrew writing, as the second 'word', in an attempt to crowdsource their meaning, which doesn't work as well as you might think, because people including bots just put nonsense in. In any case, even the word it does know, it accepts one letter being wrong, making it even less reliable than an actual regular CAPTCHA that displays a word. Small wonder it's been broken by bots. |
173
Archived fixes / View poll results gives extra option
« on March 31st, 2012, 03:35 AM »
When you have a poll, that you haven't yourself voted in but that you have permission (either because you're the poll starter or because you gave permission) to view the results, you get a 'View Results' button next to the Edit/Remove/Lock Voting buttons.
So far so good, but if you hit that button, you get the results, a Voting Options button to take you back - and you get another 'View Results' option, even though that's where you already are.
As far as I remember this is also a bug in SMF, too.
So far so good, but if you hit that button, you get the results, a Voting Options button to take you back - and you get another 'View Results' option, even though that's where you already are.
As far as I remember this is also a bug in SMF, too.
174
Plugins / Which next? [Poll]
« on March 30th, 2012, 06:57 PM »
OK, so I've officially had enough of bug wrangling for the moment, having spent my afternoon wrestling with things unsuccessfully.
So, which plugin should I write next?
So, which plugin should I write next?
176
Archived fixes / Can't edit or remove thoughts from main page in SVN
« on March 29th, 2012, 01:44 AM »
I can edit and remove any thoughts (being an admin here) from the front page, but on an SVN copy I only ever seem to be able to get the 'reply' button to appear.
Digging through the code, it seems to be testing for data-self to be added but the SVN Welcome template does not seem to have this, or maybe it's late and I'm just missing something fundamental >_>
Digging through the code, it seems to be testing for data-self to be added but the SVN Welcome template does not seem to have this, or maybe it's late and I'm just missing something fundamental >_>
177
I knew it was being discussed but this is the first time I've ever seen it mentioned.
http://www.theregister.co.uk/2012/03/26/http_version_2/
Integrating Websockets is not a bad idea (provided that it's implemented sanely and harmonises the multiple drafts in play), not quite so sure about Google SPDY, but it's not inherently bad IMO.
Thoughts?
http://www.theregister.co.uk/2012/03/26/http_version_2/
Integrating Websockets is not a bad idea (provided that it's implemented sanely and harmonises the multiple drafts in play), not quite so sure about Google SPDY, but it's not inherently bad IMO.
Thoughts?
178
Features / Users Online Today
« on March 23rd, 2012, 01:58 AM »
Some of you may have noticed that Users Online Today has sprouted here, on the main wedge.org index, and on the http://wedge.org/do/boards/ board index.
You may be disappointed, or relieved[1] to note that this is NOT a core feature of Wedge. It is in fact a plugin, so we're getting to test plugin functionality here as well.
For more details, please see the following post where I first mentioned it: http://wedge.org/pub/plugins/6929/personal-plugin-showcase-yes-i-m-an-attention-grabbing-git/msg268391/#msg268391
I currently have something like 15 plugins for Wedge in various stages of development, and more will follow in due course (and in that board, really, is where more information will be found)
You may be disappointed, or relieved[1] to note that this is NOT a core feature of Wedge. It is in fact a plugin, so we're getting to test plugin functionality here as well.
For more details, please see the following post where I first mentioned it: http://wedge.org/pub/plugins/6929/personal-plugin-showcase-yes-i-m-an-attention-grabbing-git/msg268391/#msg268391
I currently have something like 15 plugins for Wedge in various stages of development, and more will follow in due course (and in that board, really, is where more information will be found)
| 1. | Depending on your view of such things, of course. |
179
Bug reports / Board order issues
« on March 22nd, 2012, 12:27 PM »
I'm really not sure why this is the case but it needs fixing. Some of these boards I'm about to mention are not public visible.
Board index lists Public Area category as:
- The Pub
FAQs
Features
Bug reports
Plugins
Off-topic
SMF
- Dev Blog
- Salvaged Topics
- Salvaged Board
Going to The Pub itself also shows its sub-boards correctly, as does the view in Boards & Categories. But if I view the Public Area category as a whole[1] I get a very different order.
- Salvaged Topics
- Salvaged Board
- The Pub
FAQs
Off-topic
Features
SMF
Plugins
Bug reports
- Dev Blog
Now, I'm not 100% sure but for each level of hierarchy, that would be consistent with MyISAM ordering rather than correct ordering (i.e. order of creation).
I'm not sure how best to fix this. Part of me says we could just fix it by using ORDER BY board_order but I have a feeling we might be better served using Mark Rose's suggestion and applying the board order to the primary key (so that we end up with id_board as a UNIQUE, but board_order, id_board as physical primary key, so that when it's reordered, regardless of whether that's MyISAM[2] or InnoDB[3] it works properly)
Board index lists Public Area category as:
- The Pub
FAQs
Features
Bug reports
Plugins
Off-topic
SMF
- Dev Blog
- Salvaged Topics
- Salvaged Board
Going to The Pub itself also shows its sub-boards correctly, as does the view in Boards & Categories. But if I view the Public Area category as a whole[1] I get a very different order.
- Salvaged Topics
- Salvaged Board
- The Pub
FAQs
Off-topic
Features
SMF
Plugins
Bug reports
- Dev Blog
Now, I'm not 100% sure but for each level of hierarchy, that would be consistent with MyISAM ordering rather than correct ordering (i.e. order of creation).
I'm not sure how best to fix this. Part of me says we could just fix it by using ORDER BY board_order but I have a feeling we might be better served using Mark Rose's suggestion and applying the board order to the primary key (so that we end up with id_board as a UNIQUE, but board_order, id_board as physical primary key, so that when it's reordered, regardless of whether that's MyISAM[2] or InnoDB[3] it works properly)
| 1. | Also, why doesn't the header on the board index link to the category itself? I think it really should. |
| 2. | MyISAM orders by creation, but there's a physical ALTER TABLE to reorder it in the manage boards code. |
| 3. | InnoDB orders by primary key, so making the board_order the first half of the primary key, it will automatically be sorted into order. |
180
Development blog / Aftermath of the Great Deployment
« on March 21st, 2012, 04:45 PM »
So, yeah, we're about 5 days in after finally moving wedge.org to actually running Wedge, and I'd like to take a bit of time to just go over how I (at least) see it.
First of all, thank you to everyone who's stopped by, especially if you've stopped by and really loved what Nao's done with the default theme. I had the joy of seeing it ahead of time, so the surprise wasn't quite as big on me, but it was really great seeing it, especially being able to watch it grow.[1]
Also, a big thanks to everyone that's put up with the bugs we've had. As you can probably imagine, Wedge is still a living breathing work, it's still growing, still changing, as you can see from the New Revs thread every time we commit.
Because of that, and because we'd never deployed it in a public way beforehand, there was a lot of stuff that had never been thoroughly tested. So it was a matter of a little disappointment for us that things were buggy - and the list has seemed to be pretty huge in some respects - but overall, I think it's turned out pretty well. The bulk of the bugs are more annoying than serious, and I don't believe any of them are privacy or security related, either, so that's something to be quite happy about, really.
The funny thing is that there's a lot of things that I doubt people have really noticed yet. The theme's the most obvious change, and the way there are icons and animations and things, but I would encourage people to dig a little deeper. There are all sorts of less obvious changes afoot. You might just be surprised at what you find ;)
As ever, if there's anything you like or don't like, tell us! We can't fix things if we don't know they're broken, and if there's a better way of doing something than we're currently doing, tell us that too - the end of it, we want to turn out something truly awesome, and while Wedge is a long way down that road, there's still plenty more to do yet.
Sadly, we have not yet turned the corner that marks the end of 'new features' which would otherwise put us on the road to public releases. Things are still a bit too raw for that, still too many things not yet polished, or finished or tested to destruction. But we've certainly passed the biggest milestone: we've finally moved our own site to our own platform. With that, the single greatest hurdle has been passed; we get to test things in a real environment, we got to thoroughly test the importer, and we get to properly share with you what we've been doing all this time.
So, really, thank you all for bearing with us while we got here, and while we deal with the immediate things we've seen from it - and you'll be able to see the rough edges get polished, things get tweaked, things get added or removed. It's been a long road thus far, and it's not nearly over yet - but you're certainly welcome to join us for the ride :)
First of all, thank you to everyone who's stopped by, especially if you've stopped by and really loved what Nao's done with the default theme. I had the joy of seeing it ahead of time, so the surprise wasn't quite as big on me, but it was really great seeing it, especially being able to watch it grow.[1]
Also, a big thanks to everyone that's put up with the bugs we've had. As you can probably imagine, Wedge is still a living breathing work, it's still growing, still changing, as you can see from the New Revs thread every time we commit.
Because of that, and because we'd never deployed it in a public way beforehand, there was a lot of stuff that had never been thoroughly tested. So it was a matter of a little disappointment for us that things were buggy - and the list has seemed to be pretty huge in some respects - but overall, I think it's turned out pretty well. The bulk of the bugs are more annoying than serious, and I don't believe any of them are privacy or security related, either, so that's something to be quite happy about, really.
The funny thing is that there's a lot of things that I doubt people have really noticed yet. The theme's the most obvious change, and the way there are icons and animations and things, but I would encourage people to dig a little deeper. There are all sorts of less obvious changes afoot. You might just be surprised at what you find ;)
As ever, if there's anything you like or don't like, tell us! We can't fix things if we don't know they're broken, and if there's a better way of doing something than we're currently doing, tell us that too - the end of it, we want to turn out something truly awesome, and while Wedge is a long way down that road, there's still plenty more to do yet.
Sadly, we have not yet turned the corner that marks the end of 'new features' which would otherwise put us on the road to public releases. Things are still a bit too raw for that, still too many things not yet polished, or finished or tested to destruction. But we've certainly passed the biggest milestone: we've finally moved our own site to our own platform. With that, the single greatest hurdle has been passed; we get to test things in a real environment, we got to thoroughly test the importer, and we get to properly share with you what we've been doing all this time.
So, really, thank you all for bearing with us while we got here, and while we deal with the immediate things we've seen from it - and you'll be able to see the rough edges get polished, things get tweaked, things get added or removed. It's been a long road thus far, and it's not nearly over yet - but you're certainly welcome to join us for the ride :)
| 1. | The only sad part for me was that we'd decided to keep it under wraps so even when there were screenshots of stuff I was working on, they were all using the existing 'Wine' skin, which you can use here if you want, just head to Profile > Skin Selector. |