<?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: WordPress Core vs Canonical Plugins</title>
	<atom:link href="http://bluedogwebservices.com/wordpress-core-canonical-plugins/feed/" rel="self" type="application/rss+xml" />
	<link>http://bluedogwebservices.com/wordpress-core-canonical-plugins/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=wordpress-core-canonical-plugins</link>
	<description>BlueDog Web Services</description>
	<lastBuildDate>Thu, 26 Jan 2012 21:06:46 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
	<item>
		<title>By: Peter Kahoun</title>
		<link>http://bluedogwebservices.com/wordpress-core-canonical-plugins/#comment-475</link>
		<dc:creator>Peter Kahoun</dc:creator>
		<pubDate>Sat, 21 Nov 2009 20:34:32 +0000</pubDate>
		<guid isPermaLink="false">http://bluedogwebservices.com/?p=429#comment-475</guid>
		<description>I also think including (or promoting) feature-packages as separable plugins is the best way to go. (Other option is not to include such plugins into the main wp package but to promote them and offer them to simple automatic installation on the plugins page in administration.) Actually, it&#039;s hard for me to believe WP could turn to approach like this.</description>
		<content:encoded><![CDATA[<p>I also think including (or promoting) feature-packages as separable plugins is the best way to go. (Other option is not to include such plugins into the main wp package but to promote them and offer them to simple automatic installation on the plugins page in administration.) Actually, it&#8217;s hard for me to believe WP could turn to approach like this.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Utahcon</title>
		<link>http://bluedogwebservices.com/wordpress-core-canonical-plugins/#comment-474</link>
		<dc:creator>Utahcon</dc:creator>
		<pubDate>Tue, 14 Jul 2009 17:46:51 +0000</pubDate>
		<guid isPermaLink="false">http://bluedogwebservices.com/?p=429#comment-474</guid>
		<description>One of the greatest advantages of WordPress is the fact that it is so lightweight and open. This is the reason there are so many plugins. By leaving the features to the users and community the WordPress Dev Team can focus on making the core product more reliable, secure, and faster. The users and community can then create a plugin to do anything they would like with the assurance that they don&#039;t have to accept something as, this is the way it is.

I am all for WordPress sponsoring plugins as the semi-official plugins. Meaning these are the plugins most people use, and we will spot check that they still work, but you don&#039;t want the Core Dev Team spending more time making sure they don&#039;t break plugins. That is the job of the developer of the plugin. Automattic has always been open about their process of development and generous in getting betas and RCs available so that developers can in fact test their own plugins against the latest and greatest architecture.

Furthermore the WordPress Dev Team should focus on not breaking current functionality, which would alleviate a lot of the breaking plugins.

Great article.</description>
		<content:encoded><![CDATA[<p>One of the greatest advantages of WordPress is the fact that it is so lightweight and open. This is the reason there are so many plugins. By leaving the features to the users and community the WordPress Dev Team can focus on making the core product more reliable, secure, and faster. The users and community can then create a plugin to do anything they would like with the assurance that they don&#8217;t have to accept something as, this is the way it is.</p>
<p>I am all for WordPress sponsoring plugins as the semi-official plugins. Meaning these are the plugins most people use, and we will spot check that they still work, but you don&#8217;t want the Core Dev Team spending more time making sure they don&#8217;t break plugins. That is the job of the developer of the plugin. Automattic has always been open about their process of development and generous in getting betas and RCs available so that developers can in fact test their own plugins against the latest and greatest architecture.</p>
<p>Furthermore the WordPress Dev Team should focus on not breaking current functionality, which would alleviate a lot of the breaking plugins.</p>
<p>Great article.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

