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
2131
Features / Re: New revs
« on December 30th, 2012, 06:19 PM »
(Trying not to leave it too long between commits.)
(4 file, 2KB)
Revision: 1811
Author: arantor
Date: 30 December 2012 17:18:29
Message:
! Silly typo in the installer was not consistent with how everything else worked. (install.php)
! Disallow the new bans table from being dropped. (Class-DBPackages.php)
+ FTP class now has an upload facility that directly accepts a string rather than just demanding a local file. (Class-FTP.php)
! More updates of the manage-bans language file ready for translation. It is still a WIP though... (ManageBans.english.php)
----
Modified : /trunk/Sources/Class-DBPackages.php
Modified : /trunk/Sources/Class-FTP.php
Modified : /trunk/Themes/default/languages/ManageBans.english.php
Modified : /trunk/root/install.php
(4 file, 2KB)
Revision: 1811
Author: arantor
Date: 30 December 2012 17:18:29
Message:
! Silly typo in the installer was not consistent with how everything else worked. (install.php)
! Disallow the new bans table from being dropped. (Class-DBPackages.php)
+ FTP class now has an upload facility that directly accepts a string rather than just demanding a local file. (Class-FTP.php)
! More updates of the manage-bans language file ready for translation. It is still a WIP though... (ManageBans.english.php)
----
Modified : /trunk/Sources/Class-DBPackages.php
Modified : /trunk/Sources/Class-FTP.php
Modified : /trunk/Themes/default/languages/ManageBans.english.php
Modified : /trunk/root/install.php
2132
The Pub / Re: Viewing IP addresses and banning
« on December 29th, 2012, 01:03 PM »
-sigh- I wouldn't mind but all this was pretty much covered in the very first post.
But for those playing along at home, let's run through the logic.
All of this debate hinges on the point that moderators could be able to ban without being able to see IP addresses.
If you can't see an IP address, you should not be allowed to do IP bans for the simple reason that you are very likely going to ban someone you shouldn't. And giving IP ban powers to someone who can't see who they're shooting down with them is just plain daft. And any measures that involve allowing users to see who would be affected by a ban are also privacy encroaching (and thus defy the point of hiding IP addresses in the first place)
Which leads back to the original point in the original post: if you can ban, you should be able to see IP addresses because there is no legitimate time as far as I can see where you need to be able to see IP addresses and not be able to ban, and anything else just convolutes the process.
Remember: if I'm having trouble getting this fairly simple point across now, imagine what's going to happen when you come to it in 6 months and wonder who can see IP addresses, in a support topic.
But for those playing along at home, let's run through the logic.
All of this debate hinges on the point that moderators could be able to ban without being able to see IP addresses.
If you can't see an IP address, you should not be allowed to do IP bans for the simple reason that you are very likely going to ban someone you shouldn't. And giving IP ban powers to someone who can't see who they're shooting down with them is just plain daft. And any measures that involve allowing users to see who would be affected by a ban are also privacy encroaching (and thus defy the point of hiding IP addresses in the first place)
Which leads back to the original point in the original post: if you can ban, you should be able to see IP addresses because there is no legitimate time as far as I can see where you need to be able to see IP addresses and not be able to ban, and anything else just convolutes the process.
Remember: if I'm having trouble getting this fairly simple point across now, imagine what's going to happen when you come to it in 6 months and wonder who can see IP addresses, in a support topic.
2133
Archived fixes / Re: Unapproved posts gives error message
« on December 28th, 2012, 04:00 PM »2134
Plugins / Re: Attachment errors
« on December 28th, 2012, 12:53 AM »
Nope, I haven't found anything I actually want to upload anywhere.
It only kicks in *after* the attachment is made - the attachment appears to go fine, but it isn't purging properly afterwards. I'm still inclined to think this is actually a core bug not a plugin bug, though.
I've been busy working on code some more (and the commit is going to be crazy huge when it does land)
It only kicks in *after* the attachment is made - the attachment appears to go fine, but it isn't purging properly afterwards. I'm still inclined to think this is actually a core bug not a plugin bug, though.
I've been busy working on code some more (and the commit is going to be crazy huge when it does land)
2135
Plugins / Re: Attachment errors
« on December 27th, 2012, 05:27 PM »
I guess I can find something to upload somewhere...
2136
Plugins / Re: Attachment errors
« on December 27th, 2012, 04:55 PM »Also, in IE10 at least, disabling a plugin doesn't update the button. Maybe we should ensure the cache is refreshed...
2137
Off-topic / Re: Doctor Who
« on December 27th, 2012, 04:07 PM »
I will get around to watching it shortly, I'm sure... been busy the last couple of days and not nearly enough sleep.
2138
The Pub / Re: Getting ready for an alpha release: WeCSS/Wess improvements
« on December 24th, 2012, 07:48 PM »
I'm running on a lot of frustration right now, I'll admit.[1] It's possible I misinterpreted the code, however the way this is working, I don't think you'll find it's quite as protected as you think, and I suspect a profiler will suggest it is less efficient than you hoped.
| 1. | An argument over coding standards, plus spending half the day debugging the installer just to be able to test my own changes. |
2139
The Pub / Re: Getting ready for an alpha release: WeCSS/Wess improvements
« on December 24th, 2012, 07:04 PM »
So I'm looking at r1810 and I see there's a move of the instance to the getInstance function.
This is now less efficient in PHP 5.4, and I'm not even sure why it's been done, especially as it *deprotects* the singleton status of the object. There is a *reason* the instance is declared as a protected variable. (In PHP 5.4, the JIT compiler is faster when the properties of a class are predeclared, it doesn't have to maintain a hashmap the same way.)
There is absolutely no reason for the instance variable to be exposed outside of the class.
EDIT: I just noticed some of the PREG changes as mentioned. Now I might as well bookmark the preg_replace function in the manual for debugging purposes, because I'm never going to remember the ordering structure for *complex* cases that get processed into loops.
Come to think of it, why don't we strip all the comments left in the source while we're at it? It'd be faster to parse, right?
(Yes, it is faster to parse. But I still remember the fact that I had to create a flow chart to document a 600 line piece of code a few years ago to figure out how any of it worked after I removed all the comments.)
Oh, and dropping the latest SVN into my test site, even clearing the cache, it's still not working properly - the menu dropdowns have no background to them, there's no gradient in the background and other miscellaneous issues that generally result in the setup correctly handling different browsers.
This is now less efficient in PHP 5.4, and I'm not even sure why it's been done, especially as it *deprotects* the singleton status of the object. There is a *reason* the instance is declared as a protected variable. (In PHP 5.4, the JIT compiler is faster when the properties of a class are predeclared, it doesn't have to maintain a hashmap the same way.)
There is absolutely no reason for the instance variable to be exposed outside of the class.
Posted: December 24th, 2012, 06:49 PM
EDIT: I just noticed some of the PREG changes as mentioned. Now I might as well bookmark the preg_replace function in the manual for debugging purposes, because I'm never going to remember the ordering structure for *complex* cases that get processed into loops.
Posted: December 24th, 2012, 06:51 PM
Come to think of it, why don't we strip all the comments left in the source while we're at it? It'd be faster to parse, right?
(Yes, it is faster to parse. But I still remember the fact that I had to create a flow chart to document a 600 line piece of code a few years ago to figure out how any of it worked after I removed all the comments.)
Posted: December 24th, 2012, 06:53 PM
Oh, and dropping the latest SVN into my test site, even clearing the cache, it's still not working properly - the menu dropdowns have no background to them, there's no gradient in the background and other miscellaneous issues that generally result in the setup correctly handling different browsers.
2140
Bug reports / Re: in_array() expects parameter 2 to be array
« on December 24th, 2012, 06:36 PM »
We have no way to actually fix this without MAJOR changes as per my other topic.
It's nothing to do with the we object being initialised; this problem is architectural and predates the we object. It's only that the we object brings the symptoms to the fore.
As far as bypassing it goes strictly as a temporary measure, the checks at the front of allowedTo() could be expanded to whether we::$user['permissions'] is defined or not. It will hide the error message but won't fix the fact we're calling permissions tests before permissions are even loaded.
It's nothing to do with the we object being initialised; this problem is architectural and predates the we object. It's only that the we object brings the symptoms to the fore.
As far as bypassing it goes strictly as a temporary measure, the checks at the front of allowedTo() could be expanded to whether we::$user['permissions'] is defined or not. It will hide the error message but won't fix the fact we're calling permissions tests before permissions are even loaded.
2141
Features / Re: New revs
« on December 24th, 2012, 04:33 PM »
(3 files, 3KB)
Revision: 1809
Author: arantor
Date: 24 December 2012 15:32:28
Message:
! The installer *needs* the we object to *only* set up detect browser, not the entire user stuff, when for half the installer, the user won't even exist. (Class-System.php, install.php)
! Typo in one of the bbcodes. I really must make an editor for this. (install.sql)
! Some changes to the installer SQL, mostly that tie in to the ban changes. One new table, one new column in the members table, a couple of blank lines for consistency, and moving some of the settings into the new ban table as that's where the functionality will be driven from in due course. (install.php, install.sql)
----
Modified : /trunk/Sources/Class-System.php
Modified : /trunk/root/install.php
Modified : /trunk/root/install.sql
@ The new column is not related to the ban stuff but to a new feature I've talked about recently. Right now it's not a big deal, but it will be in the future, so best that we put it in now while we're doing other changes to the file.
Revision: 1809
Author: arantor
Date: 24 December 2012 15:32:28
Message:
! The installer *needs* the we object to *only* set up detect browser, not the entire user stuff, when for half the installer, the user won't even exist. (Class-System.php, install.php)
! Typo in one of the bbcodes. I really must make an editor for this. (install.sql)
! Some changes to the installer SQL, mostly that tie in to the ban changes. One new table, one new column in the members table, a couple of blank lines for consistency, and moving some of the settings into the new ban table as that's where the functionality will be driven from in due course. (install.php, install.sql)
----
Modified : /trunk/Sources/Class-System.php
Modified : /trunk/root/install.php
Modified : /trunk/root/install.sql
@ The new column is not related to the ban stuff but to a new feature I've talked about recently. Right now it's not a big deal, but it will be in the future, so best that we put it in now while we're doing other changes to the file.
2142
The Pub / Re: Getting ready for an alpha release: WeCSS/Wess improvements
« on December 24th, 2012, 01:40 PM »
That's the point, I DO feel like I have to justify myself.
I changed this one because I happened to be going through the file straight after commit and it was a few minutes work to figure out. wetem is a much bigger thing and I thought it was still being updated - I tend to mentally think of Class-CSS and wetem as being one entity even if they're actually not because it's all interrelated stuff that I didn't touch in code terms, pretty much at any point of their development.
It doesn't kill me not to see it - because I would have been jumping up and down by now over wetem - but we either need to do that for everything or nothing, and right now that's not where we are - and THAT's what's bugging me. The DB classes for example all have their scope declared explicitly, wedit has pretty much everything declared as public though I'm not sure it needs to be that way (nor am I sure it should be that way)
Ideally I'd prefer to see explicit declared scope because that's what's more correct in the grand scheme of things than a 'micro-optimisation' that probably does actually make it slower, not faster in the long run. (No-one's sure if removing 7 bytes per function declaration in a class will make it faster to parse and the difference is going to be so small it's almost impossible to actually benchmark.) However with the changes in PHP 5.4 to class definitions, it would not surprise me if it were actually faster to have that declared explicitly.
I changed this one because I happened to be going through the file straight after commit and it was a few minutes work to figure out. wetem is a much bigger thing and I thought it was still being updated - I tend to mentally think of Class-CSS and wetem as being one entity even if they're actually not because it's all interrelated stuff that I didn't touch in code terms, pretty much at any point of their development.
It doesn't kill me not to see it - because I would have been jumping up and down by now over wetem - but we either need to do that for everything or nothing, and right now that's not where we are - and THAT's what's bugging me. The DB classes for example all have their scope declared explicitly, wedit has pretty much everything declared as public though I'm not sure it needs to be that way (nor am I sure it should be that way)
Ideally I'd prefer to see explicit declared scope because that's what's more correct in the grand scheme of things than a 'micro-optimisation' that probably does actually make it slower, not faster in the long run. (No-one's sure if removing 7 bytes per function declaration in a class will make it faster to parse and the difference is going to be so small it's almost impossible to actually benchmark.) However with the changes in PHP 5.4 to class definitions, it would not surprise me if it were actually faster to have that declared explicitly.
2143
Bug reports / Re: in_array() expects parameter 2 to be array
« on December 24th, 2012, 01:32 PM »
Yes, it is.
See topic 7677 in the team board. It's been broken for a very long time.
See topic 7677 in the team board. It's been broken for a very long time.
2144
The Pub / Re: Getting ready for an alpha release: WeCSS/Wess improvements
« on December 24th, 2012, 01:15 PM »
*shrug* I was just trying to push for a little bit of consistency, sorry for wasting everyone's time with this.
2145
Features / Re: New revs
« on December 24th, 2012, 12:00 AM »
(5 files, 23KB)
Revision: 1808
Author: arantor
Date: 23 December 2012 22:59:36
Message:
! Yeah, so it's been annoying me that the mod buttons in topic didn't all have icons. Move topic still doesn't, because I haven't found a suitable icon, but merge does have an icon, so make a suitably sized version and use it. (index.member.css, small_merge.gif)
! Some more of the ban stuff, just to make it more digestible to manage, including the fairly complete language file for ban management. (mana.css, ban_items.png, ManageBans.english.php)
----
Modified : /trunk/Themes/default/images/admin/ban_items.png
Added : /trunk/Themes/default/images/small_merge.gif
Added : /trunk/Themes/default/languages/ManageBans.english.php
Modified : /trunk/Themes/default/skins/index.member.css
Modified : /trunk/Themes/default/skins/mana.css
Revision: 1808
Author: arantor
Date: 23 December 2012 22:59:36
Message:
! Yeah, so it's been annoying me that the mod buttons in topic didn't all have icons. Move topic still doesn't, because I haven't found a suitable icon, but merge does have an icon, so make a suitably sized version and use it. (index.member.css, small_merge.gif)
! Some more of the ban stuff, just to make it more digestible to manage, including the fairly complete language file for ban management. (mana.css, ban_items.png, ManageBans.english.php)
----
Modified : /trunk/Themes/default/images/admin/ban_items.png
Added : /trunk/Themes/default/images/small_merge.gif
Added : /trunk/Themes/default/languages/ManageBans.english.php
Modified : /trunk/Themes/default/skins/index.member.css
Modified : /trunk/Themes/default/skins/mana.css