Assuming the county burn ban remains lifted, Boren and I intend to have a big ol’ Texas cedar fire in my back yard during, immediately before, or immediately after South by Southwest Interactive. A bunch of Automattic employees and WordPress contributors are expected.
If you are seriously interested in getting away from Austin (about 45 minutes) to throw small trees on a large fire, please tell me your best evening for this activity. Please also specify whether you will be able to provide responsible transportation for others.
UPDATE: Leaning toward the 16th based on a few answers. Would coinciding with the closing parties be a feature or a bug?
Posted by Andy Skelton on February 11, 2010
My Google Summer of Code 2009 student, Justin Shreve, has done an excellent job creating a new search API for WordPress. We hope this API will be integrated into the WordPress core because it would simplify replacing the core search functionality and encourage developers to create many more options for searching blogs.
Justin’s Search plugin is actually a package of three plugins. The first plugin installs the API that lets other plugins do the searching. The other two plugins use the API to provide search systems that we think will please most users who are dissatisfied with the built-in WordPress search results: MySQL Fulltext and Google Custom Search. (The Google plugin requires a Google account.) For the search-savvy, Justin also wrote a Sphinx-based plugin, Sphinx Search. This last one involves installing additional software on the server.
I’m running the Fulltext plugin on my personal blog so you can try it. Enter a search in the sidebar. On the search results page you can refine your search by specifying whether to search posts, pages, and comments. You can also sort the results by relevance, date, or alphabet. The Advanced Search link leads to a form where you can specify author, categories, tags, and date range.
Self-hosted WordPress users can install Search. (It is not available for WordPress.com… yet.) After activating the main Search plugin you must also activate one of the other plugins: MySQL Fulltext, Google Custom Search, or Sphinx Search. We are anxious to know what you think of it. Justin plans to continue to improve the search system so he will need lots of user feedback.
Posted by Andy Skelton on August 21, 2009
At first we thought it was a good idea to use iframes to display reports in the Stats plugin. We’ve seen since then a lot of problems with browsers and cookies. To help resolve these issues, and in anticipation of future features, I am updating the plugin and the WordPress.com stats reporting system to remove the iframes. I just posted 1.5 beta 1. If you host your own WordPress 2.7+ blog and you use the Stats plugin, why not contribute to its development by installing this testing version? Anyone can download the beta but I don’t recommend it unless you are able to cope with potentially unstable software.
- What are the risks of using this beta?
You won’t lose any stats. If something goes horribly wrong it’s probably a bad download; just reinstall the latest version of Stats.
- How does it work?
The plugin connects to WordPress.com to get the stats reports when you request them. It uses the API key to authenticate.
- Aside from fixing cookie problems, how is this better?
Now it’s possible for anyone who can publish posts on your blog to see blog stats. They don’t have to be logged into a WordPress.com account. They only need the publish_posts capability (Author role) to view stats reports.
- Where did the dropdown blog switcher go?
Because the plugin uses a single API key to authenticate, the service doesn’t know whether the visitor is the owner of that key or some other user. So it doesn’t make much sense to show the list of blogs belonging to the API key owner. You can still use the switcher if you view your stats on any WordPress.com dashboard.
- Where did the Stats Access panel go?
This is also related to single API key authentication. Maybe in future we will bring administrative access back to the plugin. But until then, we have left the Stats Access panel intact on WordPress.com dashboards. You might want to bookmark dashboard.wordpress.com if you need these features on a regular basis.
- Will this be a required upgrade?
You mean will older version of stats be broken? Not by 1.5. Later versions may break compatibility but for now you can keep using earlier versions of Stats if you like.
- What if I install this and still see iframes?
This happens because your server is unable to connect to WordPress.com. I set it up to use SSL (https) in the hopes that most hosts support this. If yours does not work, I’d like to hear from you and do some testing on your host.
Posted by Andy Skelton on June 19, 2009
Self-hosted WordPress and WordPress MU administrators: if you are using the memcached object cache (a prerequisite for batcache), upgrade it before upgrading WordPress. There is a bug that keeps the old db_version in the options cache, preventing WordPress from remembering that it has been upgraded, and this causes it to ask you to upgrade again. In a pinch you can resolve the problem by restarting the memcached daemon.
The memcached object cache can’t be automatically upgraded because it’s not a normal plugin. Make sure to use the right version: 1.0 (sockets) or 2.0 (PECL). Only one line was changed, so you might prefer to update by hand: 1.0, 2.0.
If you aren’t sure whether you are using memcached, look for a file named object-cache.php in wp-content. If that file exists, look inside to see if the plugin name is “Memcached”.
Posted by Andy Skelton on November 19, 2008
Inspired by the new and sublimely useful WP Roadmap, here is a high-level diagram of WordPress in three sizes: 512, 1024, 2048. Made with OmniGraffle Professional.
Posted by Andy Skelton on October 30, 2008