To me, themeforest are basically not creating themes anymore…
They want us to create skins, with plugins.
For instance a theme has all logic and styling where as a skin has just styling.
Correct me if I am wrong?
For me this seems to be going away from WordPress standards, as WordPress state that all functions should be within the functions.php of the theme, yet we are now segregating them into a plugin.
Will prices go up?I ask because this seems to be about 25% more work. and $35 – $45 is getting a little cheap when all this is being implemented.
This isn’t how I see things at all, and from a lot of the comments here, I think there are many authors who would also disagree with you on this.
A theme deals with the visual aspects of a WordPress install, and plugins add functionality. Sometimes there’s a certain amount of functionality required to implement visual aspects, so this level of functionality also lives within a theme. This isn’t particularly new. This is how WordPress has been doing it for roughly 10 years now.
To be honest, I’m on board with these changes, in the end they’re for the best, no-one likes change but we need to make sure we’re coding to the best standards possible.
I just have one question RE: the new policy on inline styles.
Let’s take this example: items in a loop which can have a background image (specifically) applied via post meta. Now to me the best way of doing this is to simply use an inline style on that element generated by the value of the post meta. I’ve read the mentions of wp_inline_style() but I’m not sure how this would apply to styles generated by post meta to be applied in the loop.
Basically I’m working on a theme where the user will have full control of the post background directly from the post meta for each separate post, colour or image, each post can be different including the colour, the image, and the image display.Is it still ok to apply these post meta generated styles directly to the loop items, as this to me seems the best way of doing things
Hey Tom! The requirements say “No hardcoded inline styles are allowed anywhere. Dynamic inline styles are permitted where necessary, and wp_add_inline_style() should be used where possible.” (emphasis added)
I hope that answers your questions, as it sounds like it fits the scenario you mention to me
Japh, consider that we’re theme authors. Shortcodes will be moved into plugins because the new rules but you can’t expect fallback styling when plugin is custom made and used with a theme different from the one the it was bundled with.
That would be, honestly, asking too much. We use bootstrap in our themes, even the most simple shortcode (like a button) would rely on bootstrap css to render decently and we can’t inject whole bootstrap into another theme which is skeleton or whatever framework.
Excellent point, and I think I also mentioned earlier, that I wouldn’t expect a plugin to include any CSS or JS if it relies on something as prolific as Bootstrap.
If buyer changes theme, he do this because they don’t want old design – so they also don’t want old looking site elements (tables, widgets, quotas, captions, boxes, etc…).
I’m not sure how you come to the conclusion that this will result in “old looking site elements”? The theme will take care of the look and feel of these shortcodes generally, and plugins can also be updated. If the theme doesn’t support styling for the shortcodes, they should have generic styling built-in so they conform to the theme, in a similar fashion to how WooCommerce does.
Because i almost never rely on 3rd party code when i have to support the item myself. I’m not saying i will but i’d like to know if a simpler solution based on wp hooks similar to this one exist for plugin installation, will i be allowed to use it ?
As Sid mentions above, we’ll have to discuss this internally to come up with an answer.
You could always get familiar with TGMPA and contribute on GitHub if you wanted
If Envato want to standardise everything so that there is a generic structure and versatility regarding themes, should envato not come up with a standard class which will do this rather that different authors using different code.
This way it can be monitors easier and prevent confusion.To build a class which forces activation on plugins isnt a huge job so should envato no include this in a repository and make it compulsory to include it within the theme to activate all plugins used within the theme?
As we’ve made fairly clear in the Notes post and requirements themselves, we’ve nominated the TGM Plugin Activation class as this very solution.
Can someone clarify on this thread: http://themeforest.net/forums/thread/theme-rejected-shortcodes-are-key/103439 According to the OP they got rejected because the shortcodes are not within a plugin.
Kailoon has already clarified on the original thread itself.
2) I’m already using TGM, however it does throw up a huge amount of RECOMMENDED errors, will these be ignored. 3) I have a number of other plugins too which are throwing up these kind of errors, they’re using phpFlickr and Twitter API’s ( file_get_contents, curl etc ), the Theme Check plugin just reads the entire directory, which will include these plugins – do we have to move all plugins to an external location now? This isn’t possible with Visual Composer and say Revolution Slider extended licenses?
Sid has already answered most of your questions, but I’d also like to draw your attention to the ThemeForest-Check plugin mentioned earlier in this thread. That will stop most of these errors from showing.
Thanks for creating Q & A, it’s really helpful! But, regarding the Q & A site, that Q2 of the Phase 2 is not mine actually. My question haven’t yet been answered. Here I quote it again:
My apologies! I’ve fixed that now.
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?
Think visual VS functional separation.
If jQuery is deregistered in a plugin (packaged with the theme), will it be OK then?
If you feel it’s vitally important, instruct your users in why and how through documentation.
I’m having difficulties accepting your “there’s really no need to do this” reply when we’re talking about avoiding the load of additional 90KB for any theme by default.
Thanks for your feedback, however, as PrimaThemes points out…
If user want to use jQuery Google CDN, they can install this WordPress plugin (for example), http://wordpress.org/plugins/use-google-libraries/
My point is, this should not be done in a theme.
As suggested by uouapps, I’ve attempted to collate a basic Q&A of what’s been covered so far here: ThemeForest’s WordPress Theme Submission Requirements Q&A
Hopefully you guys find this useful, if not, that’s ok too I will try and keep it up-to-date with any significant new questions / answers. Let me know if you feel I’ve missed something.
Please do not comment there, it is for reference and easy access only.
This thread will probably reach a 100 pages within a week, as far as every answer is crucial and currently there’s no search engine within a thread, would it be possible to organize in the envato knowledge base a Q&A structured per topic ?
some people will be asking same questions, others will be asking different questions but within the same topic so it would really facilitate our lives if this thread could be more optimized.Thanks in advance Cheers UOU Apps