{EAV_BLOG_VER:03e3025f70d7b469}
Nothing to see here... just verifying my blog for my Empire Avenue profile.
P.S. Wanna join?
"And can the liberties of a nation be thought secure when we have removed their only firm basis, a conviction in the minds of the people that these liberties are the gift of God?"
geek·er·y: Socially inept single-mindedness or accomplishment in scientific or technical pursuits. Posts in this category pertain to particularly geek-related topics such as WordPress upgrades, other blog-related software and plugins, software security/bugfixes, Microsoft vs. Apple vs. Linux, math, science, website updates, OpenID, etc.
Do you use WordPress? Do you use several plugins? Have you ever considered donating to the authors of the plugins you use, but find it rather inconvenient to find each plugin's listing at WordPress.org Extend, just to find the author's Donate link?
If so, then you will find the cbnet Manage Plugins Donate Link plugin to be incredibly useful.
Plugin authors define their Donate link in the plugin's readme.txt file. This plugin reads each plugin's readme.txt to find the Donate link, and then, if it finds one, adds that link to the list of links in plugin_row_meta beneath the plugin description on the Manage Plugins page.
With this plugin enabled, you will have quick, convenient, one-stop access to the Donate links for the authors of all your installed plugins.
My hope is that this plugin will encourage more voluntary donations to plugin authors, most of whom put in countless hours of unpaid code contribution to the WordPress community. More and more plugin authors, out of economic necessity, are moving to "freemium", subscription, or other paid models, because they simply do not receive donations from those who use their plugins.
This plugin is but a humble attempt to encourage more users to donate to plugin authors.
Please do not post support questions here. Please post all support questions in the plugin support forum.
In my sidebar, I have displayed lists of categories and tags, but wanted to have greater control over these lists than what is offered by the currently available template tags. Namely, I wanted to be able to display each category/tag with a link to the RSS feed on the left, and a post count on the right. So, based on a helpful blog post, my own meanderings in this WPTavern forum thread, and help from DD32 and mfields in this WPTavern forum thread, I have custom category and tag lists, complete with links to the RSS feeds and total post counts for each category and tag.
Here's how:
Add the following code to your sidebar, or into a widget:
<ul class="leftcolcatlist">
<?php
$catrssimg = "/images/rss.png";
$catrssurl = get_bloginfo('template_directory') . $catrssimg;
$customcatlist ='';
$customcats= get_categories();
foreach($customcats as $customcat) {
$customcatlist = '<li><a title="Subscribe to the '.$customcat->name.' news feed" href="'.get_bloginfo('url').'/category/'.$customcat->category_nicename.'/feed/"><img src="'.$catrssurl.'" alt="feed" /></a><a href="'.get_bloginfo('url').'/category/'.$customcat->category_nicename.'/">'.$customcat->name.'</a> ('.$customcat->count.')</li>';
echo $customcatlist;
}
?>
</ul>
Add the following code to your sidebar, or into a widget:
<ul class="leftcolcatlist">
<?php
$tagrssimg = "/images/rss.png";
$tagrssurl = get_bloginfo('template_directory') . $tagrssimg;
$customtaglist =''; $customtags = get_tags();
foreach($customtags as $customtag) {
$customtaglist = '<li><a title="Subscribe to the '.$customtag->name.' feed" href="'.get_bloginfo('url').'/tag/'.$customtag->slug.'/feed/"><img src="'.$tagrssurl.'" alt="feed" /></a><a href="'.get_bloginfo('url').'/tag/'.$customtag->slug.'/">'.$customtag->name.'</a> ('.$customtag->count.')</li>';
echo $customtaglist;
}
?>
</ul>
You will need to modify $tagrssimg
and $catrssimg
depending on which RSS image you choose to use, and where you upload that image. If you use an image outside of your theme directory, you will also need to modify $tagrssurl
and $catrssurl
accordingly.
Eventually, I will release a series (and/or collection) of widgets, including the above two custom lists.
When I first started blogging many years ago, I used the Blogger platform, which I imported to my own domain using FTP (so that anyone reading my blog would see it as www.chipbennett.net). At the time, Blogger's commenting system was rather rudimentary, so I opted to use a third-party comment management system called Haloscan.
Interestingly, due to developments over the past couple of months, had I stuck with this arrangement, I would be in serious trouble. Recently, Haloscan was bought by Echo, which has announced that Haloscan is being discontinued in a matter of days. Likewise, Blogger has recently announced that it is discontinuing support for FTP importing of Blogger-hosted blogs to third-party domains.
Fortunately, I long ago left Blogger for the infinitely better self-hosted WordPress. Thus, even though Blogger has implemented a replacement service - their Custom Domains feature - and therefore the change would be minor, I don't have to worry about it at all.
More problematic, however, is the announced discontinuation of the Haloscan commenting system. When I first moved to WordPress, I continued to use Haloscan, which I had been using on Blogger. At some point, I decided to make the jump to native WordPress comments - but I still had several hundred comments hosted by Haloscan.
At the time, I was unable to export those comments from Haloscan, as such exports required the purchase of a Haloscan Pro account. So, I modified my blog theme to account for the old Haloscan comments, and kept a hybrid system.
Now, however, with the announced discontinuation of Haloscan, my hand was forced. Fortunately, Echo offered the option of converting to a (paid) Echo account, or exporting Haloscan comments. I quickly exported my comments, as I had no desire to pay for something that I was doing natively from within WordPress.
Thus, the problem became one of how to import several hundred comments into my WordPress database? Fortunately, this script came to the rescue, with a slight modification provided by the script developer. Using the provided script and the export.xml file provided by the Haloscan export, I seamlessly pulled all of my several hundred Haloscan comments into my WordPress database.
If you find yourself facing the same situation, the above script should help you as well.
If you need to import Blogger-integrated Haloscan comments into your WordPress installation, follow the instructions provided by the script author, at the above link.
If you, like I did, integrated your Haloscan comments directly into your WordPress installation, do the following:
$meta_records = $wpdb->get_results("select * from $wpdb->posts");
foreach ($meta_records as $meta_record) {
$blogger_to_wordpress[$meta_record->ID] = $meta_record->ID;
}
If your experience is like mine, you may get an error regarding a malformed XML file, due to its encoding. There are various options for rectifying the problem, but in my case, I just went to the line in export.xml indicated by the error message, and replaced the non-UTF-8 characters (in my case, fancy quote marks) with valid characters, and re-ran the script. Everything worked flawlessly at that point.
The wordpress.org Plugin Repository requires adherence to a few simple guidelines in order for plugin authors to have their plugins hosted there:
- Your plugin must be GPL Compatible.
- The plugin most not do anything illegal, or be morally offensive (that’s subjective, we know).
- You have to actually use the subversion repository we give you in order for your plugin to show up on this site. The WordPress Plugins Directory is a hosting site, not a listing site.
- The plugin must not embed external links on the public site (like a "powered by" link) without explicitly asking the user's permission.
Lately, however, those guidelines have apparently been interpreted somewhat more strictly (emphasis added):
(13:27:03) KnxDT: By the way: Is the GPL header necesary?
(13:27:18) markr: very.
(13:27:28) KnxDT: because WP didn't mention in the standar readme.txt
(13:27:37) markr: Ideally you would include the gpl in a gpl.txt file
(13:27:57) markr: not including the declaration will get it removed
(13:28:10) markr: users have to know what they can do if they wish
I find the assertion that not including explicit license information with a plugin would result in the plugin being removed from the repository to be at odds with the current state of plugins in the repository. To confirm my suspicion that a significant number of plugins hosted at the wordpress.org Plugin Repository did not conform to this requirement, I did a quick audit of both my own installed plugins, and the current Top Ten Most Popular plugins in the repository. I posted my findings in the WPTavern forum. In short:
Based on these findings, I decided to audit a few well-known and influential plugin authors - not to pick on the more high-profile developers per se, but rather to determine the state of license inclusion in plugins developed by those who, ideally, should be leading by example.
Here's what I found:
(0/19) of Matt Mullenweg's plugins written as a plugin and maintained by him have license notice of some kind. Shockingly, the majority of Matt's plugins lack even a readme.txt file.
(13/21) of Mark Jaquith's plugins have license notice of some kind (including one with both a license.txt file and plugin header license notice).
(0/16) of Ozh' plugins have license notice of some kind.
(4/9) of Westi's plugins have license notice of some kind (including one with both a license.txt file and plugin header license notice).
(11/33) of Viper007Bond's plugins have license notice of some kind.
Overall, for the plugin authors listed, only 28 out of 107 plugins (26%) have license notice of some kind (including two plugins that have both a license.txt file and a plugin header license notice). And the number is only that high thanks to Mark Jaquith, without whom the percentage of plugins with license notice of some kind would drop to less than 18%. Only 2 out of 107 plugins (<2%) include both a license.txt file and license information in the plugin header.
I find these numbers to be downright shocking, considering the unwritten rule now being enforced regarding removal from the repository of plugins that lack license disclosure, as well as the assertion that plugins should "ideally" include a license.txt file.
Let me be clear: I fully support the effort to ensure that plugin authors explicitly disclose license information in their plugins, either in the plugin header or in a separate license.txt file. The assertion that users need to be given explicit explanation of their rights to use, modify, and distribute plugins.
That said, perhaps those in the WordPress project leadership, and the plugin developers whom others look up to, should ensure that they are leading by example before a more-strict interpretation of the Plugin Repository guidelines is enforced against plugin developers at large.
Further, since new plugin developers will likely refer to the official wordpress.org Plugin Repository Readme File standard (which currently is silent on the matter of license disclosure) when determining what information needs to be included with their plugins, I would recommend that the standard be modified to include a License section - perhaps something like such:
== License ==
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
This way, new plugin authors would have a standard means of disclosing license information in their plugin - and also, users searching Extend for new plugins would have a known means of determining the license of any given plugin.
What are your thoughts?
Automatically activate all MaxBlogPress plugins:
Forks of existing MaxBlogPress plugins, with registration/subscription activation removed:
The latest WordPress-related minor controversy involves the removal of MaxBlogPress plugins from the WordPress plugin repository. The action appears to be in response to numerous complaints and calls for their removal, due to the behavior of the plugins.
The news of the removal of MBP plugins from the WordPress repository first appeared on the Warrior forum (h/t WPKid), and then on WPTavern, the WPTavern forum, and BloggingPro.
The removal took place presumably for violation of the guidelines for hosting a plugin on the WordPress repository:
- Your plugin must be GPL Compatible.
- The plugin most not do anything illegal, or be morally offensive (that’s subjective, we know).
- You have to actually use the subversion repository we give you in order for your plugin to show up on this site. The WordPress Plugins Directory is a hosting site, not a listing site.
- The plugin must not embed external links on the public site (like a "powered by" link) without explicitly asking the user's permission.
The MBP plugins, which offer a range of functionality from basic blog management (Ping Optimizer, Different Posts Per Page, Multi Author Comment Notification, Duplicate Post Checker) to internet-marketing tools (Stripe Ad, Unblockable Popup, Optin Form Adder, SEO Post Link, etc.), exhibit some abnormal behavior for WordPress repository-hosted plugins.
All MBP plugins behave as follows:
The plugins are problematic in further ways:
There are several problems with this behavior for a WordPress repository-hosted plugin:
The GPL defines itself as a free-software license, and defines the term "free software". From the preamble of the GNU GPL v2 [emphasis added]:
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Lesser General Public License instead.) You can apply it to your programs, too.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
To make this point even more explicit, from the GNU.org website GPL FAQ:
See the definition of free software. The GPL is a free software license...
And from that linked definition of free software [emphasis added]:
The freedom to run the program means the freedom for any kind of person or organization to use it on any kind of computer system, for any kind of overall job and purpose, without being required to communicate about it with the developer or any other specific entity. In this freedom, it is the user's purpose that matters, not the developer's purpose; you as a user are free to run the program for your purposes, and if you distribute it to someone else, she is then free to run it for her purposes, but you are not entitled to impose your purposes on her.
Comparing the behavior of MBP plugins to this definition of "free software":
So, compelling the user to register/"activate" software is a violation of the GPL - much less, requiring the user to opt-in to an email list. Such functionality clearly violates the user's freedom of use of the software without being required to communicate about it with the developer or any other specific entity. Thus, as written and distributed by MBP, the plugins in question do not conform to the GPL, which by its own definition is a free software license.
Further, some of the MBP plugins hosted by the WordPress repository were released under licenses that are not compatible with the GPL.
For example, MaxBlogPress Stripe Ad is released under the following license:
MaxBlogPress Stripe Ad Library
End User License Agreement
Copyright (c) 2008, Pawan Agrawal
All rights reserved.By using the software, you agree to be bound by the terms of this license.
1. You may install and use the software on as many computers and websites/blogs as you wish. You may make back-up copies of the software for archival purposes.
2. You can distribute this software in its original form with any other products or stand alone.
3. You are not allowed to use this script library for creating any other software or plugin without expressed permission from us.
4. The software is protected by the copyright laws of the U.S. and other countries, and we retain all intellectual property rights in the software. You may not separately publish, sell, market, distribute, lend, lease, rent, modify, reverse engineer or sublicense the software code.
5. You must not make any modification to the software without express permission from us. If there is a feature you want included or a bug you want fixed, let us know.
Such a license is clearly incompatible with the GPL, and any plugin released under such a license should never be allowed in the WordPress repository.
The MBP plugins circumvent the built-in plugin-update functionality of WordPress, and instead query the MBP web site for updates. Consider the following update function from the Multi Author Comment Notification plugin:
function mcnExtractUpdateData() {
$arr = array();
$version_chk_file = "http://www.maxblogpress.com/plugin-updates/multi-author-comment-notification.php?v=".MCN_VERSION;
The plugin then uses this version check to determine if an update is available, downloads the update, and installs it - entirely circumventing the WordPress repository.
All MBP plugins have this same functionality. Thus, essentially, the plugins are using the WordPress repository merely as a listing site - a means to allow users to search for their plugins (or tags/keywords for their plugins) in order to get more exposure and more users installing their plugins.
Such exposure is intended to be a benefit of hosting a plugin on the WordPress repository, not the sole purpose - which is why the guidelines explicitly state that the repository is for hosting, not merely for listing.
But to go even further, some MBP plugins - including Stripe Ad - place a publicly visible "powered by MaxBlogPress" text/link, which explicitly violates WordPress repository guideline #4. And to make matters worse, the author actively seeks to enforce his non-GPL license to prevent users from removing such text from the front end of their blogs:
No it’s NOT licensed under GNU GPL. We are using that format of readme.txt as most people are familiar with that.
It’s illegal to remove the powered by link without notifying me about that.
While the response from WordPress was the removal of the MBP plugins from the WordPress repository, I decided to respond on my own.
When the news broke, several people suggested that the plugins should be forked, to remove the offending code. I thought that this suggestion would make for a good challenge, so I undertook it.
As it turns out, removing the offending code from the plugins proved to be incredibly easy. Thus, forks of Favicon, Ping Optimizer, Multi Author Comment Notification, and Different Posts Per Page are now available from the WordPress repository.
Further, as pointed out by Blogging Pro (linked above), making the MBP plugins think that they are activated is as easy as updating a single database option for each plugin. It seemed like it would be fairly easy to loop through each plugin's option, and set it to the appropriate value, and I thought that some enterprising plugin author should whip up a plugin to do so.
As it turns out, I ended up being that plugin author (with a great deal of help from my friends at the WPTavern forum). As a result, I have also released cbnet MBP Auto-Activate, which, when installed, will determine which MBP plugins are installed, and automatically activate them, without needing to register or subscribe to the email list. The plugin will auto-activate any MBP plugins subsequently installed, also.
If you use MBP plugins, please let me know if you find any of these plugins to be useful. And if I can improve them, please let me know that, as well.
The latest version of WordPress, 2.7, was released earlier this week. The release, code/nick-named "Coltrane", brings several major back-end improvements:
Lorelle lists several reasons to upgrade immediately. Ryan Boren discusses the release, including what features were moved to the 2.8 (or later) blueprint. He also notes that WordPress 2.7 was downloaded 100,000 times in the first 20 hours after release (the counter reads 195,849 downloads at the time of this post), and that some bug fixes are already making it into the planned 2.7.1 release.
I upgraded late last night, and the upgrade went apparently smoothly. As always, let me know if you notice anything amiss. I will be working on some of the new features, such as nested/paged comments, in the near future.
The WordPress Development blog announced today's release of WordPress 2.6. Lots of (mostly incremental) changes; see the following video:
Download WordPress 2.6 today.
Also, be sure to let me know if anything seems broken here after the upgrade.
WordPress 2.5.1 has been released. This version is a security and bug-fix release.
Version 2.5.1 of WordPress is now available. It includes a number of bug fixes, performance enhancements, and one very important security fix. We recommend everyone update immediately, particularly if your blog has open registration. The vulnerability is not public but it will be shortly.
Some of the listed improvements include:
Upgrade, if you haven't already.
Consider two recent bits of news from Microsoft:
What do these mean? Two things: Microsoft recognizes that Vista has not been well-received in the market, and Microsoft recognizes an emerging threat from Linux.
Consider the various markets for computers: enterprise (corporate) systems, high-end (gaming, graphic design, etc.) systems, standard consumer systems, and ultra-low-cost PC (ULCPC) systems. Other niche markets also exist, as well.
Even more than a year after its release, Vista has not been well-received in any of these markets. By all accounts, the corporate adoption rate has been dismal. Due to hardware/software compatibility issues, users of high-end systems likewise have stuck with Windows XP. ULCPCs do not meet the system requirements for Vista. The other niche markets include MacOS and Linux users who don't use any version of a Microsoft operating system.
This scenario leaves the standard consumer system market as the only viable growth option for Vista. This market includes the pre-configured computers purchased through retail outlets or manufacturers' direct-sale web sites. The vast majority of Microsoft's claimed, more than one hundred million Vista license sales come from this market. However, consumer backlash against pre-installed Vista has led to a resurgence of sorts in sales of Windows XP installation media. Windows Vista has trailed Windows XP in these so-called boxed-copy sales from the week Vista was released - and many of those XP copies are being installed over pre-installed Vista.
Microsoft's business model for Windows depends upon the operating system becoming a commodity - that is, for the average computer user, Windows equals computer use, and computer use means Windows.
In this model, corporations standardize on Windows, and follow the upgrade path defined by Microsoft: when Microsoft releases a new OS, corporations dutifully upgrade their systems all at once. In the consumer market, the business model assumes first that users will view the operating system as an unchangeable part of the computer, and second, that those users will replace their systems every 2-3 years, by purchasing another pre-configured computer at retail.
Similar to Microsoft's Office business model, in which Microsoft ensured product lock-in by creating an environment in which their proprietary document format was used by 99% of productivity suite users, Microsoft's Windows business model ensured product lock-in by creating dependency on Windows-only third-party applications and by creating an environment in which consumers could only purchase PCs with Windows pre-installed.
Previous threats to this business model have been relegated to servers, high-end systems, and certain niche markets: Linux is incredibly popular in the server market, MacOS owns the market of those for whom their computer is a fasion statement or status symbol, the computer-geek market often favors GNU/Linux, etc.
However, the emergence of the nascent ULCPC market poses a serious threat to Microsoft's Windows business model. ULCPCs appeal to lower-income PC owners in the US and Europe (the largest PC markets), but are also being targeted at impoverished and third-world communities - especially as an educational tool for children in those communities (see: OLPC and similar projects). These ULCPCs open up a market segment that could, theoretically, dwarf either the corporate or consumer market segments; not to mention, the ULCPC would have an impact on at least the consumer market segment, given its attractive price.
This emerging market would not threaten Microsoft's business model, were it not that almost all such PCs currently come pre-installed not with a Microsoft operating system, but rather with GNU/Linux. These PCs favor Linux for two reasons:
Thus, the ULCPC market segment poses a serious threat to Microsoft's market share. This short-term threat, if realized, would have long-term impact on Microsoft's Windows business model.
Should Linux-based ULCPCs become the norm, then what is potentially the largest market segment would be brought up in an environment in which Microsoft Windows is not equivalent with computer use. If the ULCPC brings the computer to those segments of the world population that could not otherwise afford a computer, then this entire population would be brought up in this non-Microsoft Windows environment.
Currently, one of the most popular ULCPCs is the EeePC, sold by Asus. This computer has proven to be popular: sales are expected to be around four million units for 2008 - and while Asus now makes a Windows XP model, the EeePC originally only came pre-installed with Linux. Granted, Asus expects the XP model to take up about 60% of expected 2008 sales, but that still leaves 40% - or nearly two million units - of those sales for Linux-based units.
Microsoft has conceded that increasing Linux pre-installation poses a threat to its Windows market share, due primarily to the ULCPC market. (Linux pre-installation in the consumer market segment, while not insignificant, still remains a niche. It may yet pose a threat to Microsoft's dominant market share, but that outcome will take significant time.) Note that, in order to break into the ULCPC market, Microsoft had to make two important concessions: Microsoft first had to offer discount XP licenses to ULCPC manufacturers, and then had to extend the end-of-life date for XP at least another year.
Microsoft has found itself caught in an untenable situation: take reduced profits (due to licensing discounts) on OEM sales of a product the company wants to end-of-life (Windows XP), in order to prevent a potential hemorrhage of market share, meanwhile trying to cut losses on the product into which the company has most heavily invested in the past seven years, but which has been mostly rejected by the market (Windows Vista) - all while being forced to put all long-term hope in a product the company must now rush to get out the door early in order to stem the tide (Windows 7).
Microsoft is facing a complete upheaval of its operating-system business model. Could this scenario be the reason that Microsoft is all of a sudden so interested in buying Yahoo?