<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Rude Things Plugins Can Do</title>
	<atom:link href="http://digwp.com/2009/10/rude-things-plugins-can-do/feed/" rel="self" type="application/rss+xml" />
	<link>http://digwp.com/2009/10/rude-things-plugins-can-do/</link>
	<description>Take your WordPress skills to the next level.</description>
	<lastBuildDate>Tue, 15 May 2012 08:36:23 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: Michael Torbert</title>
		<link>http://digwp.com/2009/10/rude-things-plugins-can-do/#comment-3008</link>
		<dc:creator>Michael Torbert</dc:creator>
		<pubDate>Tue, 05 Jan 2010 18:03:57 +0000</pubDate>
		<guid isPermaLink="false">http://digwp.com/?p=627#comment-3008</guid>
		<description>Oh I see, it only goes to the third level.  Feel free to edit that part out and to delete this comment.
:)</description>
		<content:encoded><![CDATA[<p>Oh I see, it only goes to the third level.  Feel free to edit that part out and to delete this comment.<br />
:)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Torbert</title>
		<link>http://digwp.com/2009/10/rude-things-plugins-can-do/#comment-3007</link>
		<dc:creator>Michael Torbert</dc:creator>
		<pubDate>Tue, 05 Jan 2010 18:02:00 +0000</pubDate>
		<guid isPermaLink="false">http://digwp.com/?p=627#comment-3007</guid>
		<description>Chris,
Your welcome.  I&#039;m aware of how it looks, and I understand that it&#039;s annoying for some users.  I spent a lot of time thinking about it and consulted with a number of other people in the community when contemplating the decision about what to do.
Unfortunately, in this case there was no way to make everyone happy, so I sided with ensuring that nobody could ever say (even if incorrectly as was the case) that new features introduced caused harmful effects to their sites SEO.
Part of the thinking was that, unlike most other plugins which have immediately obvious effects of any configuration changes, AIOSEOP configuration changes may be tucked away in the source (which your average user won&#039;t notice) and the visible effects (SERPS) may not be apparent for some time.  This gives everyone an opportunity make the needed (if any) changes.
One example of this is canonical URLs (the introduction of which).  I added canonical URL support not quite a year ago, and now WordPress 2.9 has it built in.  AIOSEOP will automatically override the WP canonical URL and use its own method if you so choose, or it can fall back on WP&#039;s.  Depending on what plugins a person is running, using the WP canonical URL can be very very bad for your site, and when 2.9 was about to come out, I had to make changes to compensate for this, and it was very important that users know about the issue so that they can make a decision.  People will complain about having to reactivate the plugin, but I&#039;d rather have them fuss at me about that then have them fuss that they didn&#039;t know about the new WP and/or AIOSEOP settings which potentially caused harm to their site&#039;s SERPS.
It was a tough decision to make, and obviously everyone won&#039;t be happy regardless of which path I took, but I&#039;ve always tried to do what is in the best interest of users.
(Maybe I should write a better post explaining all this.)

Sorry about the misplacement of this comment, but for some reason there&#039;s no reply button under your reply to me. :)</description>
		<content:encoded><![CDATA[<p>Chris,<br />
Your welcome.  I&#8217;m aware of how it looks, and I understand that it&#8217;s annoying for some users.  I spent a lot of time thinking about it and consulted with a number of other people in the community when contemplating the decision about what to do.<br />
Unfortunately, in this case there was no way to make everyone happy, so I sided with ensuring that nobody could ever say (even if incorrectly as was the case) that new features introduced caused harmful effects to their sites SEO.<br />
Part of the thinking was that, unlike most other plugins which have immediately obvious effects of any configuration changes, AIOSEOP configuration changes may be tucked away in the source (which your average user won&#8217;t notice) and the visible effects (SERPS) may not be apparent for some time.  This gives everyone an opportunity make the needed (if any) changes.<br />
One example of this is canonical URLs (the introduction of which).  I added canonical URL support not quite a year ago, and now WordPress 2.9 has it built in.  AIOSEOP will automatically override the WP canonical URL and use its own method if you so choose, or it can fall back on WP&#8217;s.  Depending on what plugins a person is running, using the WP canonical URL can be very very bad for your site, and when 2.9 was about to come out, I had to make changes to compensate for this, and it was very important that users know about the issue so that they can make a decision.  People will complain about having to reactivate the plugin, but I&#8217;d rather have them fuss at me about that then have them fuss that they didn&#8217;t know about the new WP and/or AIOSEOP settings which potentially caused harm to their site&#8217;s SERPS.<br />
It was a tough decision to make, and obviously everyone won&#8217;t be happy regardless of which path I took, but I&#8217;ve always tried to do what is in the best interest of users.<br />
(Maybe I should write a better post explaining all this.)</p>
<p>Sorry about the misplacement of this comment, but for some reason there&#8217;s no reply button under your reply to me. :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Coyier</title>
		<link>http://digwp.com/2009/10/rude-things-plugins-can-do/#comment-3006</link>
		<dc:creator>Chris Coyier</dc:creator>
		<pubDate>Tue, 05 Jan 2010 17:41:25 +0000</pubDate>
		<guid isPermaLink="false">http://digwp.com/?p=627#comment-3006</guid>
		<description>Thanks for the updated on this Michael. I&#039;m going to do a post setting the record straight on this behavior.</description>
		<content:encoded><![CDATA[<p>Thanks for the updated on this Michael. I&#8217;m going to do a post setting the record straight on this behavior.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Torbert</title>
		<link>http://digwp.com/2009/10/rude-things-plugins-can-do/#comment-3005</link>
		<dc:creator>Michael Torbert</dc:creator>
		<pubDate>Tue, 05 Jan 2010 13:36:23 +0000</pubDate>
		<guid isPermaLink="false">http://digwp.com/?p=627#comment-3005</guid>
		<description>Jordan,

You&#039;re correct.  A while back (9 month ago?), a particular site complained that a new feature damaged their site&#039;s search engine results placement.  They finally admitted that they were incorrect in this assumption, and that the cause was something else unrelated to the plugin, but their original assessment was that a new feature hurt them.  
They complained that since most people don&#039;t read my changelog, posts, or check the options page for new options, people won&#039;t know about new settings which could potentially affect their site.
This post, and followup posts on other sites who didn&#039;t read their addendum admitting AIOSEOP was not the cause of their problems, garnered such attention, that it seemed I had to do something so that an issue like that could never actually happen where someone&#039;s site really is negatively affected just because they aren&#039;t aware of new options.  
From then on, any update which introduces new options (not just behind the scenes changes) require the user to reactivate the plugin from the settings page, to make sure that they can review the options.</description>
		<content:encoded><![CDATA[<p>Jordan,</p>
<p>You&#8217;re correct.  A while back (9 month ago?), a particular site complained that a new feature damaged their site&#8217;s search engine results placement.  They finally admitted that they were incorrect in this assumption, and that the cause was something else unrelated to the plugin, but their original assessment was that a new feature hurt them.<br />
They complained that since most people don&#8217;t read my changelog, posts, or check the options page for new options, people won&#8217;t know about new settings which could potentially affect their site.<br />
This post, and followup posts on other sites who didn&#8217;t read their addendum admitting AIOSEOP was not the cause of their problems, garnered such attention, that it seemed I had to do something so that an issue like that could never actually happen where someone&#8217;s site really is negatively affected just because they aren&#8217;t aware of new options.<br />
From then on, any update which introduces new options (not just behind the scenes changes) require the user to reactivate the plugin from the settings page, to make sure that they can review the options.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Vern</title>
		<link>http://digwp.com/2009/10/rude-things-plugins-can-do/#comment-2263</link>
		<dc:creator>Vern</dc:creator>
		<pubDate>Mon, 09 Nov 2009 19:51:22 +0000</pubDate>
		<guid isPermaLink="false">http://digwp.com/?p=627#comment-2263</guid>
		<description>I just saw that &quot;removal&quot; plugin to day for the first time.  But I came across another &quot;first&quot; today too ...  A plugin where the author has row after row of advertising (I mean 300x200 boxes!) And then a section with about 7 &quot;shoutouts&quot;, which looks like his entire link roll.  

This is absolutely too much crap added to our Admin panel.  Plus, it seems to me it adds another layer of security risk.  

I appreciate the work that goes into developing plugins, and I don&#039;t mind receiving a request for donations, but I really wish there were some etiquette rules for plugin authors.</description>
		<content:encoded><![CDATA[<p>I just saw that &#8220;removal&#8221; plugin to day for the first time.  But I came across another &#8220;first&#8221; today too &#8230;  A plugin where the author has row after row of advertising (I mean 300&#215;200 boxes!) And then a section with about 7 &#8220;shoutouts&#8221;, which looks like his entire link roll.  </p>
<p>This is absolutely too much crap added to our Admin panel.  Plus, it seems to me it adds another layer of security risk.  </p>
<p>I appreciate the work that goes into developing plugins, and I don&#8217;t mind receiving a request for donations, but I really wish there were some etiquette rules for plugin authors.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Ivany</title>
		<link>http://digwp.com/2009/10/rude-things-plugins-can-do/#comment-2070</link>
		<dc:creator>Jeff Ivany</dc:creator>
		<pubDate>Tue, 20 Oct 2009 13:21:28 +0000</pubDate>
		<guid isPermaLink="false">http://digwp.com/?p=627#comment-2070</guid>
		<description>That depends on how much you want it.  Technically, you could take any plugin, modify it to remove any of the  &#039;junk&#039; and release it yourself.  Everything in WP is Open Source and thus you are able to do this.  Now, you might really tick off the original author and they might throw a hissy fit which could lead to the original plugin being abandoned.</description>
		<content:encoded><![CDATA[<p>That depends on how much you want it.  Technically, you could take any plugin, modify it to remove any of the  &#8216;junk&#8217; and release it yourself.  Everything in WP is Open Source and thus you are able to do this.  Now, you might really tick off the original author and they might throw a hissy fit which could lead to the original plugin being abandoned.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rich</title>
		<link>http://digwp.com/2009/10/rude-things-plugins-can-do/#comment-2069</link>
		<dc:creator>Rich</dc:creator>
		<pubDate>Tue, 20 Oct 2009 13:15:53 +0000</pubDate>
		<guid isPermaLink="false">http://digwp.com/?p=627#comment-2069</guid>
		<description>I know what you mean with the signing up for the author&#039;s newsletter when activating a plugin. DiffPostsPerPage does that. 

Does anyone know an alternative to that plugin? I hate giving my email just to get a dumb plugin.</description>
		<content:encoded><![CDATA[<p>I know what you mean with the signing up for the author&#8217;s newsletter when activating a plugin. DiffPostsPerPage does that. </p>
<p>Does anyone know an alternative to that plugin? I hate giving my email just to get a dumb plugin.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Coyier</title>
		<link>http://digwp.com/2009/10/rude-things-plugins-can-do/#comment-2027</link>
		<dc:creator>Chris Coyier</dc:creator>
		<pubDate>Sun, 18 Oct 2009 15:22:24 +0000</pubDate>
		<guid isPermaLink="false">http://digwp.com/?p=627#comment-2027</guid>
		<description>In my opinion, it should at least by, by default, turned off.</description>
		<content:encoded><![CDATA[<p>In my opinion, it should at least by, by default, turned off.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jonathan Ellse</title>
		<link>http://digwp.com/2009/10/rude-things-plugins-can-do/#comment-2026</link>
		<dc:creator>Jonathan Ellse</dc:creator>
		<pubDate>Sun, 18 Oct 2009 14:21:27 +0000</pubDate>
		<guid isPermaLink="false">http://digwp.com/?p=627#comment-2026</guid>
		<description>Just out of interest, I made a plugin, Submit to Any, and it includes a author linkback but has an option to turn this off. Is that still considered dreadful, and a threat to the wordpress community?

Loving the posts here by the way. So glad you and Jeff decided to make this site.</description>
		<content:encoded><![CDATA[<p>Just out of interest, I made a plugin, Submit to Any, and it includes a author linkback but has an option to turn this off. Is that still considered dreadful, and a threat to the wordpress community?</p>
<p>Loving the posts here by the way. So glad you and Jeff decided to make this site.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cosmin</title>
		<link>http://digwp.com/2009/10/rude-things-plugins-can-do/#comment-2024</link>
		<dc:creator>Cosmin</dc:creator>
		<pubDate>Sun, 18 Oct 2009 12:19:44 +0000</pubDate>
		<guid isPermaLink="false">http://digwp.com/?p=627#comment-2024</guid>
		<description>Oh God how I hate plugins that deactivate themselves. One example would be SexyBookmarks...which is quite nice, but this deactivation gets me everytime I upgrade and I&#039;m looking for another solution.

By the way, you should include another rude thing: &quot;Updates way too often (for any small changes)&quot;</description>
		<content:encoded><![CDATA[<p>Oh God how I hate plugins that deactivate themselves. One example would be SexyBookmarks&#8230;which is quite nice, but this deactivation gets me everytime I upgrade and I&#8217;m looking for another solution.</p>
<p>By the way, you should include another rude thing: &#8220;Updates way too often (for any small changes)&#8221;</p>
]]></content:encoded>
	</item>
</channel>
</rss>

