[theme-reviewers] Formal Request for Change of Methodology.

Wed Jun 26 05:35:47 UTC 2013

i.e. don't even give it a second glance, that's a feature of the theme

-----Original Message----- 
From: Philip M. Hofer (Frumph)
Sent: Tuesday, June 25, 2013 10:35 PM
To: theme-reviewers at lists.wordpress.org
Subject: Re: [theme-reviewers] Formal Request for Change of Methodology.

There's no question about it, as long as it passes the theme unit test with
default settings it would pass right?

-----Original Message----- 
From: Daniel
Sent: Tuesday, June 25, 2013 10:31 PM
To: theme-reviewers at lists.wordpress.org
Subject: Re: [theme-reviewers] Formal Request for Change of Methodology.

What about themes like my one where you can remove the header and
footer because your using a bridge like wp-united? Where do those sort
of things come into play?

On Wed, Jun 26, 2013 at 3:29 PM, Philip M. Hofer (Frumph)
<philip at frumph.net> wrote:
> These are features of a theme, the shortcodes and more are 'features' of 
> the
> theme.
>
> If they use the theme and use those shortcodes, then that is the theme 
> that
> is using it, to require shortcodes to be cross compatible and in a plugin 
> is
> simply ridiculous.
>
> The end user, while picking a theme will choose a theme that has features
> that they want.   When they choose another theme that doesn't have those
> previous themes features they miss out, it's not a question of requiring a
> compatibility.
>
> This also goes with themes that have specialty programming in the way of
> custom post types and the like. - again the data is not lost, it's still
> there, just switching to a different theme will not grant access to it.
>
> The age of feature rich themes and innovation should be promoted not
> stifled.
>
>
> -----Original Message----- From: Harish
> Sent: Tuesday, June 25, 2013 10:24 PM
> To: theme-reviewers at lists.wordpress.org
> Subject: Re: [theme-reviewers] Formal Request for Change of Methodology.
>
>
> Good suggestions by Philip (Frumph) however I have to disagree with:
>
> " the idea that a theme must adhere and be cross compatible with other
> themes in features is a nuance that is unnecessary to worry about."
>
> Themes do not have to be cross compatible with other themes, but they 
> should
> not be the cause of the end user losing data when changing their themes.
>
> 2 of the most common issues are shortcodes and custom meta boxes where the
> key  has "_" in front to hide it from the custom meta fields section.
>
> If theme developers are worried of making things easier for the end user,
> most of these things should not have been in the theme in the first place.
>
>
>
> Regards,
> Harish
>
>
> -----Original Message-----
> From: theme-reviewers [mailto:theme-reviewers-bounces at lists.wordpress.org]
> On Behalf Of Philip M. Hofer (Frumph)
> Sent: Wed 26 June 13 10:41 AM
> To: theme-reviewers at lists.wordpress.org
> Subject: [theme-reviewers] Formal Request for Change of Methodology.
>
> 1) Remove all requirements and recommendations, change it all to 'best
> practices', do not remove anything in the codex just yet.
>
> 2) Theme review process.
> * Theme reviewers tag a theme for review. / It already passed the upload
> checker
> * Check theme with the other plugin(s)[1] available for development, check
> it for notices, warnings, fatals and deprecation messages, Pass/Fail
> * Check theme with theme unit test.  Pass/Fail
> * Review the tags, website links, theme name.  Pass/Fail
>
> It's done, it's reviewed, it's over, if it passed all of those, flag it as
> passing review and live.
>
> 3) Anything else missing on the above list that is a MUST should be added 
> to
> the list but only if it's a MUST, and can't go live no exception.
>
> [1] Make the plugins work for the theme review team; add common security
> problems, etc.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> This is it, this is all that is needed.     Everything else is icing on 
> the
> cake for best practices.
>
>
> Themes are the 'meat and potatoes' of WordPress, the idea that a theme 
> must
> adhere and be cross compatible with other themes in features is a nuance
> that is unnecessary to worry about.   Plugins are made to enhance themes;
> if a plugin doesn't work with a theme the community WILL contact the 
> author;
>
> they always do.   As long as the theme is up to date with core coding 
> which
> all of the tools at our disposal make you aware of - of which even the
> messages from core will also state things it is unnecessary to do anything
> otherwise.
>
> // not sure about
> Not sure what Nacin wrote in entirety on the Make site, but having the
> themes that are live and pass the upload process and immediately go live
> again would be a boon; that basically makes it like the theme developer 
> has
> svn access, without having svn access.
>
>
>
>
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
_______________________________________________
theme-reviewers mailing list
theme-reviewers at lists.wordpress.org
http://lists.wordpress.org/mailman/listinfo/theme-reviewers

_______________________________________________
theme-reviewers mailing list
theme-reviewers at lists.wordpress.org
http://lists.wordpress.org/mailman/listinfo/theme-reviewers 