Regarding widgets, I have placed all my custom widgets into a plugin.. But i have 3 widgets that i made that are dependent on data from my admin options. My contact info widget, my social widget, and my twitter widget. Basically in the widgets page the user just drags the widget over to the position they want it in, and the configuration info is in my admin options page, with links in those widgets displaing links to my admin page to configure. So those widgets i didn’t include in the plugin since they depend on data that is specific to the admin options i have in my theme. And those widgets share files that only available in my theme so i dont have duplicate code.
Will that be Ok, that these widgets are not included with my other widgets inside a plugin since the info from those widgets are dependent from my themes admin options?
This would be at the discretion of the reviewer. It’s difficult to answer this one, as I don’t know why your Twitter widget would be dependent on your admin options.
Is there any news on plugin authors being able to offer plugin licences for developers to use on multiple/unlimited sites?
No news yet, sorry.
So, why shortcodes must be in plugin? Shortcodes like dropcap, buttons, tables, columns, boxes etc. it’s all visual elements, not functional. They don’t provide any functionality, they just look.
Because the nature of shortcode implementation itself is functionality, and can impact the content of a WordPress install.
While reading this thread I can’t resist a feeling that envato market became slavish and dependend on various permisions instead of being free. Every post looks like “can I do this or that”, “is that allowed?”. Does it really matter to constantly ask for permisions to do anything instead of focusing on customer requirements?
I’m sorry you feel this way. I look at it like this: before, authors submitted themes without having a clear idea of what requirements reviewers were looking for; now the requirements are public, and authors are asking for clarifications based on these public requirements.
It wasn’t easy to ask “can I do this or that” or “is that allowed?” before, because the requirements weren’t known.
The situation hasn’t changed, besides increased transparency, which I would think is a good change.
Can we bundle required plugins in a separate folder and let users upload them individually? Or this is a space-mission task for users?
I would expect that could be a space mission that results in more support enquiries than if you used something like TGMPA to prompt users to do it through an interface.
You certainly could do it that way though
The big thing is that you can write something simpler to handle what you need. Otto has a great tutorial on this: http://ottopress.com/2012/themeplugin-dependencies/ Another thing is that writing competing code can often spur innovation. Many developers are interested in plugin/theme dependency these days, especially with things like CPTs, so limiting devs to using one class can actually stifle innovation in this area. Obviously, you’d want to check the code for security issues, but it’d be neat to see other solutions to the dependency issue.
Excellent points, and something we’ll definitely take into consideration as we discuss the specifics of this.
Curly braces requirement is nuisance, IMHO. Who says it improves overall readability? For me, it’s quite opposite – I have two braces more to “process” to figure out what is going on.
Just as a heads up, I leave off braces where appropriate in my Hybrid Core framework, so the themes that use it here would no longer be able to use it or would have change the code in the framework, which would defeat the purpose of using the framework.Plus, WordPress PHP coding standards allow for no braces when you have single-line blocks: http://make.wordpress.org/core/handbook/coding-standards/php/#brace-style
This does appear to be a sticking point, and while I feel that omission of curly braces is against the overall rule of clarity vs brevity, perhaps we need to revisit this.
Is a _s based theme acceptable or not ? http://underscores.me/
Underscores is just a starter theme, I don’t see why using that as a starting point would be a problem
But at the end of the day, styling a theme is for the theme we have created, not to enhance another theme. Keeping data is one thing, making another theme look better and function better is another.
Im sure ThemeFusion will not want there shortcodes/functionality within other themes.Dont get me wrong, I can see the benefits of this for the buyer, but I can see a ball ache for developers when users come back saying, it does not look right… Their past content from the theme the developer created on a new theme some other developer created, and vise versa.
Yes, styling is for the theme. Check out what ZillaShortcodes does.
From the 5 years Ive been on WordPress I have never had any support/client ever ask:
“Why is my shortcodes not working on my new theme”.
“Why is my old portfolio not showing” etc etc etc…When people buy a new theme, it generally is to provide a new presence and not to use old content.
As greenshady already mentioned, it’s not you who receives these sorts of enquiries. But as someone who worked in web agencies on WordPress sites for a number of years, I can tell you without any doubt, other people get asked. I got asked. Running a WordPress meetup group, I also see many users asking about this. It’s something that concerns them.
Why you’re not being asked at all though, I’m not sure.
Great. One of the reasons that I don’t want to use TGMPA is because everyone can download the zip files from my theme if they know the location. For “pirates” is enough to share one link in a public forum and we become, or to be precise, buyers becomes a distributor of ilegal plugin copies. If someone have a solution of how to forbid direct download then I will use this TGMPA for sure.
It could be done with access keys, and rather than package the ZIP in the theme, you serve it from a server that uses the access key to verify. However, something like this should be available on CodeCanyon in the near future (as it is with themes on ThemeForest now).
“Im sure ThemeFusion will not want there shortcodes/functionality within other themes.”
To put on the record, on day one of the first announcement, it came to us a shock purely because of deadline and buyer expectations. When it was clear that all already approved themes will have a much larger deadline since then we have been fully supporting the new requirements and will be following it, we have a much larger timeframe to support the WordPress and ThemeForest conditions and think about the changed workflow for our buyers.
We’re happy to follow and support them in the coming months.
Personally, as a developer, I am quite happy to work on these changes and write better code which in the long run will be beneficial to our business and our users.
Time to get creative guys.- Muhammad Haris
Guys, congrats on taking this step and on working so close with the community to clarify and implement these changes smoothly. I’ve seen a lot of valuable feedback and even learned a lot from experienced developers and authors in these ~100 pages and am glad to see that authors that I personally admire and respect (some even know) are on board with these new requirements and even encourage them.
They follow good practice, push developers to be creative without being sloppy and put a clear limit between style and functionality. Also, they help educate clients and in the end, an educated client is a happy and much easier to deal with client. So, thanks Envato team and Japh particularly for “wasting” so much time doing an amazing communication job that at times has become frustrating and repetitive. Much respect.
As an aside – no promo intended – this recent video from Apple (Mission Statement) kind of reaches a few points of the whole “jam-packed” design/functionality debate that has been going on lately, although it has nothing to do with WordPress. Still, the principles apply: http://www.youtube.com/watch?v=VpZmIiIXuZ0If everyone is busy making everything, how can anyone perfect anything? We start to confuse convenience with joy, abundance with choice. Designing something requires focus. The first thing we ask is: What do we want people to feel? Delight. Surprise. Love. Connection. Then we begin to craft around our intention. It takes time… There are a thousand no’s for every yes. We simplify. We perfect. We start over.Words of wisdom. Have a good day/night everyone and may you sales skyrocket!
Nice link! I watched that video when they played it at WWDC, and I thought of ThemeForest and these requirements too. It’s quite inspiring
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.