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.
7396
Features / Re: New revs
« on October 16th, 2011, 10:36 AM »
rev 1114
(x files, 10kb - And thank you Pete for taking the time to specify your commit sizes now :))
* SEO optimizations. Shh!
* Converted all $scripturl to <URL> in the index template. There can be only one! (index.template.php)
- A couple more deletions related to OpenID. I believe openid_uri should be removed as well, and reinstalled by the plugin... If someone wants to convert an SMF install to Wedge, they could install Wedge, enable the OpenID plugin (if it exists), and then do the importing. (install.sql, upgrade.sql, xml/detailed-version.php)
(x files, 10kb - And thank you Pete for taking the time to specify your commit sizes now :))
* SEO optimizations. Shh!
* Converted all $scripturl to <URL> in the index template. There can be only one! (index.template.php)
- A couple more deletions related to OpenID. I believe openid_uri should be removed as well, and reinstalled by the plugin... If someone wants to convert an SMF install to Wedge, they could install Wedge, enable the OpenID plugin (if it exists), and then do the importing. (install.sql, upgrade.sql, xml/detailed-version.php)
7397
Features / Re: Bot logging
« on October 16th, 2011, 01:20 AM »
Or we could simply have an option in the admin area, disabled by default, to skip bots from these logs...
Considering that there's no 100% sure way of determining whether an IP is a bot, it'd make sense to leave it up to the admin to decide what they wanna do. But personally, I would certainly enable such an option. As long as one is aware that less hits doesn't translate to less visitors...
IIRC, when I used to use GA on noisen.com, my stats over there were MUCH lower, something like 5 times less than SMF's own account.
Separating spider hits from the rest would be suitable as long as we have an option to disable spider stat logging. But I wouldn't feel comfortable implementing that myself...
(Although I seem to remember I'd separated spiders from visitors in Noisen/Wedge.org code, but I don't remember what it was about, since the stats themselves do take bots into account...)
Considering that there's no 100% sure way of determining whether an IP is a bot, it'd make sense to leave it up to the admin to decide what they wanna do. But personally, I would certainly enable such an option. As long as one is aware that less hits doesn't translate to less visitors...
IIRC, when I used to use GA on noisen.com, my stats over there were MUCH lower, something like 5 times less than SMF's own account.
Separating spider hits from the rest would be suitable as long as we have an option to disable spider stat logging. But I wouldn't feel comfortable implementing that myself...
Posted: October 16th, 2011, 01:19 AM
(Although I seem to remember I'd separated spiders from visitors in Noisen/Wedge.org code, but I don't remember what it was about, since the stats themselves do take bots into account...)
7398
Features / Re: These two bytes may not matter to you...
« on October 16th, 2011, 01:15 AM »
Need to answer post above...
A quick one though.
The index template declares this in the header: <meta charset="utf-8">
However, SMF/Wedge already specifies the charset in the *HTTP headers*. So I boldly tried to remove the line and... It worked. However, when validating the page, while it's seen as valid, it adds a warning that I should be specifying the charset in the document itself, to help people view the files offline (save to disk).
It absolutely makes sense, I'd say. But I still don't see the point in having the charset specified twice.
So I'm wondering... Wouldn't it make sense to just skip specifying the charset in the http headers, and focus on the document itself?
The only drawback, AFAIK, is that anything before the charset declaration might be seen as ISO, but then again, I used to have '©' in the copyright line, and it wasn't correctly output, even though the headers declared the charset correctly. This is why I rewrote it to use (c) instead. So at this point, I'm not sure declaring charsets in http headers has any point... (?)
A quick one though.
The index template declares this in the header: <meta charset="utf-8">
However, SMF/Wedge already specifies the charset in the *HTTP headers*. So I boldly tried to remove the line and... It worked. However, when validating the page, while it's seen as valid, it adds a warning that I should be specifying the charset in the document itself, to help people view the files offline (save to disk).
It absolutely makes sense, I'd say. But I still don't see the point in having the charset specified twice.
So I'm wondering... Wouldn't it make sense to just skip specifying the charset in the http headers, and focus on the document itself?
The only drawback, AFAIK, is that anything before the charset declaration might be seen as ISO, but then again, I used to have '©' in the copyright line, and it wasn't correctly output, even though the headers declared the charset correctly. This is why I rewrote it to use (c) instead. So at this point, I'm not sure declaring charsets in http headers has any point... (?)
7399
Features / Bot logging
« on October 16th, 2011, 12:42 AM »
Hey guys.
Do you think it's all right to have smf take bots into account when calculating most online and similar stats?
I think it's unfair to take them into account. And misleading. But I fear that smf users switching to wedge would think that they lost all their visitors overnight and switch back :P
Do you think it's all right to have smf take bots into account when calculating most online and similar stats?
I think it's unfair to take them into account. And misleading. But I fear that smf users switching to wedge would think that they lost all their visitors overnight and switch back :P
7400
Features / Re: New revs - Public comments
« on October 15th, 2011, 09:03 AM »
That's because you didn't update your wedge_bbcode table ;)
7401
Features / Re: Birthday, calendar, plugin, core [VOTE NOW!]
« on October 15th, 2011, 12:08 AM »
Well, one rarely chooses to use the additional options so they wouldn't take much space when folded... etc.
7402
Features / Re: Birthday, calendar, plugin, core [VOTE NOW!]
« on October 14th, 2011, 11:48 PM »
Hmm... Then forget it ;)
7403
Features / Re: New revs
« on October 14th, 2011, 11:46 PM »
rev 1112
(7 files, 11kb)
* Replaced a few dozen $scripturl calls with <URL>, just to get the hang of it... It doesn't impact performance (positively or negatively), and it still requires checking all occurrences one by one (can't use <URL> inside a JSE call for instance), so I doubt I'll be converting everything... (Display.template.php, PersonalMessage.template.php, Who.template.php)
* Moved profile link replacements for guests to below the scripturl replacement code, to make sure we can use <URL> in profile links. (Subs-Template.php)
* Renamed 'last_msg' to 'last' in Quote links, if only because the 'quote' variable doesn't have '_msg' in it either. And it's shorter. (Post.php, Post2.php, Display.template.php)
! Fix for signature header size in profiles... Whatever. (sections.css)
(7 files, 11kb)
* Replaced a few dozen $scripturl calls with <URL>, just to get the hang of it... It doesn't impact performance (positively or negatively), and it still requires checking all occurrences one by one (can't use <URL> inside a JSE call for instance), so I doubt I'll be converting everything... (Display.template.php, PersonalMessage.template.php, Who.template.php)
* Moved profile link replacements for guests to below the scripturl replacement code, to make sure we can use <URL> in profile links. (Subs-Template.php)
* Renamed 'last_msg' to 'last' in Quote links, if only because the 'quote' variable doesn't have '_msg' in it either. And it's shorter. (Post.php, Post2.php, Display.template.php)
! Fix for signature header size in profiles... Whatever. (sections.css)
7404
Features / Re: Birthday, calendar, plugin, core [VOTE NOW!]
« on October 14th, 2011, 10:20 PM »
We could have the options in qr. And have the post page used as topic starter or non-JavaScript fallback (eg open link in new tab).
Dunno.
Dunno.
7405
Features / Re: Birthday, calendar, plugin, core [VOTE NOW!]
« on October 14th, 2011, 09:25 PM »
According to my threaded post at sm.org, it isn't a problem. I didn't make multiple qr forms though. Iirc I just moved the form as needed.
Btw what is the advantage of single post pages versus quick reply?
Btw what is the advantage of single post pages versus quick reply?
7406
Features / Re: Birthday, calendar, plugin, core [VOTE NOW!]
« on October 14th, 2011, 08:34 PM »
Re OpenID, my main issue with the OpenID code is that it only creates a 'subpar' account and requires more work on the user's side to get full privileges... It sucks. Any non-SMF/Wedge login system SHOULD give users the same privileges. They can be asked for a user name at registration time, whatever, all they need is a user name, their password is checked by Facebook is all... (Heck, if a password really needs to be generated, it can be done automatically by Wedge and sent to the Facebook e-mail or shown on screen or something....)
Re post form hooks, I suppose that'll be in the quick reply form as well...?
(I should get started on rewiring the quick reply form to below individual posts. Just need to figure out the best way of showing the link...)
Re post form hooks, I suppose that'll be in the quick reply form as well...?
(I should get started on rewiring the quick reply form to below individual posts. Just need to figure out the best way of showing the link...)
7407
Features / Re: Birthday, calendar, plugin, core [VOTE NOW!]
« on October 14th, 2011, 07:30 PM »
Take your time!
7408
Features / Re: Birthday, calendar, plugin, core [VOTE NOW!]
« on October 14th, 2011, 02:06 PM »
My opinion. Pm should be core. Memberlist I'm not sure. Print can be plugin although it's not important. Openid should be a plugin at the same level as Dragooon's Fb plugin, or simply gone if it's too complicated.
7409
Features / Re: Recycling board by default
« on October 14th, 2011, 08:18 AM »
I suppose it make more sense. And it allows one to see if a post was silently deleted.
7410
Features / Re: Template skeleton!
« on October 14th, 2011, 12:35 AM »
If it throws away a reference it shouldn't be throwing way the original. Unset isn't the same as setting the reference to zero pr something. That'd be a php bug.