<div dir="ltr"><div><div><div><div><div><div>Well, while I do think there should be flexibility is what exactly is or isn't plugin territory, I would say:<br><br></div>Get over it. It isn't trivial, but it isn't that hard. Build a plugin for your theme's "plugin territory" features. And even better, try to make the plugin support other themes as well - that is real service to your customers.<br>
<br></div>And after some thinking on this, I believe there is a pretty good, technical rule for at least some things that are absolutely theme territory:<br><br></div>If a feature would require manually adding specific php code, a do_action/filter, or cannot be done via an add_action/filter or enqueue of WP core actions/filters to any theme's code, then it is a theme feature. While there are many plugins that do some things (blog post page navigation, for example) very well, many require direct theme support or having the user add code to the theme. Obviously, these are theme territory.<br>
<br></div>I would also contend that other features that require specific CSS or output ordering to match the theme's design should also be theme territory, even if it happens that the best implementation of the feature is by shortcode or could be handled by an add_action (social icons, iOS icons, or even favicon come to mind - what is more design specific than a set of icons?). It could be argued that this could be implemented via a theme specific companion plugin, but does that really help the theme switching?<br>
<br></div>But for the rest, give now non-complying themes some time - 3 months? (Remember, most of the now non-compliant themes were compliant when first approved!)<br><br></div>Bruce Wampler<br><div><br><br><div><div><div>
<div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote"><br></div><br></div></div></div></div></div></div></div></div></div>