41 posts BD Themes
  • Has referred 500+ members
  • Has sold $125,000+ on Envato Market
  • Has been a beta tester for an Envato feature
  • Has collected 50+ items on Envato Market
+5 more
bdthemes says


Regarding theme frameworks, is it still possible to use Yootheme’s Warp framework, which uses profiles instead of child themes? I know that there’s been a few themes in the past that have used it and one wordpress one that does now – http://themeforest.net/item/beauty-salon-responsive-wordpress-template/2948075?WT.ac=search_item&WT.seg_1=search_item&WT.z_author=bdthemes.
I’ll have to discuss this one with the review team and get back to you.

Yes 61designs was right, if i use gantry or warp framework there any problem? although those framework did not follow fully wordpress coding structure (100% of 20% overruled but it’s for combine joomla and wordpress both structural issue that’s means if i design a site for joomla so i can reuse that design for wordpress) and did not full fill the new requirement so what to do now? but one things those framework php coding very strong from all other authors framework, so i hope there will be some consider for those framework, although we will cover the all other issue for example: plugin for custom post type, shortcode coding structure issue validation issue theme check plugin issue etc

3610 posts Ruben Bristian
  • Sells items exclusively on Envato Market
  • Elite Author: Sold more than $75,000 on Envato Market
  • Has sold $500,000+ on Envato Market
  • Has been part of the Envato Community for over 6 years
+10 more
KrownThemes says

Hi Japh

Thanks for all the clarifications.. Even if it’s harder for us to swallow everything, i think that it’s the correct decision and a good thing to apply these requirements (i’m referring to phase 2), as it will make us better theme developers.

I have two question though, and i’ll take a practical example to illustrate my concerns. Let’s take my theme WowWay. I have two custom post type, but let’s say that i’ll move all the functionality inside a plugin and do the following:

  1. Plugin will register custom post type “portfolio”
  2. Theme provides settings for the custom post type, allowing the creating of either a gallery or a portfolio. Theme also has two page templates for users to use in case they want the “portfolio” to be displayed as a gallery or a portfolio. Theme has fancy css and custom made jQuery galleries so that it will look like it currently does.
  3. When theme is gone, the user is left with the custom post type “portfolio”, but since there are no page templates for the grid or for the single “portfolio” display, the cpt will support archives and all the projects will be displayed as basic posts with no fancy anything. But they will be left here. Correct?
  4. And the last thing … what about custom meta fields? Are these in the plugin or inside the theme? Let’s say i want to create custom galleries in my portfolios (that is images combined with videos). I will do this with custom fields. Then the single “portfolio” will handle the custom fields. Where should i put these (theme or plugin)? If i put them inside the theme they will disappear (i’m referring to the meta fields options), but the contents will still be there in the form of a serialized array. If i put them in the plugin, the backend will be there (the users will still be able to configure galleries) but the front will be gone. So my assumption is that meta fields will go inside the theme, correct?

Maybe i wasn’t too clear, but i would definitely like to hear your input on these concerns of mine.

639 posts
  • Has been part of the Envato Community for over 3 years
  • Has sold $10,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Sells items exclusively on Envato Market
ChapterThemes says

I think it’s logical that you put the custom meta fields inside the same plugin that creates the custom post types. This way in another theme they can still use the custom fields in the other theme ( if they code it in that is ).

However, I digg the option of having the actual user-interface design etc. inside the theme. This way data creation is run by the plugin but the sweet interface that ‘makes’ your plugin would be gone but the data remains. A good way to protect plugin usage outside your own theme…

641 posts
  • Has referred 50+ members
  • Has sold $40,000+ on Envato Market
  • Has been a beta tester for an Envato feature
  • Has collected 100+ items on Envato Market
+5 more
UBLThemes says


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”.

Or

“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.

Assumption is the killer of all!!!

I have in-fact owned my own web design agency for 10 years now, we have well over 50 WordPress clients a year (Not much I know but I tend to not push WordPress due to it being heavy code) and not once have I ever been asked these questions.

Please don’t think I’m against this because I am not, I think its a good thing that users will have easy to switch theming but they are not the problem.

As every author on here knows, its the bad developers, who like to steal code, this just makes it easier to do this, because all they have to do is change a few variables and style them and voila they have there self some amazing functions.

I felt for sometime that authors have been taken for a mug a lot by some authors and Envato, and it just seems that we will get more frustrated by theft than we did before.

Envato in the past just say: “You are the copyright owner and you need to fight it”.

I think if you are making things more transparent for thieves then we need more help from yourselves!

639 posts
  • Has been part of the Envato Community for over 3 years
  • Has sold $10,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Sells items exclusively on Envato Market
ChapterThemes says

@Japh

Question 1: Is it allowed to let a plugin check the current theme info and let it only work if the info matches the theme it has arrived with?

Question 2: Is it allowed to require the theme purchase code as a setting before any of the plugin features work?

32 posts
  • Has been part of the Envato Community for over 1 year
  • Has sold $100+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Sells items exclusively on Envato Market
+1 more
Deveraux says

  1. Plugin will register custom post type “portfolio”
  2. Theme provides settings for the custom post type, allowing the creating of either a gallery or a portfolio. Theme also has two page templates for users to use in case they want the “portfolio” to be displayed as a gallery or a portfolio. Theme has fancy css and custom made jQuery galleries so that it will look like it currently does.
  3. When theme is gone, the user is left with the custom post type “portfolio”, but since there are no page templates for the grid or for the single “portfolio” display, the cpt will support archives and all the projects will be displayed as basic posts with no fancy anything. But they will be left here. Correct?
  4. And the last thing … what about custom meta fields? Are these in the plugin or inside the theme? Let’s say i want to create custom galleries in my portfolios (that is images combined with videos). I will do this with custom fields. Then the single “portfolio” will handle the custom fields. Where should i put these (theme or plugin)? If i put them inside the theme they will disappear (i’m referring to the meta fields options), but the contents will still be there in the form of a serialized array. If i put them in the plugin, the backend will be there (the users will still be able to configure galleries) but the front will be gone. So my assumption is that meta fields will go inside the theme, correct?
Maybe i wasn’t too clear, but i would definitely like to hear your input on these concerns of mine.

I don’t know if TF reasons the same way as I do, but I don’t think its expected of you to create virtual pages. To add rewrite rules and change and parse routing and is pretty simple but if you want to create a real virtual page that you can add to menus etc. its quite advanced, since you have to modify some core wordpress files. It can be done in some other way but I think that would require even more work.

The general recoomendation has been that meta fields should be in the theme if its for aesthetics if its not it should be in a plugin. But i think that’s wrong for custom post types, since the main purpose should be to provide the user with an easier way of changing portfolio for example e.g. you can see what you previously had on the backend side.

Some reflections
  • I would have liked if themeforest would have gone another route by making portfolios convertible between themes to some basic extent by copying the basics of a custom post type to another (title, content. Having a standard name for various custom posttypes and then have the meta boxes in the theme, that would save time for users that are changing themes).
  • How will the licencing for plugins be, like pagebuilders, slideshows etc that are currently under the extended licence? Will the current licence be changed (for the worse for plugin authors)? It could be done for the better by encouraging users to get the plugins when changing themes otherwise..
3610 posts Ruben Bristian
  • Sells items exclusively on Envato Market
  • Elite Author: Sold more than $75,000 on Envato Market
  • Has sold $500,000+ on Envato Market
  • Has been part of the Envato Community for over 6 years
+10 more
KrownThemes says

I would have liked if themeforest would have gone another route by making portfolios convertible between themes to some basic extent by copying the basics of a custom post type to another (title, content. Having a standard name for various custom posttypes and then have the meta boxes in the theme, that would save time for users that are changing themes).

This was also my concern. Yes, i’ll put my cpt inside a plugin, but if the buyer changes the theme, the portfolio of that theme will work totally different than mine in 99% of the cases, so the user would have to recreate the custom post type all over again. Of course, the user will be able to change between all of my themes with ease, but when he’ll change to a different theme he’ll also have to create things from scratch, because that theme will feature it’s own cpt plugin.

The above might also go for shortcodes. Yes, i’ll use the same shortcodes plugin in all of my themes and the styling will differ, but when the user changes the theme he’ll see a different shortcode composer so he’ll have to reconfigure his entire website even if the content will work (because i’ll provide basic css/js functionality for my composer).

2010 posts
  • Has referred 50+ members
  • Has sold $500,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Elite Author: Sold more than $75,000 on Envato Market
+9 more
bitfade says

It seems quite obvious at this point that phase 2 rules are not going to change (drastically) so, imho, to keep arguing is just pointless.

that’s how we’re going to comply:

  • theme: mostly a blog skin, will include all css/js and some custom widgets.
  • single bundled custom plugin: no js/css, all shortcodes and cpts, hooks for theme to define metaboxes for cpts.
  • theme + plugin = get all the features! (meme here).
  • plugin alone = all data available in the backend, presentation and support when used with other themes: not our concern.
399 posts
  • Has been part of the Envato Community for over 6 years
  • Has sold $10,000+ on Envato Market
  • Had an item featured in an Envato Bundle
  • Won a Most Wanted contest
+5 more
QBKL says

@bitfade, that makes a lot of sense and it’s how I see it too. Functionality is still ported between themes, yet if falls on the new design to support the styling. Button shortcode will still return a button, except un-styled.

In relation to all the drama around the stealing deal:

a. As it is now (without the new requirements), any person with access to the theme CAN steal features. With minimal knowledge a user can go through folders and follow an inclusion path. What’s the difference then? The fact that it is a plugin and that makes the “stealing” accessible to even less experienced users? How’s that any different than a user re-using the same theme over and over again without extended licenses. The issue is not how someone steals it – cause that’s pretty darn easy in any situation. The issue is the fact that IT CAN get stolen anyway.

b. There’s been a lot of talk about deactivating the plugins once the user changes themes. Authors being frustrated that their functionality will be used with other themes too. I’ll ask you this question: Have YOU sold the package? Has it been paid for? Then what’s the matter? With current packages do you NOT ALLOW users to use your functionality if they tweak the designs or something? Do the sales come with a limited lifetime? In both cases you’re delivering both DESIGN and FUNCTIONALITY and you’re earning money for both. As long as the user of a regular licence does not use the plugin on more websites I don’t see why any author would restrict them from using something THEY HAVE paid for.

c. If you don’t feel comfortable with selling the extra-functionality packed as a plugin inside the theme and want users to pay for design separately from functionality, who stops you selling the plugin as premium on CodeCanyon? And if you do, won’t that plugin STILL be easy/easier to steal?

Bottom line, all these assumptions are pretty much flawed. As it is now everything can be stolen once ONE user gets to BUY one theme and if they are not of good-faith, they’ll provide RIPs on all those f-ed up websites that bother us all. Separating functionality from design, in the end, is good for our clients and provides easier update and support methods for us all.

There was another question about who’s going to offer support for the plugins that persist beyond your theme. The way I see it – and this works well with that bitfade said above -giving support for that plugin falls on your shoulders, as the client paid for what he got, BUT with a twist. After theme-switch (except cases where users switch to a theme from the same author), the author COULD or SHOULD only provide support for functionality issues, not styling issues. For styling issues it falls on to the client to support the consequences of their decisions, thus to pay either the author or a freelancer to restyle the plugin in line with their new theme.

33 posts
  • Has been part of the Envato Community for over 2 years
  • Has collected 1+ items on Envato Market
  • Sells items exclusively on Envato Market
  • Located in United States
JonnyShogun says


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.

basically when a user sets the Twitter Widget ID in the admin in one place, versus having to put that Twitter Widget ID in a input field in every Twitter Widget block.



Any thoughts on what would stop another developer or user from stealing code from the easy accessible plugins? And do we have to make all slider options into a plugin?

Can you explain a little further the scenario you imagine them getting access to the plugins?

I can think of two possibilities:

  1. File access to the theme or WordPress install, and taking the plugins
    If they have this level of access, nothing is stopping them doing that now.
  2. URL access to ZIP file of plugins in the theme’s subdirectory
    An option would be to utilise a different method of distribution. Have the theme install the required plugins, via TGMPA (or similar), from a repository or server that requires a key. Soon, CodeCanyon will support this (as ThemeForest does), for example.

i can see how both possibilities they can do now, but it looks like that making the slider options into a plugin, just make it easier for people to just grab your code since now its portable via a plugin

I already am using TGMPA. How would you make it available on a server with a key?

Also what the point on making slider options into a plugin, when a user can not use it on another theme, since all the files for it to work on the frontend are in the theme itself??

thanks again JAPH !!

by
by
by
by
by
by