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 - Arantor
6061
The Pub / Re: Spell checker
« on October 8th, 2011, 07:33 PM »
Well, either we provide support for both in the core and do some magic to test it, or we move it all out of the core and let a plugin deal with it.
The greatest benefit about using plugins is that for stuff like this is that you get to isolate the functions and enhance them on their own without having to worry about everything else, which sounds ideal for this.
The greatest benefit about using plugins is that for stuff like this is that you get to isolate the functions and enhance them on their own without having to worry about everything else, which sounds ideal for this.
6062
Plugins / Re: Personal plugin showcase (yes, I'm an attention grabbing git)
« on October 8th, 2011, 07:00 PM »
OK, today's little project is two-fold. Firstly, it's a plugin that provides reCAPTCHA. I'm not a huge fan of it personally, but I know some people are.
Secondly, in order to make it actually work, I had to write add some hooks. Currently it's done as four hooks injected into the control_create_verification and relevant generic control template, and I'm not sure I can make it any smaller, either, given the nature of the different operations.
Still, having implemented the hooks, I'm just working on the admin panel before tackling the proper integration (and thus testing my hooks, heh) and I thought I'd share what that looks like. It's not much in itself, but it will show a few other... hints... relating to other changes in the admin panel.[1]
Secondly, in order to make it actually work, I had to write add some hooks. Currently it's done as four hooks injected into the control_create_verification and relevant generic control template, and I'm not sure I can make it any smaller, either, given the nature of the different operations.
Still, having implemented the hooks, I'm just working on the admin panel before tackling the proper integration (and thus testing my hooks, heh) and I thought I'd share what that looks like. It's not much in itself, but it will show a few other... hints... relating to other changes in the admin panel.[1]
| 1. | If you're wondering what I'm talking about, look at Admin > Configuration > Security and Moderation > Anti-Spam in 2.0 final or 2.0.1 and compare the difference. If you're still not clear what I'm getting at, post your questions/concerns here and I'll answer them. ;) |
6063
The Pub / Re: Spell checker
« on October 8th, 2011, 05:04 PM »
Well, it's theoretically cool but it has issues. Firstly, it's not that well supported - and in future it's going to have to be reworked as PHP is dropping pspell support in favour of something else that I can't remember right now.
There is one thing it does do, though, that's cute: if it's enabled it'll spell check when searching and offer possible suggestions, but that can be integrated through the plugin (and should be, since it's still a pspell dependence, and mostly people don't even notice when it doesn't do it)
There is one thing it does do, though, that's cute: if it's enabled it'll spell check when searching and offer possible suggestions, but that can be integrated through the plugin (and should be, since it's still a pspell dependence, and mostly people don't even notice when it doesn't do it)
6064
The Pub / Re: Spell checker
« on October 8th, 2011, 04:54 PM »My only user who needs it actually uses Word to type his posts and leverage spellchecking. I guess to each their own.
That's not so weird, actually. I know someone who always uses OpenOffice to write big emails out before copy/pasting them into their web-based email. It's just easier for them, apparently, though I have no idea *why* that's the case given that they're also a LiveJournal user and have no problem blogging directly into LJ.
6065
The Pub / Spell checker
« on October 8th, 2011, 03:49 PM »
Quick poll.
Who uses it? Any of your users use it?
What language(s) do you use it with? Does it work that well for you?
Just that I'm thinking about removing it given how most of the time it's built into browsers anyway now...
Also, I suppose there's no real reason why it couldn't be supported through a plugin instead of being a core feature...
Who uses it? Any of your users use it?
What language(s) do you use it with? Does it work that well for you?
Just that I'm thinking about removing it given how most of the time it's built into browsers anyway now...
Posted: October 8th, 2011, 03:45 PM
Also, I suppose there's no real reason why it couldn't be supported through a plugin instead of being a core feature...
6066
Features / Re: Aeva - Forum owned albums
« on October 7th, 2011, 10:21 PM »
That said, I would imagine access to be slightly different to a conventional album.
6067
Features / Re: New revs - Public comments
« on October 7th, 2011, 09:03 PM »
There is, of course, an ulterior motive for breaking the template up - injecting the calendar into its original place, from a plugin perspective.
I've been debating removing the spell checker. It's not unreliable but it is a bit fiddly to set up, and with it being on the client side (which will likely have the user's word customisations in, and so on) it seems less worth including.
I'd take the opportunity to rename it. Question: what happens with an unapproved post that then gets deleted?
Logging the empty skeleton is only useful if you can log the circumstances that got you there...
Ah, yes, that was my reason: I couldn't figure out a way to load the block/layer list in a single statement. As for loading things/not loading things in the block list, I couldn't figure out whether it would be cheaper to load everything and exit per template if we weren't doing anything, or load the list and remove items if we weren't going to use them, or only add them if we were going to (but in my head, adding an item is probably slightly more expensive than adding a single big list and exiting the function)
I don't think there is a good right way to do it...
I've been debating removing the spell checker. It's not unreliable but it is a bit fiddly to set up, and with it being on the client side (which will likely have the user's word customisations in, and so on) it seems less worth including.
I'd take the opportunity to rename it. Question: what happens with an unapproved post that then gets deleted?
Logging the empty skeleton is only useful if you can log the circumstances that got you there...
Ah, yes, that was my reason: I couldn't figure out a way to load the block/layer list in a single statement. As for loading things/not loading things in the block list, I couldn't figure out whether it would be cheaper to load everything and exit per template if we weren't doing anything, or load the list and remove items if we weren't going to use them, or only add them if we were going to (but in my head, adding an item is probably slightly more expensive than adding a single big list and exiting the function)
I don't think there is a good right way to do it...
6068
Features / Re: Aeva - Forum owned albums
« on October 7th, 2011, 08:51 PM »
I would image that attachments is sort of a forum-owned album...
6069
The Pub / Re: Replacing the recycle bin
« on October 7th, 2011, 08:44 PM »
This is way I brought it out here, because I wanted to see how people would react and what experiences other people have on the subject.
I'm good with users prefs - provided that it's easy and intuitive to change.
I'm good with users prefs - provided that it's easy and intuitive to change.
6070
Features / Re: New revs
« on October 7th, 2011, 03:26 PM »
Revision: 1071
Author: arantor
Date: 14:24:27, 07 October 2011
Message:
! Removed time/date format from being generally declared and instead made it per-language. Users can, of course, still set their own preference, but system-wide is almost invariably more dependent on language than on anything else. There is, for example, a different default for English vs French because English date/time tends to use 12 hour plus AM/PM, while French tends to use 24 hour, and this is reflected as such. I *think* I hit all the places necessary to make it work as expected, but it's possible things may be slightly buggy, I haven't had time to test everything fully for this. (install.sql, wedge_api.php, upgrade.php, Load.php, ManageNews.php, ManageSettings.php, ScheduledTasks.php, Subs.php, Profile.template.php, Language files: index, Install, ManageSettings, Profile)
----
Modified : /trunk/Sources/Load.php
Modified : /trunk/Sources/ManageNews.php
Modified : /trunk/Sources/ManageSettings.php
Modified : /trunk/Sources/ScheduledTasks.php
Modified : /trunk/Sources/Subs.php
Modified : /trunk/Themes/default/Profile.template.php
Modified : /trunk/Themes/default/languages/Install.english.php
Modified : /trunk/Themes/default/languages/Install.french.php
Modified : /trunk/Themes/default/languages/ManageSettings.english.php
Modified : /trunk/Themes/default/languages/ManageSettings.french.php
Modified : /trunk/Themes/default/languages/Profile.english.php
Modified : /trunk/Themes/default/languages/Profile.french.php
Modified : /trunk/Themes/default/languages/index.english.php
Modified : /trunk/Themes/default/languages/index.french.php
Modified : /trunk/other/install.sql
Modified : /trunk/other/tools/wedge_api.php
Modified : /trunk/other/upgrade.php
@ Incidentally I made sure to avoid an awkward situation that never actually caused a *problem* before but could have done. $txt['time_format'] was previously taken to be the language-dependent setting, but that very string is declared in the profile area. Fortunately, it was redeclared after $txt['time_format'] was used to determine date/time format, but as far as I'm concerned it shouldn't change both content and meaning during runtime like that, so I renamed the profile's string. (The help string has been left in because it is still used in the profile area)
Author: arantor
Date: 14:24:27, 07 October 2011
Message:
! Removed time/date format from being generally declared and instead made it per-language. Users can, of course, still set their own preference, but system-wide is almost invariably more dependent on language than on anything else. There is, for example, a different default for English vs French because English date/time tends to use 12 hour plus AM/PM, while French tends to use 24 hour, and this is reflected as such. I *think* I hit all the places necessary to make it work as expected, but it's possible things may be slightly buggy, I haven't had time to test everything fully for this. (install.sql, wedge_api.php, upgrade.php, Load.php, ManageNews.php, ManageSettings.php, ScheduledTasks.php, Subs.php, Profile.template.php, Language files: index, Install, ManageSettings, Profile)
----
Modified : /trunk/Sources/Load.php
Modified : /trunk/Sources/ManageNews.php
Modified : /trunk/Sources/ManageSettings.php
Modified : /trunk/Sources/ScheduledTasks.php
Modified : /trunk/Sources/Subs.php
Modified : /trunk/Themes/default/Profile.template.php
Modified : /trunk/Themes/default/languages/Install.english.php
Modified : /trunk/Themes/default/languages/Install.french.php
Modified : /trunk/Themes/default/languages/ManageSettings.english.php
Modified : /trunk/Themes/default/languages/ManageSettings.french.php
Modified : /trunk/Themes/default/languages/Profile.english.php
Modified : /trunk/Themes/default/languages/Profile.french.php
Modified : /trunk/Themes/default/languages/index.english.php
Modified : /trunk/Themes/default/languages/index.french.php
Modified : /trunk/other/install.sql
Modified : /trunk/other/tools/wedge_api.php
Modified : /trunk/other/upgrade.php
@ Incidentally I made sure to avoid an awkward situation that never actually caused a *problem* before but could have done. $txt['time_format'] was previously taken to be the language-dependent setting, but that very string is declared in the profile area. Fortunately, it was redeclared after $txt['time_format'] was used to determine date/time format, but as far as I'm concerned it shouldn't change both content and meaning during runtime like that, so I renamed the profile's string. (The help string has been left in because it is still used in the profile area)
6071
Features / Re: request for reliable backup and restore function
« on October 7th, 2011, 03:00 PM »
Well, it's now academic: the backup feature is now actually gone. There are multiple scripts you can use to produce a backup.
6072
The Pub / Re: Replacing the recycle bin
« on October 7th, 2011, 02:07 PM »
Hmm, maybe 'never show inline deletions' could be a user preference, maybe.
6073
Off-topic / Re: quirksmode.js
« on October 7th, 2011, 01:53 PM »
Though sadly quite out of date :(
6074
The Pub / Replacing the recycle bin
« on October 7th, 2011, 01:52 PM »
Something Nao and I are keen on doing is getting away from the current recycle bin. While it works, there are quite a few caveats to it, not least the fact that it wasn't even enabled by default. Though we did that, it's not elegant or nice, and it's something that would be better served by replacing it.
Now, the general approach that we're looking to adopt is actually to have the recycle bin folded into the normal view rather than this separate entity.
I'm posting this up here before any real implementation starts simply because it's quite high profile, as it were. This is more my take on how it should be done from a user perspective, the technical perspective is going to be pretty much the same whatever happens.
The first thing that occurs is how it should be shown on the page; I'm thinking that deleted replies would be shown one of two ways depending on the user and their preferences.
Normal users would just see a very short post, 'This post was deleted by its author / deleted by a moderator' (I think it should be quite clear which it was done by), and moderators/suitably privileged users would get that, plus a 'click here to see the full message' much as you do with users you're ignoring.
That way, even if a post is deleted, you're aware of it in the context of the thread, and it solves other problems such as if we ever implement threaded replies, it simplifies the logic about re-routing parents, not to mention leaving the conversation quite clearly structured and without so much disjoint attached to it.
The other matter is displayed deleted threads. I'm sensing we'd track whether a board had deleted threads or not, and have that as an option at the top of a board listing, whether to show deleted topics (assuming you're a moderator or similarly empowered user). The idea is that topics should be accessible but not immediately up in your face, at least not as visible as normal posts might be.
Does that make sense? Would it be worth providing mockups of how it might look?
Now, the general approach that we're looking to adopt is actually to have the recycle bin folded into the normal view rather than this separate entity.
I'm posting this up here before any real implementation starts simply because it's quite high profile, as it were. This is more my take on how it should be done from a user perspective, the technical perspective is going to be pretty much the same whatever happens.
The first thing that occurs is how it should be shown on the page; I'm thinking that deleted replies would be shown one of two ways depending on the user and their preferences.
Normal users would just see a very short post, 'This post was deleted by its author / deleted by a moderator' (I think it should be quite clear which it was done by), and moderators/suitably privileged users would get that, plus a 'click here to see the full message' much as you do with users you're ignoring.
That way, even if a post is deleted, you're aware of it in the context of the thread, and it solves other problems such as if we ever implement threaded replies, it simplifies the logic about re-routing parents, not to mention leaving the conversation quite clearly structured and without so much disjoint attached to it.
The other matter is displayed deleted threads. I'm sensing we'd track whether a board had deleted threads or not, and have that as an option at the top of a board listing, whether to show deleted topics (assuming you're a moderator or similarly empowered user). The idea is that topics should be accessible but not immediately up in your face, at least not as visible as normal posts might be.
Does that make sense? Would it be worth providing mockups of how it might look?
6075
Features / Re: New revs
« on October 7th, 2011, 01:32 PM »
Revision: 1069
Author: arantor
Date: 12:31:48, 07 October 2011
Message:
! Any pages that use the default settings construct now display a 'Your settings have been saved' message at the top of the screen after pressing save. (ManageServer.php, Admin.template.php, Admin language file)
----
Modified : /trunk/Sources/ManageServer.php
Modified : /trunk/Themes/default/Admin.template.php
Modified : /trunk/Themes/default/languages/Admin.english.php
@ Of course, pages that don't use the standard settings context structure probably don't *need* this anyway because it should be fairly obvious as you head between different areas (e.g. from a summary to an edit page, back to summary) that something has been changed.
Author: arantor
Date: 12:31:48, 07 October 2011
Message:
! Any pages that use the default settings construct now display a 'Your settings have been saved' message at the top of the screen after pressing save. (ManageServer.php, Admin.template.php, Admin language file)
----
Modified : /trunk/Sources/ManageServer.php
Modified : /trunk/Themes/default/Admin.template.php
Modified : /trunk/Themes/default/languages/Admin.english.php
@ Of course, pages that don't use the standard settings context structure probably don't *need* this anyway because it should be fairly obvious as you head between different areas (e.g. from a summary to an edit page, back to summary) that something has been changed.