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
3646
The Pub / Re: Number of 'online users'
« on April 22nd, 2012, 02:59 AM »You could have something like awstat which takes away the need for analytic's which will place cookies on your machine and the user has to accept them.
But awstats is just a waste of resources really, that's why people use analytic's it looks better and you get more info, without it consuming CPU and memory.
awstats parses the server access log, you know, that one that's maintained automatically by the webserver. That will continue to be produced. But the measures I'm proposing do not change the workload awstats has, nor does it change the information available to awstats. And trust me when I say it will reduce the server workload rather than increase it as you seem to think it will.
awstats only consumes any resources when you run it - the actual logging is done ANYWAY.
The good thing is, you are not saying.. Lets just remove any statistics of all guests so it reports non. I am sure that wouldn't be very nice.
So the options are that, you remove logging of guests actions meaning you will resort to using some other analytic's to provide the forum owner with the statistics if they so need to view them.
You can still figure out what is being viewed and what is popular. You still have topic view counts. You still have page views and choice of analytics.
What you would lose under my proposal is the ability to see 'right now' what some group of users 'right now' is seeing. And the mythical number of current users, which is skewed anyway for a bunch of reasons.
To be honest, there isn't really a down side to it.. I am just stating some points to an equation that can scope the field.
I mean, if possible you could even consider a plugin that is optional for the forum owner to track this kind of stuff within the forum.
Thank you for your meaningful input, it has just raised my blood pressure and confused everyone else.
3647
The Pub / Re: Number of 'online users'
« on April 22nd, 2012, 02:40 AM »I would like to argue against the fact of not knowing what guests are doing other than checking your server logs.
To you it might mean nothing. But to someone who is building a new website for its viewers, these statistics can be a asset to them.
We all know when a new website forms a lot of people like these numbers to look like people are active so they can get more activity on the site.
For a users point of view, if I logged on to a site and saw no activity, then I wouldn't be that interested.
Even if its says "guest" its still reporting some activity and gives the forum owner indication that there is users on the site. Even though they could be search engines and not actual people. But actual people may not know this, so could be good for them to have.
I like your idea of tracking through IP, so if that's the way to go then, you could add some kind of triggers that logs guest information based on what they are viewing, and also have maybe something that prunes these logs every so often so they don't fill up with trash.
3648
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.
3649
Features / Re: New revs - Public comments
« on April 22nd, 2012, 01:31 AM »
Oh, sorry, yeah, this is a mostly new install of Notepad++ which I forgot to reconfigure for LF only. When I first made the file I actually called it SplitTopics because it was just the stuff for SplitTopics.php (namely splitting and merging) but then I moved the topic-moving stuff in as well.
Thing is, it's totally related to managing topics, rather than topics in general, hence the name.
And thanks Aaron :) Certainly I find that I forget some things, notably dates and times which Nao's done a lot of work on, but for the rest of the things out there, I've got a fair idea of how I think it has to work to actually be meaningfully suited to i18n, and the biggest thing is tackling these awkward composite strings where a single line is made out of $txt['something'], $variable, $txt['something_else'], because that causes so many problems!
I am aware though that some of my moderation filters UI won't work properly in RTL because of the way it builds certain strings but I figure to a point we'll deal with that when there are people around who actually use an RTL language and can be best placed to tell us how it has to work. I'm not familiar enough with other languages to make that much of a call on it.
And actually while my native language doesn't require me to think outside the box in terms of phasing out composite strings and bringing in sprintf type strings, it does make me acute of how to cope with multiple languages at once, and I'm still not sure how exactly I want to handle English US vs English UK though I know I will want to do just that. (It makes me chuckle that phpBB has the exact opposite problem, having a strong British heritage)
Without wishing to sound like I'm taking a cheap shot at SMF (because I'm not), I'm a bit concerned how they're planning to solve this fundamental problem in the future. I can't remember when it was logged on the tracker, but AngelinaBelle (IIRC) logged an issue to deal with these composite strings, and the general approach was to create multiple forms of the relevant words for composite elements, so when you had some of these, you'd have multiple different words depending on the context, e.g. $txt['members_normative'] and $txt['members_declarative'] which in English would be the same string but would be different strings in other languages, I think it was talking about German.
But instead of doing that, I figured it's simply cleaner and easier (if very slightly slower) to create the complete string so you always have the term in relevant context.
Still, it's not like XenForo or other systems where we put it all in the DB...
Thing is, it's totally related to managing topics, rather than topics in general, hence the name.
And thanks Aaron :) Certainly I find that I forget some things, notably dates and times which Nao's done a lot of work on, but for the rest of the things out there, I've got a fair idea of how I think it has to work to actually be meaningfully suited to i18n, and the biggest thing is tackling these awkward composite strings where a single line is made out of $txt['something'], $variable, $txt['something_else'], because that causes so many problems!
I am aware though that some of my moderation filters UI won't work properly in RTL because of the way it builds certain strings but I figure to a point we'll deal with that when there are people around who actually use an RTL language and can be best placed to tell us how it has to work. I'm not familiar enough with other languages to make that much of a call on it.
And actually while my native language doesn't require me to think outside the box in terms of phasing out composite strings and bringing in sprintf type strings, it does make me acute of how to cope with multiple languages at once, and I'm still not sure how exactly I want to handle English US vs English UK though I know I will want to do just that. (It makes me chuckle that phpBB has the exact opposite problem, having a strong British heritage)
Without wishing to sound like I'm taking a cheap shot at SMF (because I'm not), I'm a bit concerned how they're planning to solve this fundamental problem in the future. I can't remember when it was logged on the tracker, but AngelinaBelle (IIRC) logged an issue to deal with these composite strings, and the general approach was to create multiple forms of the relevant words for composite elements, so when you had some of these, you'd have multiple different words depending on the context, e.g. $txt['members_normative'] and $txt['members_declarative'] which in English would be the same string but would be different strings in other languages, I think it was talking about German.
But instead of doing that, I figured it's simply cleaner and easier (if very slightly slower) to create the complete string so you always have the term in relevant context.
Still, it's not like XenForo or other systems where we put it all in the DB...
3650
Archived fixes / Re: Time offset (auto detect)
« on April 21st, 2012, 11:20 PM »
Ugh, that's the last time I rely on code posted on php.net :/
We have the browser's default language, yes. It's a starting point, perhaps, but I'd argue it's even more insane and effort intensive than using the list I already did, seeing how there's many different language codes, that's a couple of hundred in memory serves, and I *really* don't want to go through the codes to figure out what timezones might be applicable.
That also assumes that the timezone is right. What happens if, say, I take my laptop (which is set to en_GB) to America? All of a sudden it's now very wrong ;) That's an extreme and unlikely case but it's why you can't truly risk selective AJAX. But I wouldn't be opposed to two dropdowns, the second populated by the first (e.g. continent => region)
Mind you, what's actually so wrong with a single dropdown? I can put in a nice graphical map if that would help?
We have the browser's default language, yes. It's a starting point, perhaps, but I'd argue it's even more insane and effort intensive than using the list I already did, seeing how there's many different language codes, that's a couple of hundred in memory serves, and I *really* don't want to go through the codes to figure out what timezones might be applicable.
That also assumes that the timezone is right. What happens if, say, I take my laptop (which is set to en_GB) to America? All of a sudden it's now very wrong ;) That's an extreme and unlikely case but it's why you can't truly risk selective AJAX. But I wouldn't be opposed to two dropdowns, the second populated by the first (e.g. continent => region)
Mind you, what's actually so wrong with a single dropdown? I can put in a nice graphical map if that would help?
3651
The Pub / Re: The Cookie Law (in the UK at least)
« on April 21st, 2012, 11:14 PM »
Yup, there is a huge argument about it. There are a few things that bug me with respect to SMF/Wedge's implementation, and at this point I am specifically referring to the PHPSESSID cookie, NOT the logged in one.
1. The PHPSESSID cookie is normally a session cookie but due to odd behaviour it can also become a persistent cookie when you actually sign in, and its state becomes somewhat indeterminant at that point too.
2. There is no behaviour in SMF or Wedge that relies on the PHPSESSID cookie for remembering previous actions, no behaviour for managing or passing security tokens, nor maintaining tokens for security or for routing purposes.
3. It does, however, store a unique identifier for that session to identify the user. There are no consistency concerns, no accuracy concerns.
4. Its primary use is to uniquely identify a user for the purposes of seeing how many users are online at once. Because of the fact it is a full session, it also stores things like what user agent the user is reporting and also the URL they are visiting. This does have a concern regarding privacy since we have a uniquely identified session and tracking otherwise personal details.
So, yes, I agree that it does come under the definition of uniquely tracking a user. But there are concerns attached to it because it isn't used for any behaviour other than analytics. This puts it into the category of questionable.
And yes, it is a session cookie, in theory. Practice is somewhat different, though.
The cookie itself doesn't log that information, but it does tie it to a database record which does.Quote I think the best thing to do would be for you to stop taking this argument around and around and around in circles. Stop trying to justify something you don't know enough about, please, for the sake of everyone else trying to solve this. You're taking pieces of the advice out of context and trying to apply them to what you think is going on.
The facts remain thus: no matter how much you argue, the PHPSESSID cookie is not compliant based on the terms and wording of the law (as opposed to the layman's interpretation, which you're misquoting and taking out of context). That said, the law's terms are very vague and badly defined, so it's possible that the PHPSESSID cookie could be argued to be compliant but certainly the current implementation DOES NOT COMPLY IN FULL. Stop trying to pretend otherwise.
Now, that's not to say that it can't be made compliant, it certainly can, but some work is required to make that the case.
AND AGAIN: UNTIL WE HAVE A RESPONSE FROM THE ICO, THIS IS ALL HYPOTHETICAL ANYWAY.Quote from Nao on April 21st, 2012, 11:03 PM It's not entirely feasible, and it is also considered bad faith under the privacy and tracking considerations, which is the entire point of this law in the first place: to protect user privacy.
Do we actually *need* to track unique guests? Do we care how many 'guests' are online at once? Do we care how many 'unique guests' (given that's a figure that we don't really understand nor have any accuracy for) are online at once?
If we do care, we should push for using something like Google Analytics and do it that way (with all the cookie concerns that way), but if we don't care out of the box for 'unique guests', a figure I'm actually not that bothered with anyway, we could ditch it, be compliant out of the box by not using *any* cookies for guests at all, save some DB space by not tracking active numbers of guests as true sessions, make it a little faster by not performing queries for this sort of thing for guests, and just for fun, make it faster by saving bandwidth.
How important, really, is the number of 'maybe unique guests' to us?
1. The PHPSESSID cookie is normally a session cookie but due to odd behaviour it can also become a persistent cookie when you actually sign in, and its state becomes somewhat indeterminant at that point too.
2. There is no behaviour in SMF or Wedge that relies on the PHPSESSID cookie for remembering previous actions, no behaviour for managing or passing security tokens, nor maintaining tokens for security or for routing purposes.
3. It does, however, store a unique identifier for that session to identify the user. There are no consistency concerns, no accuracy concerns.
4. Its primary use is to uniquely identify a user for the purposes of seeing how many users are online at once. Because of the fact it is a full session, it also stores things like what user agent the user is reporting and also the URL they are visiting. This does have a concern regarding privacy since we have a uniquely identified session and tracking otherwise personal details.
So, yes, I agree that it does come under the definition of uniquely tracking a user. But there are concerns attached to it because it isn't used for any behaviour other than analytics. This puts it into the category of questionable.
And yes, it is a session cookie, in theory. Practice is somewhat different, though.
The cookie itself doesn't log that information, but it does tie it to a database record which does.
I think the best thing to do, if this doesn't apply is to adapt the cookie to fall directly under these terms.
I think that would be a better way, and would allow tracking to still exist. As in uniquely identify them.
The facts remain thus: no matter how much you argue, the PHPSESSID cookie is not compliant based on the terms and wording of the law (as opposed to the layman's interpretation, which you're misquoting and taking out of context). That said, the law's terms are very vague and badly defined, so it's possible that the PHPSESSID cookie could be argued to be compliant but certainly the current implementation DOES NOT COMPLY IN FULL. Stop trying to pretend otherwise.
Now, that's not to say that it can't be made compliant, it certainly can, but some work is required to make that the case.
AND AGAIN: UNTIL WE HAVE A RESPONSE FROM THE ICO, THIS IS ALL HYPOTHETICAL ANYWAY.
I still think we should try tracking guests through their ip if feasable ;)
Do we actually *need* to track unique guests? Do we care how many 'guests' are online at once? Do we care how many 'unique guests' (given that's a figure that we don't really understand nor have any accuracy for) are online at once?
If we do care, we should push for using something like Google Analytics and do it that way (with all the cookie concerns that way), but if we don't care out of the box for 'unique guests', a figure I'm actually not that bothered with anyway, we could ditch it, be compliant out of the box by not using *any* cookies for guests at all, save some DB space by not tracking active numbers of guests as true sessions, make it a little faster by not performing queries for this sort of thing for guests, and just for fun, make it faster by saving bandwidth.
How important, really, is the number of 'maybe unique guests' to us?
3652
The Pub / Re: The Cookie Law (in the UK at least)
« on April 21st, 2012, 10:33 PM »
One thing I will add... actually... there is an interesting point to be made here. Complying with the law as it seems to be, that means we can't issue the PHPSESSID cookie without permission. That means search engines won't give consent, and thus we don't have to worry about PHPSESSID for non-guests.
In *that* case, yes, we lose the accuracy of the 'number of online guests', but we actually gain performance and speed and stop having any PHPSESSID/SEO issues again ever to have to deal with.
From my perspective, I'm increasingly considering that a viable option - though I do note there is an exemption in there for cookies used for performance and tracking the number of users to balance load, and it's possible to argue that one with PHPSESSID. Until I get some guidance from the ICO, though, this is all largely hypothetical.
In *that* case, yes, we lose the accuracy of the 'number of online guests', but we actually gain performance and speed and stop having any PHPSESSID/SEO issues again ever to have to deal with.
From my perspective, I'm increasingly considering that a viable option - though I do note there is an exemption in there for cookies used for performance and tracking the number of users to balance load, and it's possible to argue that one with PHPSESSID. Until I get some guidance from the ICO, though, this is all largely hypothetical.
3653
Archived fixes / Re: Thoughts not display @ on initial post
« on April 21st, 2012, 10:28 PM »
Hence the 'refresh to interact' too ;)
3654
Plugins / Re: Light URL Plugin Maybe?
« on April 21st, 2012, 10:27 PM »
Given that a decade ago I was addicted to alcohol, I do not wish to get into any kind of substance abuse, and will be firmly discouraging suggestions of it.
3655
Archived fixes / Re: Thoughts not display @ on initial post
« on April 21st, 2012, 10:25 PM »
That's not a bug, that's exactly as designed.
3656
Archived fixes / Re: Time offset (auto detect)
« on April 21st, 2012, 10:25 PM »I just checked and there's only Africa/Cairo, which is not visible if you remove the Africa region manually...?
They're usually in 'Other', which is removed manually, right...?
Yes, but Windows (I only know of Windows) guesses my timezone automatically -- probably because of my language more than anything... French => France => Only one timezone? We're good to go. Heck, maybe it could be implemented as well here... i.e. take the 'big' countries that have only one timezone, and try to set them by default according to the language... (and/or with regards to the timezone evaluated through time offsets.)
...Or have a large list that is only loaded through Ajax and, while we're at it -- selects the 'most likely' timezone as default...
3657
Features / Re: New revs - Public comments
« on April 21st, 2012, 10:17 PM »
No, the move to 2.0 wasn't pretty, I wasn't involved but I was aware that 1.1 used numeric indexes and that there's even hints of that still in Wedge (e.g. the movetopic strings I moved yesterday, being numbered 1 through 4)
But either way, we're definitely moving in the right direction.
But either way, we're definitely moving in the right direction.
3658
Features / Re: New revs - Public comments
« on April 21st, 2012, 10:06 PM »
The thing about legacy strings is that they're sometimes used in composite form elsewhere e.g. $txt['something_' . $something] so while it might not be obviously used, it may end up being used anyway, as you mentioned, though some of them will just have to be tested to see if the string isn't used, heh.
The time offset stuff is deprecated, but I didn't remove it pending finishing (or reverting) the timezone stuff.
The time offset stuff is deprecated, but I didn't remove it pending finishing (or reverting) the timezone stuff.
3659
Features / Re: New revs - Public comments
« on April 21st, 2012, 08:47 PM »
Yes, it will. First thing it does is strtolower the string.
3660
The Pub / Re: The Cookie Law (in the UK at least)
« on April 21st, 2012, 06:58 PM »
Hmm, I didn't know whether or not it worked or what its gotchas were.
Regarding the one foible mentioned in the thread, there is a note that viewing threads 'should not be permitted' without a cookie. My interpretation of the ICO's directive is that viewing threads would come under the whole 'viewing information' thing and that you'd be able to do that for publicly-visible topics without having to have cookies enabled.
Regarding the one foible mentioned in the thread, there is a note that viewing threads 'should not be permitted' without a cookie. My interpretation of the ICO's directive is that viewing threads would come under the whole 'viewing information' thing and that you'd be able to do that for publicly-visible topics without having to have cookies enabled.