Japh said
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.

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 uses skeleton or whatever framework.

Same goes for javascript: almost all our code is commercial, made by us to be used with our themes only. While we will move shortcodes/custom post types into a plugin so all data will be available to the buyer in the backend when switching theme, the plugin itself will never include any of our custom js code.

Shortcodes will be rendered, markup will be there but its styling cannot be our concern.

UBL said
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.

TommusRhodus said
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

bitfade said
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.

Same goes for javascript: almost all our code is commercial, made by us to be used with our themes only. While we will move shortcodes/custom post types into a plugin so all data will be available to the buyer in the backend when switching theme, the plugin itself will never include any of our custom js code.

Shortcodes will be rendered, markup will be there but its styling cannot be our concern.

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.

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?

Japh said
A theme deals with the visual aspects of a WordPress install, and plugins add functionality.

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.

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?

neutrico said
Of course, there is no need. But code without closing tags is still valid – and if it’s valid why report it as wrong? Just from logical point of view.
And it’s easier to edit files that are 100% PHP.
For example some editors/IDE’s complain that you have unpaired closing tag in footer.php

Our policy, is that it is required. As with the requirement for curly braces. It improves overall readability, and there’s no good reason not to include it.

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.

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.

m_i_n said
I coopearate with one TF elite author, i’m responsible for coding from PSD to template and to WP theme. After a couple of years and almost 10 000 sales / 5 000 comments (and i don’t know how many mails) we’ve never had any single question like this: “Hey, i change theme to another, where are my shortcodes?”...

You don’t get those questions. Those questions get passed on to developers like me who handle your users after they stop using your themes. We have to help those users clean up the mess.

UBL said
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.implemented.

Essentially, the WordPress theme system is a system for creating “skins”.

The best way to think about a theme is that anything within your theme folder should deal with the visual display of the site. Anything else should go within a plugin.

Japh said
Our policy, is that it is required. As with the requirement for curly braces. It improves overall readability, and there’s no good reason not to include it.

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.

Agreed.

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.

Post Reply

<strong></strong> to make things bold
<em></em> to emphasize
<ul><li> or <ol><li> to make lists
<h3> or <h4> to make headings
<pre></pre> for code blocks
<code></code> for a few words of code
<a></a> for links
<img> to paste in an image (it'll need to be hosted somewhere else though)
<blockquote></blockquote> to quote somebody