1999 posts
  • Elite Author
  • Sold between 250 000 and 1 000 000 dollars
  • Author had a File in an Envato Bundle
  • Has been a member for 5-6 years
  • Author had a Free File of the Month
  • Won a Competition
  • Bought between 10 and 49 items
+4 more
bitfade says

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.

366 posts WordPress Guy
  • Envato Staff
  • Australia
  • Has been a member for 5-6 years
  • Contributed a Tutorial to a Tuts+ Site
  • Exclusive Author
  • Sold between 100 and 1 000 dollars
  • Bought between 50 and 99 items
  • Referred between 1 and 9 users
  • Repeatedly Helped protect Envato Marketplaces against copyright violations
Japh Staff says

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.

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.

366 posts WordPress Guy
  • Envato Staff
  • Australia
  • Has been a member for 5-6 years
  • Contributed a Tutorial to a Tuts+ Site
  • Exclusive Author
  • Sold between 100 and 1 000 dollars
  • Bought between 50 and 99 items
  • Referred between 1 and 9 users
  • Repeatedly Helped protect Envato Marketplaces against copyright violations
Japh Staff says

I’m off again for the night, everyone. Midnight seems to be my limit, but I’ll be back fresh again tomorrow if you have further questions or clarifications :)

33 posts
  • Bought between 1 and 9 items
  • Exclusive Author
  • Has been a member for 2-3 years
  • United States
JonnyShogun says

Hello,

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?

1 post
  • Bought between 10 and 49 items
  • Has been a member for 3-4 years
pixelnprint says

Is there any news on plugin authors being able to offer plugin licences for developers to use on multiple/unlimited sites?

8 posts
  • Bought between 10 and 49 items
  • Has been a member for 4-5 years
m_i_n says

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?

1999 posts
  • Elite Author
  • Sold between 250 000 and 1 000 000 dollars
  • Author had a File in an Envato Bundle
  • Has been a member for 5-6 years
  • Author had a Free File of the Month
  • Won a Competition
  • Bought between 10 and 49 items
+4 more
bitfade says

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.
Must have missed it, glad to know it.
814 posts
  • Author had a Free File of the Month
  • Exclusive Author
  • Sold between 10 000 and 50 000 dollars
  • Bought between 1 and 9 items
  • Referred between 1 and 9 users
  • Serbia
  • Has been a member for 5-6 years
rvision_ says


is TGM mandatory ? say i don’t need all TGM features but can obtain the only ones i’m interested in with simpler (custom) code, would that be a problem ?
We don’t have a concrete answer for this. Can you show me some custom code that we could look at to evaluate options?

Can we bundle required plugins in a separate folder and let users upload them individually? Or this is a space-mission task for users?



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.

1466 posts
  • Has been a member for 2-3 years
  • Exclusive Author
  • Sold between 10 000 and 50 000 dollars
  • Bought between 10 and 49 items
  • Referred between 1 and 9 users
  • Croatia
OriginalEXE says

I too don’t like braces requirement. When I started with php I used braces everywhere, but now I just can’t, it looks ugly.

158 posts
  • Exclusive Author
  • Has been a member for 5-6 years
  • Referred between 50 and 99 users
  • Sold between 1 000 and 5 000 dollars
  • United States
greenshady says


is TGM mandatory ? say i don’t need all TGM features but can obtain the only ones i’m interested in with simpler (custom) code, would that be a problem ?
I’d love to know why you’d want to write custom code for this rather than using an existing, recommended, class?

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.


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.


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.



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.

As has been mentioned many times over, the major problem is data portability. Once a user switches to another theme, that shortcode is broken. It’s the same with things like CPTs and taxonomies.



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.

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
by
by
by
by
by
by