[theme-reviewers] Bundling Plugins

Chip Bennett chip at chipbennett.net
Mon May 2 14:15:51 UTC 2011


That's a good distinction: simply bundling "plugin.zip" into the Theme is,
IMHO, absolutely inappropriate. Simply add installation instructions that
the Theme relies on "Plugin X', and to install the Plugin from the
repository. Also, in all instances, any Theme dependent upon a Plugin MUST
degrade gracefully, such that it functions acceptably without the Plugin.

As to what Plugin code is suitable for incorporation: I think that, as long
as the functionality is Theme-related (and, clearly, SEO functionality IS
Theme-related, since SEO is entirely Theme-dependent), it is fair game. But,
the Theme developer who chooses to incorporate such functionality into the
Theme then bears the burden of fully maintaining that incorporated code. It
is an issue for the Theme Review Team, since we then take on the burden of
reviewing such extra functionality - but then, in the end, that's our job.

On the other hand, just as we exclude non-Theme-related functionality as
"Plugin territory", I think we should hold the same standard for
incorporated Plugins. To be explicit: Theme functionality should involve the
*presentation* of content; anything that involves the *creation* or
*management* of content should be left to Plugins.

Also, regarding "best practices", I will add: I think the "best practice"
recommendation should be that Themes, if they choose, should incorporate
*support* for a given Plugin, rather than incorporating the Plugin code
itself. One example might be the WP-PageNavi Plugin, which can be supported
as easily as adding:

if ( function_exists( 'wp_paginate' ) ) {
	wp_paginate( 'title=' );
} else {
	*// do something else instead*
}


Or, for Yoast Breadcrumbs:

if ( function_exists('yoast_breadcrumb') ) {
	yoast_breadcrumb('<li id="breadcrumbs">','</li>');
} else {
	// do something else instead
} ?>


This method allows for graceful degradation, and does not encumber the Theme
developer with maintaining someone else's code.

Chip

On Mon, May 2, 2011 at 8:57 AM, Ryan Hellyer <ryan at pixopoint.com> wrote:

> There are situations in which it makes sense to build a theme which relies
> on specific plugins to function, but it is often not a good idea to
> incorporate the entire code base into the theme since the plugin may be
> under active development. In this situation I tend to have the plugin
> automatically install and activate the plugin(s). I think it would be a good
> idea if this sort of situation was allowed in the theme repository.
>
> Simply bundling the plugins zip file into the theme and requiring the user
> to copy the files over seems counter productive though and shouldn't be
> allowed IMO since the user could just as easily get the plugin from the
> repository instead.
>
> There are some excellent themes in the repository which incorporate large
> amounts of "plugin like" functionality so I would assume that seamlessly
> integrated functionality would be deemed appropriate for the repository.
>
> Just taking something like Yoasts SEO plugin and dumping it verbatim into a
> theme would be plain weird and shouldn't be allowed though IMO, as it would
> include a bunch of text unrelated to the theme and create confusion for the
> user. However if it were integrated seamlessly and cleanly, then I don't see
> any problems with that approach, albeit I personally would never roll that
> much SEO functionality into a theme.
>
> Ryan,
>
>
>
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20110502/929b09d4/attachment-0001.htm>


More information about the theme-reviewers mailing list