Recent Posts
1
Features / Re: New revs
« Today at 06:05 PM by Nao »rev 2125 -- all of the rest...
(8 files, 5kb)
* Made the Chrome for Mobile fix more generic, by applying it to the universal selector. All elements need it really, even though 99% of the issues stem from table cells (which is also why 99% of all problematic websites in Chrome 25+ are forums... Eh.) (index.css)
+ Added ability to easily restyle mini-menu fonts. (index.css)
! Fixed PM contact list box breaking layout in smaller screens. (editor.css)
* Refactored CSS filename generation, to something more acceptable. To me, at least... It basically calls array_filter twice instead of once (to deal with 0's, see below), and avoids doing a useless preg_replace. Plus, the code is shorter this way. (Subs-Cache.php)
! Fixed the odd '0-guest' CSS filenames generated when serving content to a bot, or any client that doesn't provide an actual browser or OS name. (Subs-Cache.php)
! Fixed hardcoded text in the custom profile area. And other things. (ManageMemberOptions.php, Admin.template.php, ManageSettings.language.php)
* Translation. Changed "entrée" to "saisie" as translation for "input", as it suddenly sounded better to me... (ManageSettings.french.php)
* No biggie, but I think that an strpos() is faster than a substr_count()... (Subs-Template.php)
(8 files, 5kb)
* Made the Chrome for Mobile fix more generic, by applying it to the universal selector. All elements need it really, even though 99% of the issues stem from table cells (which is also why 99% of all problematic websites in Chrome 25+ are forums... Eh.) (index.css)
+ Added ability to easily restyle mini-menu fonts. (index.css)
! Fixed PM contact list box breaking layout in smaller screens. (editor.css)
* Refactored CSS filename generation, to something more acceptable. To me, at least... It basically calls array_filter twice instead of once (to deal with 0's, see below), and avoids doing a useless preg_replace. Plus, the code is shorter this way. (Subs-Cache.php)
! Fixed the odd '0-guest' CSS filenames generated when serving content to a bot, or any client that doesn't provide an actual browser or OS name. (Subs-Cache.php)
! Fixed hardcoded text in the custom profile area. And other things. (ManageMemberOptions.php, Admin.template.php, ManageSettings.language.php)
* Translation. Changed "entrée" to "saisie" as translation for "input", as it suddenly sounded better to me... (ManageSettings.french.php)
* No biggie, but I think that an strpos() is faster than a substr_count()... (Subs-Template.php)
2
Features / Re: New revs
« Today at 05:42 PM by Nao »rev 2124 -- feel free to revert if not to your taste..? I just felt like doing that, and liked it enough to commit...
(11 files, 7kb)
* Refactored action array a bit more, inspired by Pete's work... Aligned all entries to make them more readable (well, if your tab size is 4 spaces, as should be...), converted all array('Function') to just 'Function' (it only takes an extra line to account for this, and is probably faster due to not having to create the array structures), shortened verificationcode action name to fit the tab rewrite, converted Boards and Logout actions to strings (they didn't need to be in an array in the first place), and renamed several functions to match their container file when it made sense. Phew... Saves nearly 500 bytes out of the total index file size, so it's all good. (index.php, Admin.php, Groups.php, Mailer.php, ManageSettings.php, ModerationCenter.php, PersonalMessage.php, PostModeration.php, Subs-Editor.php, Themes.php, VerificationCode.php)
! Commenazi -- fixed a file containing a comment an accent encoded in ISO-8859-1. (ManageSettings.php)
(11 files, 7kb)
* Refactored action array a bit more, inspired by Pete's work... Aligned all entries to make them more readable (well, if your tab size is 4 spaces, as should be...), converted all array('Function') to just 'Function' (it only takes an extra line to account for this, and is probably faster due to not having to create the array structures), shortened verificationcode action name to fit the tab rewrite, converted Boards and Logout actions to strings (they didn't need to be in an array in the first place), and renamed several functions to match their container file when it made sense. Phew... Saves nearly 500 bytes out of the total index file size, so it's all good. (index.php, Admin.php, Groups.php, Mailer.php, ManageSettings.php, ModerationCenter.php, PersonalMessage.php, PostModeration.php, Subs-Editor.php, Themes.php, VerificationCode.php)
! Commenazi -- fixed a file containing a comment an accent encoded in ISO-8859-1. (ManageSettings.php)
3
Features / Re: New revs
« Today at 04:24 AM by Arantor »(14 modified, 1 deleted, crap I forgot one as Packages-Get should have died too, I'm blaming the rum, 3KB)
Revision: 2123
Author: arantor
Date: 21 May 2013 03:23:14
Message:
! Unnecessary extra globals. (Subs-Cache.php, Subs-Captcha.php)
! There's no need for the admin inclusion when in short order we proceed to run a hook which can actually *do* something anyway. (Admin.php)
! We have loadSource, let's use it. And just for kicks, since a bunch of array('file', 'function') had the same things, I made it into just array('file'). Could even have gone really mad and made it a string but that seemed like one step too far, you know? After all, I only wanted to get shot of the use of $sourcedir, everything else just sort of 'happened'. (index.php)
! I finally realised that there really was no need to keep the random stuff around for the old package manager, if I wanted it, I had SVN but really there wasn't much I thought I might have found useful, so removed a bunch of stuff. There are still tendrils elsewhere that haven't been cleaned up yet, but I'm getting to it. (Admin.php, PackageGet.php, Security.php, Subs-Package.php, Packages.template.php, language files: Admin, Errors, Packages, Who)
----
Modified : /trunk/Sources/Admin.php
Modified : /trunk/Sources/Security.php
Modified : /trunk/Sources/Subs-Cache.php
Modified : /trunk/Sources/Subs-Captcha.php
Modified : /trunk/Sources/Subs-Package.php
Deleted : /trunk/Themes/default/Packages.template.php
Modified : /trunk/Themes/default/languages/Admin.english.php
Modified : /trunk/Themes/default/languages/Admin.french.php
Modified : /trunk/Themes/default/languages/Errors.english.php
Modified : /trunk/Themes/default/languages/Errors.french.php
Modified : /trunk/Themes/default/languages/Packages.english.php
Modified : /trunk/Themes/default/languages/Packages.french.php
Modified : /trunk/Themes/default/languages/Who.english.php
Modified : /trunk/Themes/default/languages/Who.french.php
Modified : /trunk/index.php
Revision: 2123
Author: arantor
Date: 21 May 2013 03:23:14
Message:
! Unnecessary extra globals. (Subs-Cache.php, Subs-Captcha.php)
! There's no need for the admin inclusion when in short order we proceed to run a hook which can actually *do* something anyway. (Admin.php)
! We have loadSource, let's use it. And just for kicks, since a bunch of array('file', 'function') had the same things, I made it into just array('file'). Could even have gone really mad and made it a string but that seemed like one step too far, you know? After all, I only wanted to get shot of the use of $sourcedir, everything else just sort of 'happened'. (index.php)
! I finally realised that there really was no need to keep the random stuff around for the old package manager, if I wanted it, I had SVN but really there wasn't much I thought I might have found useful, so removed a bunch of stuff. There are still tendrils elsewhere that haven't been cleaned up yet, but I'm getting to it. (Admin.php, PackageGet.php, Security.php, Subs-Package.php, Packages.template.php, language files: Admin, Errors, Packages, Who)
----
Modified : /trunk/Sources/Admin.php
Modified : /trunk/Sources/Security.php
Modified : /trunk/Sources/Subs-Cache.php
Modified : /trunk/Sources/Subs-Captcha.php
Modified : /trunk/Sources/Subs-Package.php
Deleted : /trunk/Themes/default/Packages.template.php
Modified : /trunk/Themes/default/languages/Admin.english.php
Modified : /trunk/Themes/default/languages/Admin.french.php
Modified : /trunk/Themes/default/languages/Errors.english.php
Modified : /trunk/Themes/default/languages/Errors.french.php
Modified : /trunk/Themes/default/languages/Packages.english.php
Modified : /trunk/Themes/default/languages/Packages.french.php
Modified : /trunk/Themes/default/languages/Who.english.php
Modified : /trunk/Themes/default/languages/Who.french.php
Modified : /trunk/index.php
4
Features / Re: Splitting a topic, keeping the origin
« Today at 01:04 AM by xrunner »I would tend to agree that it would be useful. Many times trying to do a good split is not always easy if a lot of posts have accumulated. Also the rumblings and so on leading up to the reason for the split are contained in the posts that would be left in the original topic - i.e. you can't always do a perfect split anyway - so I would lean toward this being a useful way to see how the split topic came to be.
5
Features / Re: Splitting a topic, keeping the origin
« Yesterday at 11:26 PM by Arantor »Yeah, that's something I hadn't quite figured out what to do with.
It's one of those things that will likely be useful to a lot of forums and a pain in the backside to a lot of others - but I think it's useful enough for the bulk that it be a feature included.
It's one of those things that will likely be useful to a lot of forums and a pain in the backside to a lot of others - but I think it's useful enough for the bulk that it be a feature included.
6
Features / Re: Splitting a topic, keeping the origin
« Yesterday at 11:06 PM by Johnny54 »I am a moderator and split topics quit often to get a off-topic discussion in there own topic.
So I don't like having a non deletable link to the original topic in the splitted topic simply because there's no connection (off-topic).
If this option can be chosen at splitting, and/or the entire option be switched off by the admin. then it is oke.
So I don't like having a non deletable link to the original topic in the splitted topic simply because there's no connection (off-topic).
If this option can be chosen at splitting, and/or the entire option be switched off by the admin. then it is oke.
8
Features / Splitting a topic, keeping the origin
« Yesterday at 08:52 PM by Arantor »OK, so this came up on sm.org earlier and a topic that was split ended up losing some context because of it.
I wondered, then, if it would be of use to keep the origin topic in a split. In the newly split topic, keep a reference to the original topic and provide a link back, ideally not as part of the message body itself.
We have per-message data storage, it's no big deal to get that and stuff a link to the old topic inside the first post of the new one.
I figure that if it wasn't part of the message body, there's no way it could be accidentally deleted by a moderator.
Thoughts?
I wondered, then, if it would be of use to keep the origin topic in a split. In the newly split topic, keep a reference to the original topic and provide a link back, ideally not as part of the message body itself.
We have per-message data storage, it's no big deal to get that and stuff a link to the old topic inside the first post of the new one.
I figure that if it wasn't part of the message body, there's no way it could be accidentally deleted by a moderator.
Thoughts?
9
Features / Re: Permissions UI, latest experiment
« Yesterday at 02:35 AM by Farjo »"Question: if you can tick both allow and deny, which would logically take precedence? What would you expect it to do if you selected both?"
I would expect it to deny, as deny overrides all allows.
It's like a night club within which are many parties, all with their own invite list. If your name's on a list then you can get into the club. If your name is not on a list it means nothing - your name could be on a different list or it may be on none. However if you've been banned from the club then you won't get entry no matter how many lists your name's on.
So I agree with you getting rid of Disallow. Disallow is 1. not distinct enough to Deny to be clear and 2. misleading, because it doesn't disallow, it just doesn't allow. It's neutral, it does nothing.
"Well, it all came about because of the very fact that Disallow and Deny seem awfully close together. Hell, even just renaming it to Yes/No/Never would be an improvement."
Essentially what you have with your screen is Yes/Never/Neither - the latter being when both are unticked, and it's a truer representation of what's actually going on.
All your screen really needs is a good explanation at the top. And people who've never before seen Deny will assume it's new Wedge functionality :)
I would expect it to deny, as deny overrides all allows.
It's like a night club within which are many parties, all with their own invite list. If your name's on a list then you can get into the club. If your name is not on a list it means nothing - your name could be on a different list or it may be on none. However if you've been banned from the club then you won't get entry no matter how many lists your name's on.
So I agree with you getting rid of Disallow. Disallow is 1. not distinct enough to Deny to be clear and 2. misleading, because it doesn't disallow, it just doesn't allow. It's neutral, it does nothing.
"Well, it all came about because of the very fact that Disallow and Deny seem awfully close together. Hell, even just renaming it to Yes/No/Never would be an improvement."
Essentially what you have with your screen is Yes/Never/Neither - the latter being when both are unticked, and it's a truer representation of what's actually going on.
All your screen really needs is a good explanation at the top. And people who've never before seen Deny will assume it's new Wedge functionality :)
10
Off-topic / Re: Excuses for turniing off all Personal Messages
« Yesterday at 02:13 AM by Arantor »My reasoning to them was that spammers won't waste time PMing each member because it's very inefficient. Better to get an ad in a signature or post so it can be there for all to reach.
If that's the issue then all I ask is of them is honesty - not some lame excuse that spammers are PMing all the members.
About ~100 spammer membernames who just happened to have a birthday every day. Go figure. I told them about it and they turned it off but I never got any thanks for it.
Do you personally think that a declaration should be in the registration agreement by default that it's possible that personal messages could be read by Admins who have access to Cpanel? I.e., there is no inherent security of member's PMs?
