Do you expect that forcing authors to move features from theme to bespoke plugins will allow end users to switch from this to this seamlessy ?
More likely, each theme will include its own set of custom plugins that would need to be mandatory installed to replicate the demo and to mix them with previous themes custom plugins will lead to anything but a seamless experience for buyers and authors.
Who’s going to deal with raging buyers when everything will break horribly (because it will) ? Who’s going to bear the burden of support ? old theme author ? new one ? you think buyers will accept “we can only support our own theme/plugins when used together” kind of answer ?Who asked for this changes ? buyers ? I doubt so, having dealt with thousands of them myself and not yet having found one who cares about the issues you’re trying to address with these new rules.
You make some interesting points, and we’ll definitely be discussing them.
You’re trying to enforce wp.org rules on TF when TF products are anything like wp.org ones.
Interesting distinction you make. Do you believe your customers will only use a ThemeForest theme and its bundled plugins, without any plugins from wp.org? And that plugins bought from CodeCanyon will only be used with ThemeForest themes, and not themes from wp.org?
Shouldn’t they all play as nicely together as possible?
First of all, 3 weeks is a joke and even further grace period is a joke for existing themes. We simply needs MONTHS to apply these changes gradually.. like a few per update.
Three weeks was our initial thoughts before we start applying all these to newly submitted themes. We’re happy to take your feedback into consideration on this though, of course!
As for existing themes, we know it’s going to take months, and you’ll have them
“Inadmissible shortcodes” will not be allowed in “shortcode” plugins If that’s true do you know how buyers will react?
That’s not what we said, so let’s assume it’s not what we meant
These will be inadmissible in the theme. Shortcodes should be in plugins, not the theme itself, as much as possible.
Hi, Japh: I do not agree with this view. If you set the post counts options for category, not mean it will change the global posts_per_page parameter. Also If the theme has portfolio and blog, then the layouts of portfolio and blog are different, the users need to set each post count for the portfolio and blog.
Good point, thank you. Will take this into consideration.
7. Themes are not permitted to add options that define the number of posts to show on archive or category pages.
Is there any reasons why we can’t do this? We can filtered the ‘pre_get_posts’ to change posts_per_page value for archives and category. Problem will raise with the theme that have many post types, or theme that provide option to choose columns layout per category.Anyway this is a great news, thanks!
WordPress itself already provides a feature for this.
Also, themes that do add this option can break plugins. For example, some plugins might break because the theme is setting a global
posts_per_page parameter and so a “number” parameter in the plugin becomes useless.
Can you please explain how lists in TinyMCE is a shortcode? All I am saying here is, Lists is a standard feature in Tiny MCE editor, why should there be a shortcode for this in the first place? and How can this be admissible ?
It is like creating a shortcode for Headings (H1,H2…) and it is in the admissible list. I am merely pointing the inconsistency that I feel here.
Thanks for clarifying! I’ll discuss this further with the review team.
Japh saidThe question was about the same plugin.
Not allowing one plugin doesn’t mean not allowing all plugins.
Perhaps I misunderstood your first post? I thought you were saying “You aren’t allow to include plugins in your theme at all”, but perhaps you actually meant “Not all plugins will be allowed to be included”?
It’s a commercial plugin. Buyers cannot auto update it. More, when i first released the theme buyers went and bought the plugin even if it was included, because thought that they should do so in order to update. But this is wrong, since i’ve modified the plugin a lot. So now, i have my own version of the plugin which i only update on theme updates and the buyers have to update both the theme and the plugins. Otherwise they could simply update the theme and the plugin should be update.
Well this is an interesting grey area isn’t it. You’ve forked a plugin, and can now only offer updates via theme inclusion?
Really?! I’ve included the Visual Composer in my latest theme and i was bashed by the reviewers one whole week because i’ve included the Visual Composer in my theme, which was actually possible since the author of the plugin already gave the tools for doing this. Finally the reviewers told that they will not accept the theme unless i put the plugin inside the TGM activation class, which was stupid, because the plugin is completely modified by me, so now buyers have a really hard time to update and maintain it. Yes, it’s harder to maintain a plugin installed via TGM then a plugin embedded in the theme. You may say otherwise, but you’re not the one who is answering my support tickets
Not allowing one plugin doesn’t mean not allowing all plugins.
Also, maintenance should be easier with TGMPA. If it’s not working better for you, I’d be interested to know why. Keeping the plugin separate for updates means the plugin can be updated independently of the theme, which is great.
WordPress Core API
1. base64_encode() : This is not allowed in a theme, but is it allowed in plugins ? It is being used by popular plugins to import/export settings.
Actually we’re saying this is ok. Normally Theme-Check will throw an error, but we’re allowing it for certain conditions, such as theme frameworks that need it, etc.
1. Admissible shortcodes list is contentious.
a. Lists is already in WP Editor Tiny MCE, but it is in admissible shortcode whereas Accordion/Toggles are not.
b. What about other common shortcodes like Tabs, Icons etc.
Can you please explain how lists in TinyMCE is a shortcode?
2. Columns shortcodes (in one form or other) are being used by Themes with inbuilt PageBuilder. So, do they have to move out their inbuilt PageBuilder as a separate plugin?
I would imagine that’s one way to resolve the issue, yes.
1. W3C Validated, Is it necessary ? Twenty twelve has 12 errors.
2. No Inlines styles? But Inline styles are added by the WP Tiny MCE editor when you try to give text a color or center align the text etc..
As WordPress is doing it there, there isn’t much that can be done, but it’s undesirable behaviour.
Another important question is :
Themeforest API updates the Theme what about the plugins included in the theme using TGI Activation ?
Plugins will need to have their own individual update mechanism. This is one of the issues we’re trying to resolve with this.