 | newtonsongbird on Suggestions |
 | Kim Parsell on Core Contributor Handbook |
 | Lance Willett on We’re getting very close… |
 | Muhammad Abdi on Core Contributor Handbook |
 | Maor Chasen on We’re getting very close… |
I’m going to be upgrading the /extend/themes bbPress install to bring it up to the same level of bbPress where the ideas and plugins and support forums are. This is to allow the login cookies to integrate properly across the whole site.
This means that parts of the themes directory will be non-functional or broken for short periods of time as I track down issues with it. These times should be short and as minimal as possible.
I changed the default sort order from DESC to ASC on https://irclogs.wordpress.org/ Let me know if it is better or worse 
It was a bit hard to follow conversations by scrolling up.
It was quite nice to be able to instantly see the most recent chat at the top. However, I agree with being annoyed when scrolling down to find the start of a conversation and then scrolling back up to follow it. So good and bad.
link should be .ORG not .COM
Thanks. Edited.
I was ASC for a long time but switched because of following along during the day and refreshing often for the most recent comments. When there is an extensive dialogue, it’s a bit challenging either way — hard to say whether one is that much better. And when one is looking at it that much, it’s easy to toggle to choice.
I like it. It’s more natural for reading what I missed, which I think is what most people use it for.
Seems more intuitive this way.
Way better, thanks!
When looking at the source code for the IRC logs, I noticed this at the bottom of one the https://irclogs.wordpress.org/chanlog.php pages:
“
It looks like the footer file is not being included.
Thanks – fixed.
When clicking on a timestamp of a single message, the order reverts to DESC. Is it possible to apply the selected order there too?
Theme pages now have a little “Theme SVN” link in their FYI box. This just gives a link to the theme’s SVN, for people that want to use it.
This is something several of the theme reviewers asked for, and it fits with the long term goal of allowing some theme authors the ability to directly update themes via SVN instead of using the ZIP file uploader. Encouraging SVN use is a good thing, I think.
That just lists all the versions, ala the ‘Other Versions ยป’ link on plugin pages. Shame it can’t be WordPress.org-ified rather than a simple listing though.
That’s what it’s supposed to do. The theme SVN isn’t organized like the plugin SVN, with trunk and tags and such. It just has one directory for each theme version.
So it could be pulled into a WordPress themed page then…
Rich: Given it’s a SVN repo, I’m not really sure it’s possible to style it like WordPress.org. That aside, as it’s a SVN repo, it’s not designed to look like WordPress.org
On a site such as WordPress.org having unstyled pages like that is very un-professional. I still think the data could be pulled into a themed page, and even if it can’t I have seen better web front ends for SVN.
You can style the SVN web interface but I wouldn’t want to be the person writing the XSLT to do it – it’s not fun and you won’t make it look much better – I don’t see why it needs styling at all.
If you want to look at a pretty version of the code, then use the plugins Trac instead of browsing the directory via SVN. Or even better just use a proper SVN client.
The SVN repository isn’t really meant for browsing with your browser.
I think it would be worth a little XSLT to just put a note at the top, like “This is blah blah blah for the plugin’s page please see LINK or visit WordPress.org.”
This is welcome addition,
but I do think “trunk” folder should be given, that will be helpful when author modify theme code in response to theme-users support request.
Could we get the same thing for Plugins?
Plugins have had the SVN links in their Admin sections forever. Not sure it’s worth exposing them on the public side of things.
Not everyone has access to the admin section of every plugin.
I personally see SVN access for Plugins as more useful than for Themes. Every task is common between them however (Other than Theme review team stuff, but thats a not a normal front end task anyway). Allowing easier access to the SVN repo from the plugins page will help people who are not aware of SVN get into it at well, encourage them to use svn..
One of the first thing I do, and I’d hope other Plugin developers do, is open the plugins SVN repo and take a glance at the code, it’s what tells me if I’m going to atttempt to use it or not. That’d be my main use for it for Plugins (as well as for Themes).
erm plugins already have a link to the Development log in the FYI box. This was what I was referring to when I thought that the themes should match it.
Slightly off topic, but… It just occurred to me that the default vote for compatibility was for 3.1 at a time where it was not released. As much as I like the idea that one can vote on works/broken for the latest beta/RC, it seems to me that the vote should apply to the latest and greatest *released* WP version by default. (Or maybe it already is the case, in which case it’s not clear at all…)
i’m meaning for plugins, btw. But since you’re also worrying about that and I can only assume the same logic applies for themes, I figured I’d raise it here.
I added child theme support to the theme previewer for /extend/themes. The only child theme we have in there at present that I know of is this one: http://wordpress.org/extend/themes/mazeld , but now the preview works for it. Note that the parent theme of a child theme must also be in /extend/themes for this to work.
Shouldn’t we add a hint to a child theme that it’s a child theme? Maybe with a link/button to the parent theme?
Other than buddypress child themes? I think they were a previous exception?
Right, buddypress is a special case. Nothing has changed there.
Awesome, caise, pross and chip are still hashing out the guidelines with us to make them clear to the end user, will keep you in the loop of course.
Great stuff!
Found some buddypress themes that don’t work:
http://wordpress.org/extend/themes/unplugged
http://wordpress.org/extend/themes/buddypress-colours
It could probably fail more gracefully than now (white screen in the popup). Ideally it could just output “can’t find parent theme in our repository”.
…and the page title should read, “Are you my mother?”
You know how the keywords are used to find more of it’s like, would having the keyword child-theme be good to have ? to help find more of it’s like ?
Profiles now shows up-to-date info from the various trac installs once again. It won’t be up-to-the-minute, but it will be updating on a somewhat regular basis.
Example: http://profiles.wordpress.org/users/nacin
Great.
I still find it mildly amusing to have this at the bottom of my profile 
Tuesday June 28th, 2005 – Started a new topic in the WP.org support forums
Old Skool!
Mine doesn’t show my posts/threads from back in 2003. 
Could you explain the logic, or is it still not working right? The two most recent core Trac events it shows for me are one from today and one from March 25. I think I’ve opened about 80 tickets in the intervening time.
I didn’t back populate it. Didn’t seem to be a lot of point for all the effort that that would involve. It’ll update from today onwards.
It’s not that only entires are outdated, it’s display name too.
Note that that display name doesn’t show non English letters.
Milan: No, you just have that stuff put in for your name on BuddyPress, which is where it’s getting the name from:
http://buddypress.org/community/members/dimadin
The Profiles system is built on top of BuddyPress. So it shares a lot of stuff with that system.
When I can view the page… it still looks like I may be logged out in that section.
and when viewing the users directory there are links to view their last activity, but the link does not work. Links are coming up like this: http://profiles.wordpress.org//p/28633
Yes, I know. Didn’t say I fixed *everything* there.
LOL, but if I hadn’t have mentioned it…
but it also isn’t picking up every activity correctly, support forum posts specifically.
compare http://wordpress.org/support/profile/esmi
with http://profiles.wordpress.org/users/esmi
Actually, it is picking up activities correctly, it just isn’t doing what you are expecting it to do. It shows the last 10 activities of each different “type” of thing.
aha, that makes sense. I wondered how you were going to limit it.
Keep up the good work
Why initial layout with tabs was discontinued, I think it was more useful?
I agree with previous comments. Updating mechanisms seems freezed since April… Santa Claus has to work hard
The theme uploader tool now performs a much more extensive scan of uploaded themes and gives the results back in a list format to the uploader. Hopefully this will allow theme developers to more easily fix problems with their themes and reduce some of the load on the theme review team.
Example of the resulting output (truncated). Note that I intentionally used a failed theme here, to show an example of what that looks like.
And so on. This is an improvement over the previous method, which just stopped at the first error found and didn’t give a whole lot of useful output. While that old system is still in place (for now), this one is there in addition to it and will give all the results for any theme uploaded.
Lol. Are you guys actually receiving “I created a new theme” spam?
Not exactly, but the process for getting a theme approved was rather frustrating. The uploader checked for a number of basic conditions, but then only reported the first error. This made it hard to use because it became a process of upload, fix the problem, repeat until it goes through. And even then, the theme review requirements are somewhat more stringent. So I made this checker code to hit all the major points and provide a sort of feedback system, to allow theme authors to fix up their themes before uploading them. I wasn’t the first to do so, Pross had a fairly extensive checker system in place which I used parts of.
Could this be turned into a plugin for theme developers?
Great idea Otto. Being a theme developer, it will be nice to have a dev plugin to test all this before rolling out a new theme. Will Pross announce the plugin here once it’s available?
If he don’t, I will.
It’s actually available for use now. The Theme Reviewers make extensive use of it. As for if/when Pross plans to release the plugin, I don’t know. But, we actively encourage all Theme developers to make use of it!
Hopefully I’ll have something uploaded today
First version has been uploaded.
http://wordpress.org/extend/plugins/theme-check/
The output page is still pretty basic, but all the checks are run.
excellent, thanks for that.
While this is awesome, the screenshot you’ve attached shows wp_specialchars() and attribute_escape() being used in a backwards compatibility file.
Does this mean that themes are unable to use functions like this for backwards compatibility? (e.g. I can see a case where the theme author checks if esc_html() exists, and if not, maps to to wp_specialchars() )
Why support ancient insecure versions of WordPress?
Bingo!
Right now, we would (probably) make an exception for a Theme that provides awesome, thorough, and consistent backward-compatibility for a given WordPress version. Of course, I’ve yet to see such a Theme. Usually, it’s a one-off compatibility check.
This check system doesn’t currently prevent the upload from succeeding (although all the previous checks are still in place). I expect to make changes before making a “pass” on this a requirement. Discussion must ensue, and such.
I don’t think I’ve seen a theme that’s actually backwards compatible. Many will have a function_exists() check for things added in WP 2.3 then no compatibility check for something in 3.0.
These auto-search type scripts are ridiculous. I have a theme in review for weeks because of them.
I understand the deprecated function search, but why on earth are you blacklisting php functions like “base64_encode/decode”, fopen, and force use of comment-reply script? At least mark them as suspicious and make the theme reviewer check them manually for improper use, because some themes might actually have a good reason to use them.
This new tool doesn’t currently block anything from being uploaded. Feel free to discuss your concerns on the theme-reviewers mailing list: http://lists.wordpress.org/mailman/listinfo/theme-reviewers
Is the new theme uploader/reviewer available to download at all? It would be very helpful for themes that aren’t going to be uploaded to wordpress.org.
Are you going to improve the same way the plugin uploader. E.g.
a) screenshot page with no screenshots
b) recommended usage of all pages
c) using of deprecated functions (php or WP)
d) using of direct sql and not wp_query
e) not commenting functions
f) not using objects
g) using non translantable strings and not allowing translations at all
h) using very often problematic things like <?= in place of <?php echo
… and many other problems if they can be easily detected
No, there’s no plans to do plugin reviews in any way.
New and improved this morning, we have a two-fer.
First, on the extend plugin directory, you may notice some new pie chart fun on the stats tab for each plugin. This shows a percentage breakdown of the versions being actively used by that plugin’s users. Only slices greater than 1.0% are shown.
Secondly, since data kept in a box is not very useful, there’s a new API for getting this data. Usage is fairly obvious from just a simple example, which gets the version breakdown of one of my own plugins:
http://api.wordpress.org/stats/plugin/1.0/simple-facebook-connect?callback=demo
The callback parameter is optional, of course, and provided for people who want JSONP usage.
Note that the version data is relatively new, so we don’t have it for all plugins at present. It will get better as reporting continues. For those interested, it’s saving the total counts of the version numbers as reported by the plugin update-checks over the last week. Since the data at present is only from one day, it’s not very accurate.
Wow, AMAZING. You do all the fun stuff :p
Hmm couple of comments
1 – doesn’t show on http://wordpress.org/extend/plugins/simple-facebook-connect/
2 – does show here: http://wordpress.org/extend/plugins/eshop/ but the containing box seems to be wider that it should be
3 – multi coloured wheel looks nice but the key needs looking at, can it either list the last 2 versions + the most used version rather then what appears to be a random selection.
4 – http://api.wordpress.org/stats/plugin/1.0/eshop?callback=demo – about half way you’ll see mine appears to be messed up?
5 – are we able to get actual number of installs as well as the % ?
Other than, nice feature
Nice! This is going to really useful as the plugin developer!
Questions/notes:
(Also: are you working on a secret v500 of SFC that you haven’t released yet? )
my reply seems to have disappeared
1 – please check out: http://api.wordpress.org/stats/plugin/1.0/eshop?callback=demo for possible error (half way)
2 – containing box on the plugin page is a bit wide.
3 – the key is weird, can we have last couple of versions, plus most popular as defaults?
4 – it doesn’t actually appear on your plugin page…
5 – can we get access to actual number as well as the & ?
other than that looks good
that & should have been %
1. Not an error, although some cleanup may be in order. Somewhere, somebody is actually reporting that back to us as the version. I could limit it to numbers only, but then plugin that use something other than numbers in their versions might have a problem.
2. Intentional. Google’s chart API adds huge margins on either side of the stupid thing, so I put in new CSS rules to cut those off the sides and force it back into the right place. Looks good in Chrome, FF, and IE to me.
3. Not sure what “key” you mean here.
4. I see it just fine. Can you give me a link?
5. No.
2. It looks fine here:
http://wordpress.org/extend/plugins/wp-pagenavi/stats/
but it doesn’t seem to be applied on the main plugin page:
Also, I think it would make more sense to put it to the right of the History box, below the bigh bar graph.
Anyway, it’s really nice to have access to this information.
Yeah, I could put it there (and make it larger). My thinking was that the version information would be useful for users as well as for authors, to know how much usage a plugin got, or how much updating it got, etc.
Don’t regular users have access to the /stats tab too?
Yes, they do. I just didn’t think of it.
now shows on your plugin, wasn’t before.
the key – the ‘version number color block references’ on the right of the chart, if you look at yours for instance the biggest use by far is 0.21, yet that doesn’t even appear within the key.
The padding/margins around it are still making it stick out of the sidebar .
And I agree the stats tab would be a better place for it, allowing it to be bigger as well. – mine is multi coloured
You can get a rough estimate of total installs by looking at the API – find the version with the lowest % of installs, this probably corresponds to 1 install. Divide 100 by the % to get a total number of installs.
Notes:
@Otto: It seems Google Sitemap Generator breaks the API call:
http://api.wordpress.org/stats/plugin/1.0/google-sitemap-generator?callback=demo
Gary: if there’s no data, then it returns nothing. Remember that it’s only a couple of days old. I didn’t know what to return for a null result.
That plugin is currently the 4th most popular. It should have data associated with it by now.
Weird. I’ll check it out.
@Gary: This has now been fixed. Most plugins (over 11000) should be showing data now.
Thanks a lot, Otto. Pretty much what I’ve been asking for some time ago. Although it would be more valuable (for the plugin dev) if it would show the versions of those WP environments the plugin is currently installed on. Would make it easier to drop compatibility for versions of WP that aren’t used with the plugin anymore..
Anyways, thanks a lot!
Moved it to the stats tab. It does make more sense there.
Neat. It would be great if it could be moved a little higher, so that the ‘Active Versions’ header would have the same baseline as the ‘History’ header.
Another thing would be to make the headers the same size. Don’t know if that’s possible though.
looks a lot better, thanks.
It’d be nice if it was sorted by percentage rather than version number I think. For example, why is yellow listed in the key instead of light green? Light green is a larger section:
http://wordpress.org/extend/plugins/vipers-video-quicktags/stats/
For that matter, I think the pie should be sorted by percentage too maybe.
Actually, I was thinking about doing a reverse sort on the version numbers, since you typically only care about the latest versions anyway.
+1
*cough* I asked for that, but would also be nice if the most popular version was in the mix as well.
Awesome! Except for the fact that my plugin’s chart looks like a tasty lollipop. We really need to get these users upgraded…
The total # of active users would be a very valuable stat to show alongside downloads. Working on it?
Now that I look at it better, the percentages seem to represent slices of the total download count.
I was under the impression that an “active version” meant the number of users currently using that version on their site.
Nope. Download count is entirely separate. This is using the data from the plugin update-check.
So, on Front-end Editor when I hover over the largest slice, I get this:
1.9.1 28.141 (29.8%)
What does 28.141 represent?
The 28.141 is the actual percentage. The other number is different because I cut out everything less than 1.0%. So the total percentage I’m showing is actually less than 100%, which is then getting stretched to 100%.
Ok, thanks for the explanation. Would be great if it would display the actual number of users though.
Awesome feature, thanks for making this! FYI: it renders poorly in IE9 without compatibility mode enabled.
Thanks for doing this! Out of curiosity, is this based on all sites with each plugin it installed or activated?
The numbers come from the sites where it is activated, not just installed.
Very nice feature! I have noticed few things :
1/ There are usually way more active versions than plugins download. Does this mean that the download count only count the users that clicked on the download link and not the one that are directly installing the plugin from the WP built in installer?
2/ The askimet stats have apparently an issue : active versions for 2.4.0 : 28.26 (should miss some numbers).
1. I don’t understand what you mean. You can’t have more active versions than total downloads. And no, the download count includes direct downloads as well.
2. I see nothing wrong there. What do you mean?
1. If you do sum of active versions for some plugins, you will see that it is well above the total downloads… Sometimes 3 or 4 times…
2. Check out the askimet stats page, release 2.4.0 is active on 28.26, it should probably 28.261 or 28.262… It is just missing the trailing number.
Those are percentages, not raw counts. And it’s not missing the trailing number, the value is 28.260, so the zero doesn’t need to be shown.
There are two numbers, one is the percentage but the other one is a count, isn’t it? You have for each pie : the release number, the active version count and then between parenthesis, the percentage the active version count represents in the overall count, isn’t it? If this is the case, then the raw count for Askimet is wrong. It shows 28.26 (29,4%).
No, they’re both percentages.
I just don’t display any slice of the real pie smaller than 1%. The first number (the 28.26) is the actual percentage of the data. It’s the value you care about.
The second number (the 29.4%) is the percentage that that slice in the pie you’re seeing actually represents.
Because I’m cutting out some of the data (any slice less than 1%), the remaining data expands to fill the pie. Thus the number is slightly higher, but it is not significant enough of a difference to actually worry about.
There is no “raw count” anywhere on that version number chart. The raw count is not data that will be made available.
Ok got it, it is a bit confusing like this even if it very valuable data! Why don’t you want to display the raw count? It would be very interesting data as well and won’t break any privacy as you aren’t displaying which blog is using it…
The raw numbers bounce around a bit, but the percentages are usually consistent.
We won’t blame anybody if the numbers aren’t 100% accurate. More than the raw numbers, it is the trend that is interesting. Perhaps you could provide the global number of blogs on which the plugin is installed, this would be maybe simpler and less subject to error. Would be nice anyway
Anyway, many thanks for this new feature, very valuable! Congrats folks!
Hopefully in the future we’ll be able to show rankings and rough %s.
Hi, just wondering whether there is a problem here, or whether I am missing something? Would love to see this data, and would appreciate if someone would enlighten me.
Visibility of Pie chart, Google response?
I understand that version data is not available for all plugins, but I have only managed to see the “pie chart” once for one plugin at http://wordpress.org/extend/plugins/vipers-video-quicktags/stats/ and once I navigated away (tried one of my plugins of course, nothing there, tried others mentioned above, nothing there (yet others had obviously seen pie charts), came back to viper, but now no chart, then just had a long… “transferring data” which is also what I was getting with others.
Maybe the pie charts should be cached in case the google chart api fails?
API access
I assumed maybe problem was with the google chart api response, so thought I’d see if I could get the stats via the api mentioned above, since without the chart api the data is not visible. I assumed that it would work similar to other wp api call’s (version check and plugin search/info calls). No matter what plugin slug I use from thos ementioned above or akismet, eg:
http://api.wordpress.org/stats/plugin/1.0/simple-facebook-connect or
http://api.wordpress.org/stats/plugin/1.0/eshop
I get an empty OK response?
array(4) { ["headers"]=> array(5) { ["content-type"]=> string(9) “text/html” ["content-length"]=> string(1) “0″ ["date"]=> string(29) “Mon, 25 Oct 2010 00:28:45 GMT” ["server"]=> string(9) “LiteSpeed” ["connection"]=> string(5) “close” } ["body"]=> string(0) “” ["response"]=> array(2) { ["code"]=> int(200) ["message"]=> string(2) “OK” } ["cookies"]=> array(0) { } }
There were some problems with this which I’ve since solved. You should get a valid response for almost all of the plugins now.
Looks like you might have noticed judging by the data shown in http://api.wordpress.org/stats/plugin/1.0/simple-facebook-connect, but is it possible to cut out invalid version numbers (e.g. 500.0 in SFC)
Yes, but it’s not something I’m going to do yet. I want to see what builds up after being there a whole week. After that I’ll work on filtering to eliminate strangeness.
Thanks
Otto – this is really useful, as a plugin developer, to see this information.
One question, though – is there anywhere I can go to find out more information about other WordPress.org API calls like this one? I’d like to be able to access other plugin information but the api.wordpress.org site shows that there is currently no documentation.
Thanks.
Yeah. We really should document those.
Great tool for plugin developers, Otto. Thanks! I’ve been hoping for something like this for a long time.
Otto – Thanks for your work on this. Looks like I jumped on the plugin development bandwagon at the right time. Here’s a thought. I know you aren’t showing slices < 1.0% and, instead, are stretching the other slices of the pie to make up for this. Instead of doing that why not add all these slivers together and put them into an "Others" slice? Just a thought.
I could do that for the display, sure. Note that the API call returns all the (valid) numbers, not just those above 1.0.
Not sure how I missed this. Thanks!
So, the output on the stats tab, and via the specific plugin URL seems to flip around quite a bit and today I’m getting a return that 100% of my install base is on a rather old version, which I definitely know is not the case. Is this code still moving around a lot? Any idea when it will be locked down as I can’t say I’m happy when I go to the plugin on wordpress.com and see that 100% is v1.0.2 when the current version is 1.1.2. Let me know how it’s going. Thanks
Nope, code is solid. What plugin?
Hi Otto,
This one: http://api.wordpress.org/stats/plugin/1.0/webphysiology-portfolio?callback=demo
Let me know,
Jeff
Not enough users. The database only shows 9 reported active installs in the last week. And versions with counts of 1 are ignored.
Note that some data may have been lost a few days ago, when I was making some other stats changes. This will self-correct as time goes by and sites do update checks.
Gotcha. Are there other APIs into the stats? Like you’re able to see counts but I believe I can only see percentages. Would be nice to know how many folks actually have it installed verses how many folks have downloaded it. Not that I’d want others to see this info necessarily but from a perspective of how much ongoing effort to put in or as an indication to maybe review it for improvements…. Thanks for this!
You should read the previous comments on this post. Counts are purposefully not revealed.
Thanks Alex, I had read this a back in October. My question was around whether there were other APIs, outside of the one in this topic, that would provide more details. Numbers would be nice. I can understand why specific domains might not be shared but seems like sharing numbers with developers isn’t a bad thing. After all, this is “open” source, right?
The codex now recognizes the single-sign-on wp.org cookies and signs you in with them.
Note that MediaWiki has its own cookies too, so logout doesn’t quite work right. I’ll work on that soon.
I was wondering why Codex how gives nothing more than “Failed to get ID from name ‘MikeSchinkel’”; ideas how to fix; clear cookies?
Sorry about that. Working on it.
Log out, delete cookies, and try again?
Maybe a note on the Codex home page letting people know this would be good? Seeing some chatter via forums that people think it’s broken.
Okay, this is temporarily disabled until I figure out what went wrong. Mike, email me directly please, since you can reproduce this and I can’t.
Emailed, but it seemed to have cleared up.
Okay, problem is solved for the subset of people that were having the problem.
Long story short: If your username matches without regard to case, then you’ll get logged in properly now. If it can’t find a matching user for you, then, well, you just won’t get logged in. Better than getting that error.
In theory, it should make a new user for you in MediaWiki in that particular case, but that doesn’t seem to be working for now. I’ll sort that out tomorrow. At least you’ll be able to access the codex regardless.
WordPress.org now shows Gravatar Hovercards too. Should be active anywhere you see a Gravatar on the site.
Thank you for the speedy service
Is the link to the plugin author profile on the plugin detail page gone for good? I liked that users could click through and see all of the plugins I’ve released.
There’s an API where the page can add additional stuff to the hovercard, so we could actually put # plugins and # of themes linked directly to those pages in the hovercard… next version.
The current implementation of the hovercards overrides the A tag (if there is one) wrapping the Gravatar. If that tag were split out so that there was one wrapping the image and one wrapping the text/name, then the name could be linked directly to the profile page.
We currently have a pretty basic callback system in place so that you can do things to cards as they are generated (one card, per profile on a a page). You can hook into that by creating a callback method (called profile_cb) on the Gravatar object, before calling attach_profiles(). That might look something like this:
DH-Shredder are discussing. 
Denis, 
<script type='text/javascript' src='http://s.gravatar.com/js/gprofiles.js?ver=1'></script>
<script type='text/javascript'>
jQuery(document).ready(function($){
Gravatar.profile_cb = function( hash, dom_id ) {
// do stuff here
};
Gravatar.attach_profiles();
});
</script>
hash = the md5 hash of the email of the user
dom_id = the DOM id=”" of that hovercard (you can use this to isolate a jQuery selector within that card)
From there, you can use some DOM magic to inject things into the card wherever you want, just take a look in Firebug or something similar to see the structure of the HTML that’s created and you should be able to figure it out
You might need to bump the ver=1 part once in a while, because we’re still tweaking things a little bit, so you won’t get the latest version unless that increments (CDN will be caching the old version).
Otto, can you use that callback to keep the link pointing to the WordPress.org profile?
Also, when someone doesn’t have a hovercard (which many people don’t, because they’re using a secondary Gravatar addresss), it removes the link. Go to one of my plugins, hover my name, and watch the text go from blue to grey and unclickable.
Fixed the name link. The image now links to the gravatar profile, the name points to the profiles page.
Hovercard appears with the info alright, but the edges are rugged and just don’t look good. I’m guessing it’s just a browser thing (I’m on Ubuntu 10.10 Chrome 6.0.472.63). There should really be some kind of fallback, or just hold back the unnecessary advanced feature that is the tilt. Just the zoom would be awesome enough
Some of the hovercards don’t seem to be working – mine for example, and Esmi’s – the little loading spiral just goes round and round infinitely. Is there some requirement that makes the card work?
Made some minor style updates to the wporg web site today; changed the dark grey and light blue backgrounds to lighter shades of grey to better match the 3.0 style, as requested by Matt M. Replaced homepage screenshots with new ones from 3.0, as requested by Jane.
Looks awesome!!!
I love the color
The Codex will be updated shortly, since it’s different templates it lags behind.
Imagine if it was run on WordPress! *cough*
Looks nice! The color of the drop-down under Extend needs a color fix too.
I think the extend drop down needs a mouse over events on the sub items, like a color change or something. Perhaps change it to orange as well?
Just deployed a fix for the extend dropdown; may take a few minutes and/or need a clearing of your cache. Submenu items should have the same orange hover color as other menu items.
Loving the new color change. Really stands out and clean to read.
Much easier on the eyes – great job as always.
Looks great! Will the local sites be updated too?
Yeah, local sites should be updated too (since local forums already are).
The inner form pages need some color retouching too: http://wordpress.org/support/forum/3
Nice When the light grey color scheme was first added to WP, it seemed out of place. But, it’s really grown on me since then and looks great on wp.org.
Looks really good, MT. Nice work.
Looks neat and feels more polished.
Outstanding work.
Just noticed when the ‘extend’ tab is “current” the nav-submenu anchors lose their hover state.
http://planet.wordpress.org/ still has the old colors.
I actually think this is not an improvement; the fresh colour scheme with blues was better. The silvery grey is okay for an unassuming ‘behind the scenes’ admin look, but here it looks bland and unattractive; not good for fresh open source software that has just released a new version with loads of beautiful new features.
The most important thing to realize is that the WP Dashboard serves radically different goals than the WordPress.org ‘storefront’. I think it is a mistake to use the same colour scheme for both. Imagine mozilla.com (champion of fresh and professional FOSS looks) being styled with the colours of the Firefox or Thunderbird user interface! (crossposted from here)
I disagree. I love the consistent WordPress look, creates brand recognition…
mark, 
DH-Shredder 5:59 pm on April 14, 2011 Permalink | Log in to Reply
Since this is work on bbPress specifically, it should only affect the front-end of the directory, and not the SVN repo, correct?
Otto 6:34 pm on April 14, 2011 Permalink | Log in to Reply
The display and search capabilities of /extend/themes and the API calls from core will be temporarily affected until I can make the proper adjustments to them. Access to the SVN will not be affected.
DH-Shredder 7:05 pm on April 14, 2011 Permalink | Log in to Reply
Cool, thanks much.
Otto 8:24 pm on April 14, 2011 Permalink | Log in to Reply
This update is complete. Let me know if any bugs are spotted and I’ll correct them.