<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Make WordPress Themes &#187; discussion</title>
	<atom:link href="http://make.wordpress.org/themes/tag/discussion/feed/" rel="self" type="application/rss+xml" />
	<link>http://make.wordpress.org/themes</link>
	<description>Just another make.wordpress.org site</description>
	<lastBuildDate>Wed, 05 Jun 2013 15:29:39 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.6-beta3-24432</generator>
	<atom:link rel='hub' href='http://make.wordpress.org/themes/?pushpress=hub'/>
		<item>
		<title>query_posts()</title>
		<link>http://make.wordpress.org/themes/2012/12/14/query_posts/</link>
		<comments>http://make.wordpress.org/themes/2012/12/14/query_posts/#comments</comments>
		<pubDate>Fri, 14 Dec 2012 15:21:56 +0000</pubDate>
		<dc:creator>Chip Bennett</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[discussion]]></category>
		<category><![CDATA[Guidelines]]></category>

		<guid isPermaLink="false">http://make.wordpress.org/themes/2012/12/14/query_posts/</guid>
		<description><![CDATA[While the clock has started ticking on the 3.5 release grace period for Guidelines updates, I would like to discuss formalizing one other _doing_it_wrong() issue that has been implicitly enforced for some time now: use of query_posts(). Would anyone be opposed if we formally added query_posts() to Theme Check as a required stopper? To understand [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>While the clock has started ticking on the 3.5 release grace period for Guidelines updates, I would like to discuss formalizing one other <code>_doing_it_wrong()</code> issue that has been implicitly enforced for some time now: use of <code>query_posts()</code>.</p>
<p>Would anyone be opposed if we formally added <code>query_posts()</code> to Theme Check as a <strong>required</strong> stopper?</p>
<p>To understand why <code>query_posts()</code> is always inherently <code>_doing_it_wrong()</code>, see <a href='http://make.wordpress.org/themes/mentions/nacin/' class='mention'>@nacin</a>&#8216;s WordCamp presentation <a href="http://www.slideshare.net/andrewnacin/you-dont-know-query-wordcamp-portland-2011"><em>You Don&#8217;t Know Query</em></a>, and <a href="http://wordpress.stackexchange.com/a/1755/3966">this great WordPress StackExchange answer</a> by @rarst.</p>
<p>In short, if you are creating secondary queries, you should use <code>WP_Query()</code>, and if you&#8217;re modifying the main query, you should filter <code>pre_get_posts</code>.</p>
<p>Thoughts?</p>
]]></content:encoded>
			<wfw:commentRss>http://make.wordpress.org/themes/2012/12/14/query_posts/feed/</wfw:commentRss>
		<slash:comments>60</slash:comments>
		</item>
		<item>
		<title>Follow-Up: Theme Obsolescence Guideline</title>
		<link>http://make.wordpress.org/themes/2011/01/24/follow-up-theme-obsolescence-guideline/</link>
		<comments>http://make.wordpress.org/themes/2011/01/24/follow-up-theme-obsolescence-guideline/#comments</comments>
		<pubDate>Mon, 24 Jan 2011 14:48:34 +0000</pubDate>
		<dc:creator>Chip Bennett</dc:creator>
				<category><![CDATA[post]]></category>
		<category><![CDATA[discussion]]></category>
		<category><![CDATA[Guidelines]]></category>
		<category><![CDATA[obsolescence]]></category>

		<guid isPermaLink="false">http://make.wordpress.org/themes/2011/01/24/follow-up-theme-obsolescence-guideline/</guid>
		<description><![CDATA[I haven&#8217;t yet seen any discussion of this point in Phil&#8217;s post below, so I wanted to highlight it again: Some of the review team have brought it up that there should be a time limit for non-updated themes, our general consensus is 2 or 3 major revisions of WordPress before suspension for not keeping [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>I haven&#8217;t yet seen any discussion of this point in <a href="http://make.wordpress.org/themes/2011/01/21/obsolete-no-longer-active-themes-discussion/">Phil&#8217;s post below</a>, so I wanted to highlight it again:</p>
<blockquote><p>Some of the review team have brought it up that there should be a time limit for non-updated themes, our general consensus is 2 or 3 major revisions of WordPress before suspension for not keeping themes updated. What this means that currently we’re on WordPress 3.0 previous to that was 2.9, 2.8 which is 2, 2.7 being 3 revisions previous, all themes that are prior to 2.7 (or 2.8) should be suspended as being currently obsolete.</p></blockquote>
<p>To be clear, the Theme Review Team is formally proposing an obsolescence Guideline, that <strong>any Theme not updated within 2 (perhaps 3) major releases of WordPress be automatically suspended, until a current version is submitted and approved</strong>.</p>
<p>For example, if this guideline were put into place with a timeline of 3 major WordPress releases, when WordPress 3.1 is released, all Themes not updated since before the release of WordPress 2.8 (i.e. since June 2009) would be blanket-suspended.</p>
<p>Or, if this guideline were put into place with a timeline of 2 major WordPress releases, when WordPress 3.1 is released, all Themes not updated since before the release of WordPress 2.9 (i.e. since December 2009) would be blanket-suspended.</p>
<p>We very much want input and feedback on this proposal. Would this guideline generally help or hurt &#8211; improve or worsen &#8211; the Theme Repository? Is the proposed timeline (2 or 3 major WordPress releases, which translates into, generally speaking, 6 or 9 months) reasonable?</p>
]]></content:encoded>
			<wfw:commentRss>http://make.wordpress.org/themes/2011/01/24/follow-up-theme-obsolescence-guideline/feed/</wfw:commentRss>
		<slash:comments>26</slash:comments>
		</item>
		<item>
		<title>Discussion &#8211; Child Themes on the Repository &#8211; Guidelines</title>
		<link>http://make.wordpress.org/themes/2011/01/24/discussion-child-themes-on-the-repository-guidelines/</link>
		<comments>http://make.wordpress.org/themes/2011/01/24/discussion-child-themes-on-the-repository-guidelines/#comments</comments>
		<pubDate>Mon, 24 Jan 2011 09:10:25 +0000</pubDate>
		<dc:creator>Frumph</dc:creator>
				<category><![CDATA[post]]></category>
		<category><![CDATA[Child-Theme]]></category>
		<category><![CDATA[discussion]]></category>
		<category><![CDATA[Guidelines]]></category>

		<guid isPermaLink="false">http://make.wordpress.org/themes/2011/01/24/discussion-child-themes-on-the-repository-guidelines/</guid>
		<description><![CDATA[1) Parent themes of child themes that are developed need to be made child-theme ready; proper use of where to find files with get_template_part, get_stylesheet_ and get_template_ functions. 2) http://codex.wordpress.org/Child_Themes documentation is applied as part of the theme review process when checking child themes, all information is to be considered good practice and required, with [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>1) Parent themes of child themes that are developed need to be made child-theme ready; proper use of where to find files with get_template_part, get_stylesheet_ and get_template_ functions.<br />
2) <a href="http://codex.wordpress.org/Child_Themes" rel="nofollow">http://codex.wordpress.org/Child_Themes</a> documentation is applied as part of the theme review process when checking child themes, all information is to be considered good practice and required, with addition to the theme review representation of license information.<br />
3) Parent themes of child themes submitted must have passed the current theme review guidelines for the current revision of WordPress, not if they have passed before, but specifically with the current revision of WordPress.<br />
4) Child themes are reviewed with the parent theme; must pass current theme review guidelines and associated child theme documentation.<br />
5) Recommendation to use the parent themes repository slug as the prefix to the child theme&#8217;s name.  ex. easel-highsociety,  atahualpa-wired, this is only the name of the theme &amp; directory name of theme in the zip, not where to find the theme; even as found in the <a href="http://codex.wordpress.org/Child_Themes" rel="nofollow">http://codex.wordpress.org/Child_Themes</a> being part of the review process, this naming convention will stay a recommendation; however, declared best-practice.<br />
6) Description in the style.css must clearly state that it is a child theme example: &#8220;This is a child theme for the Easel theme.&#8221; &#8211; This is for redundancy of recognition that it is a child theme, even though other things will be noted on the repository that it is a child theme, this is for the wp-admin -&gt; themes page for the end user.</p>
<p>Additional For Developers:<br />
1) It is the responsibility of the developer of child themes to keep their child themes up to date with the current revision of their theme that is updated.   If a developer make changes to the parent theme, it is the developers responsibility to keep the child themes updated as well.</p>
<p>Changes, word usage, additional guidelines and protocols, as well as information regarding use of child-theme tag requested as part of this discussion.</p>
]]></content:encoded>
			<wfw:commentRss>http://make.wordpress.org/themes/2011/01/24/discussion-child-themes-on-the-repository-guidelines/feed/</wfw:commentRss>
		<slash:comments>19</slash:comments>
		</item>
	</channel>
</rss>
