Regarding phase two, in theory we could comply with the rules by including just two plugins?
The way I was thinking about doing it was having a standard functions plugin that houses the “core” of our theme’s functionality (as an example, all of the Bootstrap element shortcodes which are the same on each theme).
And then a second one to include additional functionality specific to that theme (i.e. a portfolio custom post type and its associated shortcodes, plus any other specific post types).
Would that be acceptable?
Just so I understand clearly, the first phase only affects the “simple” standards changes (i.e. media queries at bottom of CSS, validation, using correct WP standards) and issues such as moving shortcodes/post types to plugins is phase two?
It wasn’t overly cleary in the post, so just wanted to confirm. I assume I read it right, as there was no real clarification on things like page builders which would’ve been required if it was a set-in-stone requirement in phase one.
Smartik saidAgreed. My suggestion would be to require all themes to run in strict mode. Never encountered a script that passes jshint. Not even wordpress core or jQuery itself
JSHint should be excluded from requirements list…
+1, JSHint is way over the top and unless there’s a serious JS error in there it doesn’t matter too much.
I could be wrong but I don’t think I saw it on the list, if we’re getting all technical with keeping things that WP does as standard in our themes then one thing I think needs adding:
Keeping classes on default WP functionality. For example, you occasionally see themes that forget to include %2$s on the sidebar classes, which I imagine is something that should be enforced.
I know Japh said it would be a few days, but just wondering if we have a more concrete date/time for the final confirmed requirements?
It’s now starting to hold back the development of a new theme we’re working on as I don’t particularly want to do it one way, and then have to change it all to adhere to the new requirements.
aleluja saidNothing is left to luck here. If TF can enforce plugins they can enforce standards for naming.
Well until there are standards for the naming it should’t be let to luck. I (and themeforest and wordpress community) don’t want to take a risk between losing access to data and having everything work nicely. I agree it would be super-awesome but currently it’s just too risky.
I believe the idea is that themes in future should play nicely with all WP themes, including ones from WP.org and other sites. Therefore enforcing a naming convention wouldn’t work for obvious reasons.
This looks interesting, as someone previously said – some more screenshots would be great!
ZOMG, huge step for ThemeForest! Haven’t read all this thread, but I’d like to suggest a “Certified” stamp of some sort for the themes which passed the requirements.
All new themes (and eventually all TF WP themes) must adhere to the rules, so the stamp would be fairly pointless
“since when do the plugin developers make rules for us, the theme developers?”. Time to get off your high horse and gain a little humility. Plugin developers don’t make rules for theme developers and theme developers don’t make rules for plugin developers. The community builds rules and guidelines for everyone.
“The commuity” being the WordPress community?
Envato isn’t bound to the WordPress community’s rules, nor do they have any obligation (as far as I am aware) to adhere to the community guidelines set out by the WordPress community.
Is it possible through TGM to automatically install and activate the plugins with the theme activation with the choice of user’s being able to disable them from the plugins option? Is that allowed or possible?
They won’t automatically install, but a banner will appear saying they are required by the theme for functionality, with a link to install them (either from included package, or the WP.org repository, presently).
I think the idea was that during theme activation, it would automagically install any required plugins that were not currently installed.