“her worries would have continued for some time if she did have [a Gravatar]. She’d have been desperately trying to remember every single site she’d put her email on to see whether her picture appeared there”
Actually, if all the sites where her avatar appeared used Gravatar, she would only have to worry about changing one image on gravatar.com and the new avatar (or lack thereof) would then be used on all those sites. Gravatar helps alleviate the situation you describe, not make it worse.
In any case I think it would be wrong to pimp Gravatar in the actual default theme. As it exists right now, having Gravatar in the core actually helps people who want to add their own avatar solution by supplying the core replaceable function and the calls to it in the rest of the code. By replacing that one function, a plugin author can remove Gravatar altogether and replace it with something else. Another bonus for me and everyone who volunteers support time is that by using Gravatar we avoid all the issues associated with supporting file uploads in the core.
I still believe that Gravatar should be supported by default in the core, but I think it would be inappropriate to push what is effectively advertising for the service to the front end (in the default theme) and force people to make modifications to remove it. That’s not the idea of having it there at all.
This was added to the 1.0.1 release that was just made.
Those folders are created with 0750 file permissions. If you can’t do anything with them then unless you have shell access you might have to ask your host to delete them and then you can re-create them yourself.
There are also changed files in BackPress which need to be copied over if you do it that way.
http://backpress.automattic.com/changeset?old_path=tags%2F1.0&new_path=tags%2F1.0.1
The meta bug was pure stupidity on my part. It only caused visible problems in the profile page somehow, but there you go.
Both that and the “get user by email” issue were enough to force a new release.
So you changed the URL that the installer suggested?
This should not be the case. I’ve isolated a bug that is causing this to happen. Looks like we are going to get a 1.0.1 release sooner rather than later!
I’m chasing this up with our i18n person today.
@vulvodynia
I thought those files would be automatically created. I’m chasing this up with our i18n person.
@chrishajer
Nice to know it was smooth for you!
Try replacing the function bb_since with this and let me know if translation works better for you then:
function bb_since( $original, $do_more = 0 ) {
$today = time();
if ( !is_numeric($original) ) {
if ( $today < $_original = bb_gmtstrtotime( str_replace(',', ' ', $original) ) ) // Looks like bb_since was called twice
return $original;
else
$original = $_original;
}
// array of time period chunks
$chunks = array(
( 60 * 60 * 24 * 365 ), // years
( 60 * 60 * 24 * 30 ), // months
( 60 * 60 * 24 * 7 ), // weeks
( 60 * 60 * 24 ), // days
( 60 * 60 ), // hours
( 60 ), // minutes
( 1 ) // seconds
);
$since = $today - $original;
for ($i = 0, $j = count($chunks); $i < $j; $i++) {
$seconds = $chunks[$i];
if ( 0 != $count = floor($since / $seconds) )
break;
}
$trans = array(
_n( '%d year', '%d years', $count ),
_n( '%d month', '%d months', $count ),
_n( '%d week', '%d weeks', $count ),
_n( '%d day', '%d days', $count ),
_n( '%d hour', '%d hours', $count ),
_n( '%d minute', '%d minutes', $count ),
_n( '%d second', '%d seconds', $count )
);
$print = sprintf( $trans[$i], $count );
if ( $do_more && $i + 1 < $j) {
$seconds2 = $chunks[$i + 1];
if ( 0 != $count2 = floor( ($since - $seconds * $count) / $seconds2) )
$print .= sprintf( $trans[$i + 1], $count2 );
}
return $print;
}
Hmmm, that’s lame. We should be using the plural translation functions there I think. I’ll look into it.
I recommend continuing to use the plugin. There are only a few cases where integration might work without it.
The logo and screenshot are old too.
If MySQL is a bottleneck, then memcached can help on small sites (some pages reduce to zero queries). In those cases though people generally don’t have access to memcached.
0.9 was – and is – a stable release. The poll was meant to find out the level of demand on each timeframe. I think there is probably a reasonable cohort asking for support up to the end of 2010, so I’m prepared to maintain security fixes on the 0.9 legacy branch until then – this will however rely on proactive reporting from users of 0.9 as I won’t really be using it at all within a couple of months.
People contributing peer support on these forums can make the choice personally whether or not they help out with 0.9 problems. I’ll also provide a link to the latest 0.9 “legacy” release on the downloads page (with warnings about discontinuing support).
So, I’m thinking that support continues until 31 December, 2010. Anyone particularly unhappy about that?
Poll added to first post.
Some people simply won’t be able to use 1.0 on shared hosts with several plugins. Their host will terminate their account for excessive resource use
WordPress is much more resource heavy than bbPress in this regard. This is the only place I think we might have a use for an output caching plugin like wp-super-cache.
For those not using the XML-RPC functionality (95% of you) I strongly recommend you delete xmlrpc.php immediately after install. Several of WordPress’s security issues over the years have been through that API.
Doing that will also disable the ability to receive ping-backs.
vs well over 100 files for bbPress 1.0
To be pedantic, I count 61 files without any plugins active on the front-page. Still not great for NFS.
You can always fork 0.9 and start you’re own forum product. Maybe call it ckPress
Eeek! I’d rather _ck_ stuck around here personally. She has earned the right to say pretty much whatever she likes about bbPress (not that I don’t appreciate your support frooyo).
Also, you can’t really tell how fast each forum is when they are all empty. You need to insert some data in there to get a real idea.
