Revision History

2014-01-25: Fixed issue with oversized favicons (this may take a while to work itself fully clear of all caches, both server and local-user). Adjusted javascript embed to avoid multiple inclusions of the CSS file when multiple javascript embeds are present in a single page.

2013-06-28: Fixed issue with Gravatars being replaced by essentially-random identicons (due to HTML change on Stack Exchange profile accounts page).

2013-04-28: Minor internal changes that may result in slight performance improvements. Added guards against internal server errors in PNG image generation. For HTML and JS output, used CSS to slightly compress the text of badge counts with 4 or more digits.

2013-02-24: Fixed issue with missing display names (due to HTML change on Stack Exchange profile accounts page). Added support for non-Gravatar avatars.

2013-01-07: Enabled the use of the numeric "account id" instead of the association id, changed the examples to use account ids, and made the "get code" page generate the account id URLs. (URLs based on association ids should continue to work to whatever extent they already did—it seems they may not have worked at all for some more recent users.)

2012-05-16: Fixed issue where the total rep would be missing a zero after the comma (for example, "4,69" instead of "4,069"). Added last-modified and cache-control headers to output so that proxies and browsers can cache the results.

2012-03-24: Fixed broken SSL favicon URLs, added cache-control header to the SSL proxying of the favicons to cause browsers to cache them for 30 days.

2011-11-22: When the HTML or JavaScript flair is loaded via https, the favicons are proxied through se-flair.appspot.com so as not to break the https security (sstatic.net doesn't have a proper SSL certificate of its own).

2011-11-19: HTML and JavaScript output now use SSL-agnostic URLs (by stripping off the leading protocol, for example., removing http: to get //sstatic.net/math/img/favicon.ico) for the favicons and if https was used, switch to the https://secure.gravatar.com/ URL for the Gravatar, so using an https://se-flair.appspot.com/ URL inside an https page should not cause any insecure resource loading.

2011-09-22: Changed from many API calls to scraping the stackexchange.com profile accounts tab. Fixed the color of the rep text in the PNG output.

2011-03-31: Fixed issue with some favicons being missing or very large, possibly distorting the HTML and JavaScript output (specifically GIS, possibly others).

2011-03-28: Fixed issue with incorrect rounding in display of total rep in some instances.

2011-03-22: Fixed error with applying topn parameter (for example, top4) to image output; hid badge types with a count of 0; added facility to get copyable embedding code based on a profile page URL.

2011-03-20: Fixed internal server error in case where StackAuth 1.1 API call reports an account with no site_name.

2011-03-17: Issues with label placement and bad rendering of favicons seem to be corrected now; if badge counts are not complete at time of loading, they are not displayed (but they will be rechecked on the next load).

2011-03-16: Initiated experiment in faster loading—badge-loading is more often delayed, but overall flair loads faster, just omitting badge counts if they are unavailable.

2011-03-13: Added experimental image output.

2011-03-07: JavaScript embedding method added; all links now target _blank so as to open in a new window/tab; http://se-flair.appspot.com/[site hostname]/[site user_id]/ (or http://se-flair.appspot.com/js/[site hostname]/[site user_id]/) now displays a link to the correct URL rather than redirecting to it.

2011-03-06: Total rep is now rounded rather than truncated (as is the case in Stack-Exchange-produced flair); diamond is shown if moderator on highest-rep site and diamond and count are shown if moderator on other sites; display-name color fixed.

2011-03-05: Added a work-around for a bug where the StackAuth 1.1 API returns an invalid user_id, and some improved error-handling.

2011-03-02: Fixed "internal server error" issue for users for whom their Area 51 account is their highest-rep account. (Since there is no API access to Area 51 data, the data on the Area 51 account is generated by running some regular expressions against the HTML of the user page; previous versions neglected to pull the display name and email hash for Area 51—the display name and email hash of the highest-rep account are used for the gravatar and display name in the generated output.)

2011-02-28: In the case described below, where some badge counts are assumed to be zero because of a failed API call, a small (?) will appear to the right of and slightly above the badge counts with the title text "data may be incomplete". [superseded by 2011-03-16] (As below, the API call to get the badge counts will be tried again on the next load.) Also, requests using the 32-character hexadecimal string association id without the four hyphens are now redirected to the URL with the 36-character association id (with the four hyphens in place).

2011-02-26: The "internal server error" issue seems to have been a problem with loading badge counts. Now, in instances where there is a problem loading badge counts for a user on a particular site, it is counted as zero badges from that site to allow loading to complete. Retrieval of the badge count is retried on the next load.

Experimental Features/Changes

• Data is now scraped from the stackexchange.com profile accounts tab

Because of the really large number of API calls needed to assemble the data (and having to scrape the Area 51 profile anyway) and problems associated with it, versus the relative simplicity of scraping the accounts list on the stackexchange.com profile page, data is now grabbed that way. In most instances, this seems to result in slightly higher reputation points and badge counts for reasons that I haven't fully investigated. This also means that there is no longer a delay in loading up badge counts.