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.
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.”
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.
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
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.
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.
- 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).
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.
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…
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).
Damn it! The error just re-appeared after I edited this post. Grrr.