From the screen shots I’ve seen as well as the feedback from a couple of different websites, it looks like Blogger has finally taken a few pages out of the book of WordPress in terms of the interface. Econsultancy.com thinks the refresh is too little, too late. I wonder how many people who participated in all of the interface testing for Blogger gave the suggestion “make it look like WordPress“. ∞
Not sure if any of the plugins or themes you have installed within your WP-Content directory contain the outdated version of TimThumb? Good news, there is a simple plugin that not only scans your content directory for the outdated version of the script, but also provides a link to quickly upgrade to the newer version. After installation, you’ll find the options page within the Tools menu. After running the scan on WPTavern for the first time, these were my results:
This plugin is especially useful to those who have more than a few themes or an abundant number of plugins installed as it checks the entire contents of the WP-Content directory. According to a post within the plugins support forum, it has not gone through specific testing with WordPress Multi-Site but the author sees no reason why it wouldn’t work.
Joost de Valk who is pretty popular these days, especially after the release of his Yoast SEO Plugin tells us the story of how one of his sites was hacked because a theme containing the TimThumb vulnerability was not updated. If that were not interesting enough, Joost shares a statistic that doesn’t surprise me one bit. According to Joost, after he releases an update to his plugins, he rarely sees more than 20% of the user base upgrade within the first week.
We, as a community, need to get better at that.
I agree. People such as myself have harped on the fact that people need to start upgrading their WordPress installs sooner rather than later once an update has been released. I don’t have the numbers to back it up but I’m willing to bet that thanks to the easier upgrading processes built into WordPress, there is a larger number of people updating within the first week compared to when users had to manually upload the updated files to the server.
As if keeping abreast of updates for WordPress were not enough, users have to be vigilante on knowing when there are updates for both plugins and themes. Despite WooThemes publishing the information on their website regarding the security flaw and the associated fix, Joost still became a victim one month later. It seems as though KNOWING about the update is at least half the battle. Therefor, what do you think is the best way or ways to keep users abreast of updates for plugins and themes, especially as it relates to security releases? As it stands, the only time I know of when a plugin or theme needs to be updated is when I’m at the dashboard screen and I see the notifications. Should there be a built-in function in WordPress that plugins as well as themes can use to send email notifications to administrators when an update is available? Or, do we rely on plugin and theme authors to individually come up with ways to help their user base keep in touch with updates?
WPCandy has announced that they have launched a new service called Pressed Ads. While WPCandy was initially surviving ad free thanks to their Powered By System, reality has sunk in. Their powered by system will now be going in two directions, one for their readers and one for businesses. The unique advertising network will be centered around WordPress centric products and services while also being invite only for advertisers and publishers. It looks like the goal is to have Pressed Ads show up on the most influential WordPress sites which will provide extremely high relevancy with regards to the type of advertising that will be displayed on those sites through the network. Since the beginning of the year, the powered by system, has enabled Ryan to work on WPCandy full time which is amazing in and of itself.
I for one wish Ryan the best of luck. If he can manage to find a way to get paid enough money to live a semi decent life while putting food on the table not made of Ramen noodles which also allows him to work on WPCandy full-time, more power to him. He would then be accomplishing everything I didn’t. I tried advertising and managing that myself, affiliate programs, the botched VIP section in the forum and in fact, donations. None of the revenue was guaranteed and at times, I would go a few weeks without receiving a dime. I think my downfall in the advertising was that I was not a salesman and for the most part, didn’t want to be one. The best situation that could have happened for me was if I could find someone willing to pay me a flat fee on a weekly basis. Sort of like an investment, an investment in ME and the content I publish. That way, WPTavern ended up more like a job for me that I knew I was going to get paid for versus busting my ass and sometimes reaping no rewards. But I could never figure out how I’d convince anyone to go through with that type of investment, at least not anyone with the kind of income that would even consider it valuable to do so. I just wanted to concentrate on generating the content I and my readers/listeners enjoyed without going broke.
Right now, WPCandy is the place to be. It’s the hip spot when it comes to WordPress news and community. Ryan knows the people he needs to know and it’s obvious he has the support of some great companies that are backing him on his work with WPCandy and now, Pressed Ads. Now it’s time to see if his passion and desire along with all that support are enough to get him and the site up to the next level.
Kaspars Dambis of Konstruktors.com has publised his second version of a proposed user interface design for his popular Widget Context plugin. Widget Context is a plugin that provides users the opportunity to show or hide widgets. I’ve used Widget Context in the past but I’ve been quite happy with the performance and functionality of Widget Logic which relies on me knowing about Conditional Tags. Because of the conditional tags concept, it’s not the most user friendly plugin. However, I am very satisfied with how it works. By default, when a widget is enabled in WordPress, it’s displayed within the sidebar on every page that sidebar is loaded. After configuring a widget through Widget Logic to only show up on the front page via the conditional tag, it is then hidden on all other pages EXCEPT the frontpage. So in a way, I’m configuring where the plugin will display and be hidden at the same time.
Widget Context on the other hand has the ability to tell widgets where they are hidden and where they will be shown. Some may see this as a benefit as more flexibility, but I see it as another layer of complexity. The second edition of the proposed user interface for Widget Context is as follows:
You can also see a live demo of the UX proposal. I like the idea of being able to search for pages or posts to show or hide widgets during the configuration process. However, this version of the plugin implements rules that can have lower or higher power based on their vertical arrangement. While this provides more flexibility, I think it adds complexity. Since this type of functionality looks like it will never make it into the core of WordPress based on everyone that has told me “There’s a plugin for that” I’d like to share with Kaspars and anyone else that may be looking into this realm of WordPress functionality what I’d like to see so that we can have a GO TO plugin that everyone can use.
I’m thinking of a plugin that’s a cross between Widget Logic and Widget Context. This plugin should work on the premise that anytime a widget is added to a sidebar, it’s viewable across the entire site where that sidebar loads. UI is added to the widget screen so that I can easily search or choose from the various template files that make up my theme to decide where the widget will be displayed. By specifically configuring where the widget will be displayed, I’ve also configured where it will not be displayed. I’m not quite sure which user interface would work best for selecting more than one area where the widgets will be displayed, perhaps the check box method that already exists in Widget Context. This is about all I’d need to satisfy my needs. It’s simple, not many options and I think covers the basis for a lot of uses. Now, if Kaspars or users suggested that they wanted rules, or more complex ways of telling their widgets where to show up or hide, I would not complain about having an Advanced tab that showed additional options. But I definitely don’t want that clutter in view as part of the default configuration UI.
I’m not sure if I explained my vision very well but if you could, please take a look at the proposed changes and offer Kaspars some suggestions if you have any.
Mark Jaquith recently performed a scan on a local copy of the WordPress plugin respository and was able to generate a list of basic quoted string shortcodes within the plugins. The list looks like it could go to the moon and back with some funky looking shortcodes that are not very descriptive. Mark notes that there has been some discussion on whether or a not, a directory should be built and published which notes all of the shortcodes in use from all plugins in the repository so that plugin authors can check and see if their own shortcodes would conflict with any other plugins or perhaps, make theirs compatible with another.
While I don’t dabble in as nearly as many plugins these days, I can say that I’ve never gone through the experience of dealing with a shortcode conflict. If you have, I’d love to hear your story.
Morality Of Forking – Another well written piece covering the GPL, this thing called Spirit and an explanation that you can abide by both and still be a jerk.
