Last week we announced our newly published and recently updated WordPress theme submission requirements, which raised lots of valuable discussion over in the forum post. The insight everyone provided was valuable and greatly appreciated. It also reminded us that we need to be including more community input, from a wider group, from much earlier stages! Where you provided feedback and it was not taken on board, we also really apologise and hope the clarifications below address your concerns better this time.
The process also made it obvious that we hadn’t been communicating clearly enough at the launch of these submission requirements, which we’ll provide further clarification on here. We will continue working harder at improving our communications, especially from within the Review team and covering all other aspects of review.
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.
So we will be now selling simple themes with bunch of plugins? I guess it might not be a problem for themes from “blog” category, but what about this very niche themes, like for hotels with booking systems, restaurant themes, directory themes etc. I’m pretty sure it will cause more problems than you’re expecting. Imagine you have “directory” theme with full maps support etc, all functionality has to be provided by a plugins, someone buys it, changes the theme, and it works but doesn’t look good for obvious reasons. Who’s now to blame? Author of a original theme/plugin hybrid or author of new theme? It looks for me like we will be changing to ThemeCanyon.
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.
That’s correct. There’s actually clarification if you click through to the requirements themselves, where there is separation between Phase 1 and Phase 2 (where page builders are mentioned).
One thing that still isn’t explained to me clearly is the use of Options plugins. Many authors including myself use plugins to add custom options. e.g OptionTree
How would this be handled for themes using OptionTree?
Can I get an official response on this ASAP so I know what path to take with my theme.
One thing that still isn’t explained to me clearly is the use of Options plugins. Many authors including myself use plugins to add custom options. e.g OptionTree
How would this be handled for themes using OptionTree?
Can I get an official response on this ASAP so I know what path to take with my theme.
Thanks
There is no problem with using an options framework such as OptionTree. It is even listed as allowable under Phase 2 in the requirements article.
Question: What if I use Visual Composer plugin for shortcodes (elements) and want to override some default shortcode outputs and styles with mine? Do I need to create an additional plugin just for that overriding stuff?
Let’s say I want to override the default Tabs shortcode that is, by default, using jQuery UI to use a structure and styles of Zurb Foundation instead. Where should the overriding code reside, in a plugin or theme?
So we will be now selling simple themes with bunch of plugins? I guess it might not be a problem for themes from “blog” category, but what about this very niche themes, like for hotels with booking systems, restaurant themes, directory themes etc. I’m pretty sure it will cause more problems than you’re expecting. Imagine you have “directory” theme with full maps support etc, all functionality has to be provided by a plugins, someone buys it, changes the theme, and it works but doesn’t look good for obvious reasons. Who’s now to blame? Author of a original theme/plugin hybrid or author of new theme? It looks for me like we will be changing to ThemeCanyon.
Not at all.
As an example, there is a real estate plugin in the WordPress.org directory: Some themes will be made to support this and it will work nicely, others will not. This is actually fairly common.
In your example, you could create a plugin that provides all the restaurant functionality for your restaurant theme. If you make a second restaurant theme, you’ll likely use the same plugin. If another theme is used with the plugin, it probably won’t work, as that theme wasn’t created to work with that plugin.
purethemes said
BTW, what about OptionTree that has “theme mode”, does it have to be included via the TGM Plugin Activation class?
One thing that still isn’t explained to me clearly is the use of Options plugins. Many authors including myself use plugins to add custom options. e.g OptionTree
How would this be handled for themes using OptionTree?
Can I get an official response on this ASAP so I know what path to take with my theme.
Thanks
There is no problem with using an options framework such as OptionTree. It is even listed as allowable under Phase 2 in the requirements article.
Hello,
I don’t see this mentioned in the Notes or the official requirements. So can you confirm that Options plugins such as OptionTree and Advanced Custom Fields can be hard coded into the theme and not be included via TGM?
most authors already have built their own frameworks, by moving features into plugins duplicate code will most likely occur: it's safe to assume that this won't be an issue during item review ?
Due the above (common code used by both plugin and theme), some updates may require buyers to update both at the same time. According to direct experience, some buyers will not (for instance they could update theme only) either by mistake or due to technical issues (as in, the plugin update server being down) so we must somehow prevent buyer website from breaking until they do it the proper way. A possible solution could be
to embed plugin code in the theme as well
if plugin is not installed, none of the above code will be ever used
if plugin is installed and version matches, plugin code is used
if plugin is installed but not updated, embedded plugin code is used until the buyer updates (goto 2)
Would the above be acceptable under the new rules ?
I don’t see this mentioned in the Notes or the official requirements. So can you confirm that Options plugins such as OptionTree and Advanced Custom Fields can be hard coded into the theme and not be included via TGM?
Search for “Theme options framework” in the page and you will find it
Advanced Custom Fields is a separate issue, and should be a plugin via the TGM Plugin Activation class.
most authors already have built their own frameworks, by moving features into plugins duplicate code will most likely occur: it's safe to assume that this won't be an issue during item review ?
Due the above (common code used by both plugin and theme), some updates may require buyers to update both at the same time. According to direct experience, some buyers will not (for instance they could update theme only) either by mistake or due to technical issues (as in, the plugin update server being down) so we must somehow prevent buyer website from breaking until they do it the proper way. A possible solution could be
to embed plugin code in the theme as well
if plugin is not installed, none of the above code will be ever used
if plugin is installed and version matches, plugin code is used
if plugin is installed but not updated, embedded plugin code is used until the buyer updates (goto 2)
Would the above be acceptable under the new rules ?
This sounds very reasonable to me. Reviewers will look at these on a case-by-case basis.
Advanced Custom Fields is a separate issue, and should be a plugin via the TGM Plugin Activation class.
Hi Japh, adding ACF as a plugin? If buyer switch to another theme, ACF won’t work anyway. All calls to ACF fields will remane in a previous theme. Also, when ACF is being included in the theme it being used as a Lite Mode, which is defined in functions.php. What to do about that?
Hi Japh, adding ACF as a plugin? If buyer switch to another theme, ACF won’t work anyway. All calls to ACF fields will remane in a previous theme. Also, when ACF is being included in the theme it being used as a Lite Mode, which is defined in functions.php. What to do about that?
While I understand that if the theme is specifically referring to ACF field names, they won’t show in another theme, the data will still be available in the back end for the user.
