Pears »
“Collect, test, and experiment with interface pattern pairings of CSS & HTML. Pears is an open source WordPress theme, enabling people like you to get your own pattern library up and running quickly.”
WordPress Excessive Overloading Your Server – Solving the wp_cron.php Resource Issue »
Genesis Framework Hooks »
via @pat_ramsey. A handy tool to 'display all hook names right in your theme view in the browser.'
Genesis Framework Hooks »
via @pat_ramsey. A handy tool to ‘display all hook names right in your theme view in the browser.’
WordPress Snippets »
A collection of WordPress snippets to make developers' lives just a bit easier. I'm not found of the current UI as it's not easy to skim, but the filter capability helps and I'm sure the site will improve as it grows.
How to Unlock the Secret “All Settings” Menu in the WordPress Dashboard – WordPress, Multisite and BuddyPress plugins, themes, news and help »
A quick addition to your functions.php will provide quick access to an 'alphabetized list of everything in the wp_options table' within the WordPress dashboard.
Handy, very handy.
The Guardian Releases a Newsfeed Plugin
The Guardian just released a news feed plugin for WordPress as a part of its Open Platform initiative, making it easy for anyone to post Guardian stories to their WordPress-powered site in full, images and all. They’re working on other platforms as well.
Oh, and did I mention ads? Because they’re including ads and performance tracking in the stories too.
This is smart on so many levels – when so many other publishers are trying to lock everything down, the Guardian sees the future and is going to make money from it.
If you aren’t familiar with The Guardian’s efforts on the Web, you should be. They have an absolutely amazing team of developers building out their platform, which includes a content API, politics API and curated data sets.
As they put it “Our vision is to weave the Guardian into the fabric of the Internet, to become ‘of’ the web rather than ‘on’ the web.”
Design, Feedback, WordPress and the Community
Chris Messina has posted a great entry discussing the problems with open source design, with a focus on the new administrative interface for WordPress 2.4, which is generating a lot of discussion now that it is partially implemented in the nightly releases. As an avid user of WordPress and occasional plugin developer, I’ve been following the discussion from afar and fully agree with Chris that it is much too early for the design to be judged.
Hopefully Chris’ points about a lack of a visible design owner will be noted and acted upon. The project needs a strong, authoritative voice that can answer the design questions, lead the discussions and gather ramblings, compliments and complaints for future revisions. I fully believe the WordPress team has all of these issues covered, they just need to communicate it a bit more and demonstrate that they have it covered. We as a community also need to trust that they know what they’re doing – we are using their software after all, and judging by the amount of sites running WordPress, and the amount of people theming and building plugins for the platform, I’d say it has a loving community.
One of the first steps to resolve this issue is purely communication. I think it incumbent on the designer/dev team/Matt to release the final approved comps of the design, if for no other reason than it eliminates the uninformed complaints and can guide the conversation towards useful feedback. If people are going to take issue with the design – and people always take issue with design changes – they should at least see the plan in full, and there’s no reason to wait for final implementation for its debut. People love WordPress, and this is a major change; humans tend to dislike change when the object being modified is something with which they are comfortable. Doubly so when the changes are unknown.
Right now, all folks see is a Frankensteinian beast where once there was a well-known friend. Assuaging the fears is as easy as a quick post of a few screen shots, and a couple of words to describe the changes.
Fixing the WordPress Theme Reset Problem
As I posted in the WordPress forums I’ve run into an odd problem – WordPress occasionally resets my theme to the default version, which is annoying to say the least. After a lot of digging, I learned that the likely culprit is a bit of code in WP meant to protect the user from bad themes, but which has had the opposite effect for me and many other users. Luckily, others have already reported the bug and filed a patch, but the fix won’t be released until the next version of WordPress (2.4), which is slated for late January.
So, I decided to go out on a limb and make the change in my local version with the expectation that the file will be overwritten when I upgrade to the latest and greatest. So, I modified one line as indicated in Changeset 6325, commenting out line 269 of wp-settings.php, which contained validate_current_theme();.
I’m not positive that this will fix the issue, but all of the signs point in the right direction. As the fix is simple, and has been made to 2.4, I feel relatively confident that it is a safe move on my part. I’ll keep an eye on my site and post updates as needed.
Many thanks go out to the great folks constantly improving WordPress!
Update: Well, that theory didn’t last too long. When I hit the site this morning my theme had reset. Grrr.
WordPress Marketplace
Matt, the creator of WordPress, is laying the groundwork for a theme marketplace, the beginning of which he shares in his post Marketplace Idea. The idea is solid, and a step I’ve wanted to see for a while. I design and build my own themes, and will likely do so for a long time to come, but I have never built a theme to give away due to time constraints, so I’m not firmly in either target audience for the service. From this outside (though firmly in the ‘I love WordPress’ camp) vantage point I see some great benefits from this service:
- The amount of people developing themes will increase, as professionals will be able to justify the time spent on theme creation. If billable hours are important to you, knowing that you are creating a product is worth spending some unpaid time up-front.
- Following from the last point, the more professional developers and designers that are involved, the more high quality themes will be available.
- Blog themes will gain in value. While I am a big fan of giving away work, having produced a couple of small plugins and scripts myself, it is important that we establish the fact that good work is worth paying for, and great work doubly so.
- Good designs that are “retired” from a site could be put into circulation as a theme. I’ve had a couple of designs that I have replaced because I wanted something new on a site, not necessarily because the old design had any major flaws. Knowing that I could earn money, benefit others and/or gain recognition, I’d be more willing to spend some time making the small changes required to place it on the Marketplace. I’m not sure how this point relates to the requirement that the theme has not been published before.
- This is a great promotion of open source code, without sacrificing the earnings that should come from hard work.
I’m really curious to see how the pricing will play out. Will the system set a price, or a set of prices, or will each theme producer set their own? Knowing only that a subset of users will have to pay to use your theme provides an interesting twist to setting your price and deciding on how much work to put into each theme.
I’m also excited to see how people make names for themselves, building reputations with the themes they produce. This could produce a neat cottage industry, or it could reduce the value of design and development in much the same manner as the “get a whole site for $500″ services that have existed for a while. The latter doesn’t worry me very much, as quality stands out, and I know quite a few top notch folks who make their living producing great work at fair prices far above the outsourced rates.
Ma.gnolia Plugin 1.4 Released
Thanks to Rick and Emre for the excellent suggestions which prompted these improvements to the Ma.gnolia WordPress plugin:
- Added the ability to pull bookmarks from group collections as well as those of individual people. Tags can be used with either, so you can pull bookmarks from the Web Design group that have been tagged with ‘css’.
- Added ability to pull the Full feed from Ma.gnolia, which includes:
- Thumbnails of each bookmark
- The tags applied to each bookmark
Please note, this is all or nothing, so you cannot just pull the image, or the image and description without the tags. Sorry, but that’s how it’s coming through and I spent too much time trying to find a way around it with a couple of different RSS parsers.
- Changed the variable $username to $collection to fit the new model of pulling from groups or individuals. This shouldn’t impact your site as it is more of a clean-up task.
- Added configuration option to enable/disable the link to view more Ma.gnolia bookmarks
- Added the plugin to wp-plugins.net/ to ease updates for folks using Update Manager to track plugin updates (like me).
Please check out the official page to download the latest version and the new examples page to learn more about the plugin.
Note: for Users of 1.3: You should be able to drop this upgrade in place without changing any of your code. Please let me know if you notice any issues with your existing setup.
WordPress Database Error
I’ve been running into problems ever since I upgraded WordPress to 2.x (not sure if it was 2.0 or 2.1) with new posts. The first time a new post was was loaded into the browser, the server kicked out this error:
PHP Warning: mysql_affected_rows() [<a href='function.mysql-affected-rows'>function.mysql-affected-rows</a>]: A link to the server could not be established in /Users/alex/Dev/SilverSpider/site/wp-includes/wp-db.php on line 183
I searched to find an answer when I first ran into the problem, but never found a solution. Then, while I was working on the Ma.gnolia plugin, it cropped up again, so I began comparing my install to the stock set up and and found that my old wp-config.php contained some lines that are not included in the 2.x wp-config-sample.php:
$server = DB_HOST;
$loginsql = DB_USER;
$passsql = DB_PASSWORD;
$base = DB_NAME;
As I upgraded from 1.x, and the instructions say not to mess with the config file, I hadn’t looked into it as a possible source of the problem, but by removing this block of code, all appears to be running properly, at least in my local development environment. This post will either reinforce my theory or blow it to bits…
Show time!
It works!
Well, this post worked perfectly and did not generate an error. If you upgraded from 1.x to 2.x and are running into this problem, backup your wp-config.php and then remove that block of code and try it for yourself. Please let me know if that doesn’t work for you. I’ve filed a ticket so this will be resolved all official-like (3992).
Perhaps Not…
Damn it! The error just re-appeared after I edited this post. Grrr.
Change the Thesis Doctype and Add Meta Tags
I love using Thesis because it lets me focus on content, while providing all of the design and development hooks I need to tweak the theme as I see fit. I’ve dug in a good bit, and while I’m far from an expert, I’m confident that anything and everything I want to do is available to me.
One thing I discovered early is that the default doctype is XHTML Strict, which is great in many respects, but can add some complexity given enough design changes and external data sources.
In 1.6 I was able to add some custom code to change the doctype to XHTML Transitional, simplifying some issues I was having with IE 8. Those same reasons necessitated that I include a new meta tag as well. Thesis 1.7 changed the implementation methods, so I’m documenting the new, right way to modify the doctype and add items to the page head in the hope that others might find it useful.
Credit: I learned about of this from girlie, who was kind enough to point me in the right direction on the Thesis forums.
Modify the Thesis Doctype
Simply add this to custom_functions.php in your Thesis directory:
Adding Meta Tags or Conditional Comments
This hadn’t occurred to me as I’m used to placing these directly in the code, but once girlie pointed me in the right direction I found it is a simpler solution.
<head>Thinking About Thesis?