Posts by Japh

378 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh
says

Ouch… sorry about the mammoth post! :shocked:

378 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh
says

include_once "file.php" == bad
require_once "file.php" == ???
Just making sure.
Is file including bad, or is “unimportant file” including bad ?

Neither are inherently bad, it’s situation-dependent. We’ll put together some further clarification on this.


Correct me if I am wrong (didn’t read the whole thread) but I think the point of using “shortcode plugins” is to prevent the “lock in” effect you get if you use a theme and then want to switch and none of your shortcodes work any longer.

Therefore it should be sufficient to provide a small self written plugin for your customers so they can switch theme whenever they want and keep their shortcodes working. Thats what I plan to do.

I definitely wouldn’t use a public repository plugin for my shortcodes. (And to be honest: if envato wants to enforce these requirements to existing themes that wouldnt work anyways, since all these plugins use different shortcodes than the ones used in themeforest themes. Implementing them now would break all existing shortcodes which is probably not the best idea ;D )

In all honesty I think Envato did a rather mediocre job with this requirements (most of them are good but a lot of them lack examples or clarification).

A handfull Elite Authors were pitched with these requirements months back. I at least provided extensive feedback and I think none of my suggestions or clarifications found their way into this draft. I am not surprised about this 18 page discussion :P

Thanks so much for the feedback you gave. I’m still advocating for some of the changes you suggested. I imagine you’ll see them in v2.0 :)


One thing I have to mention, again, is that for something so important to the core of this site, it’s products, and thousands of peoples sole way of earning a living, you did another awesome job of placing this on a blog (notes) that no one reads, started a forum thread on the 4th of July (the biggest holiday in the US and many have taken a few days off and may miss this), and didn’t put a message on authors dashboard, nothing in the notices section of my dashboard and no banner at the top to inform us. A real disappointment yet again Envato – you do seem to excel at this issue…..

Thanks for the feedback, but we did globally sticky this forum thread, and closed comments on the Notes post (as it was a secondary announcement for those who do read it). Apologies for the conflict with the 4th July too, that was definitely an unfortunate oversight.

There is now a notice in the author dashboard about this announcement!


After the grace period is over how will you handle themes that aren’t fully meeting these requirements. Will you be treating the top selling items and the not-so top selling items equally? If an existing item that isn’t selling much doesn’t meet these requirements, you will most likely soft reject it but will you do the same for an item that has 300+ sales a week?

Firstly, we’re currently only talking about newly submitted themes, so it would be impossible for a newly submitted theme to have any sales. However, when the time comes to apply these standards (after revision based on this discussion) to existing themes, I don’t see why we would be more lenient based on sales. If anything, it’s more important that a theme selling well complies with standards.


1. It will be ok to use shortcodes if I put them into a plugin? And for shortcodes that are inadmissible I have to provide other plugins to do the job? So all in all in the end we will provide a theme with TGM that will install 20 other plugins right?

The list of admissable and inadmissable shortcodes relates to inclusion in the theme itself. Inadmissable shortcodes, or any shortcodes for that matter, should be implemented via a plugin (custom or existing).


Just one thing I disagree (as many others here); my honest opinion is that add a limit to the shortcodes functionality affects creativity and flexibility coding a WP theme; every author has a way to create great items to be released here. The shortcodes is an interesting feature in the WordPress themes. A lot of people is happy adding just few words between [] instead of adding widgets in (only) the available sidebars. Following the new requirements, sidebars would define the limit for the shortcodes usage.

Can you explain why you think this? It’s not “No shortcodes anywhere ever!”, we’re just saying that certain shortcodes must be implemented via a plugin.


Custom headers and custom backgrounds are not always needed. Similarly, add_editor_style() isn’t always needed if the theme’s typography matches the editor.

Great catches, thank you :)


Good, and how about portfolio features? Like, we have some incredible portfolio idea and of course, no plugin is available for it. Why would I create it in a plugin for another user to use with another theme? It’s my idea, my plugin, created for that specific theme, not for all the themes available here. Why would I provide support for someone using another theme? About social options or icons, maybe I want my own icons, there’s no plugin for them, I should create a plugin for them too, yeah, because of damn standards.

Standards means no creativity and use of as-generic-as-possible layout with as-many-free-plugins-as-possible. The best combination.

And for pricing tables, why would I be limited to some dummy generic layout some plugins offer me, when I maybe have like some killer ideas for those pricing tables? Because standards, that’s why

We have a really neat marketplace called CodeCanyon, you could always sell your portfolio plugin there and recommend it for use with your themes to get that functionality.


@FinalDestiny I don’t have an answer for you on portfolios. That is a tricky one, but I don’t think Envato is disallowing portfolio post types, so you are still free to do those as you wish.

As @Astoundify mentioned, perhaps Justin Tadlock’s Custom Content Portfolio plugin could work for some authors?


Even though you modified the plugin you can still use your version > zip it up and utilize the TGM class. I have plugins I’ve written and I still use the activation class instead of including them directly in the theme files.

Yes, exactly! Nice work :)


note TGM Plugin Activation class. throws a bunch of warnings not listed in the acceptable cases(theme check plugin)

Good note, thanks Chris. Thomas is looking into that for an update to TGMPA.



Also by placing your major features in a plugin, you can really easily include those features in all of the themes you build. Update the plugin once and all of your themes have the update. So much easier to maintain.
This statement right here should at least strike something in the heads of those theme developers here that don’t think they should be using plugins. If nothing else, think of the amount of hours you will save using (even your own) plugins when developing your themes.

I’m actually surprised this wasn’t raised earlier in the discussion. It seems to make a lot of sense to me, I’d be interested to know more about you guys’ thoughts on it. Why might you think this isn’t easier / better?


can we also add a SSL check for all external scripts/styles loaded, Ive had some cases where assets fail because of SSL.
function prefix_styles(){
//Check if is ssl
$schema = is_ssl() ? 'https://' : 'http://'; 
wp_register_style( 'cw-font', $schema . 'fonts.googleapis.com/css?family=Noto+Sans:400,700,400italic' , array(), 1.0 , false  );    
}

Perhaps it would make more sense for these assets to be loaded without the protocol so they adopt whatever the current protocol is? Thoughts?


Unsure about the whole plugin concept – theoretically you’re making it hard for buyers to “buy” a theme. If what your stating is concrete a user will buy a theme via TF and have to download additional plugins for that theme to work, doesn’t this mean that a user is purchasing a broken theme from the start and will have to piece it together like a jigsaw puzzle – this is very bad for business and will force a lot of users to start selling away from TF (We saw it and thought we might move somewhere else for our debut theme).

Themes should work fine without the plugin in this case, and just gracefully degrade. Once the plugin is activated, the theme then incorporates that functionality.


And my another little problem would be the fact that, each theme being unique, having one plugin for shortcodes isn’t enough, each theme has individual features, individual shortcodes, basically demanding a new plugin for each theme. And this only for the shortcodes, if you have a portfolio too, you need another plugin. If you have something else, another plugin, we end up selling more plugins than the whole theme itself, let’s not forget that we’re on ThemeForest and not CodeCanyon.

Why is that? Why not be on both? (Genuine question!)


twitter api v1.1 need curl and base64_encode, so it’s allowed? or ignore it and don’t use twitter feeds as widget

Twitter API v1.1 doesn’t need curl (use WordPress functions instead, it’s what they’re there for), and base64_encode is listed as an exception to the rule (so is allowed) :)


If Themeforest wants me to add this functionality to a plugin, there should be a way for me to also be able to update my plugin. simple as that. Its the distrubution that’s the problem.

Quite right. The auto-update functionality we have for ThemeForest doesn’t yet work the same way with CodeCanyon. We need to fix this!


Just saying it’s an option. If you do not want to share your plugin (which is fine), then include your own custom updater like @Astoundify mentioned. As far as I know TF does not prevent this, but if they do, it SHOULD be allowed.

It is allowed, and at some point CodeCanyon itself will support this, as ThemeForest does.


Most of the discussion here is simply the result of bad communication by Envato if you ask me. The draft for those rules was available months ago and was sent to some authors for feedback. This is part of what I provided as feedback:

...

I still think this makes sense and I think if it would have been added to the requirements this thread would probably have 15 pages less :P

Agreed :(

378 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh
says

Can someone from the TF staff please answer my question? Are page builders allowed? Yes or not?

Sorry! I have asked Siddharth to respond to this particular question, so I imagine he’ll reply soon.

378 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh
says

Guys, who are those “experienced authors” who agreed with this?... I bet that there is not even one from the top authors.

Actually, most were top authors. I’ll find out if we can disclose this info.

378 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh
says

Essentially, the longer you’ve been earning money on Envato, the more work you have to do now if you wish to hold on to that income. If you have a dozen, two dozen, three dozen themes up on TF, you’ll be facing busy times indeed. It’s like a retroactive law; you’re kind of being punished for something that was completely permissible at the time you did it…

Maintenance is a part of selling themes. Over time, they need to be updated. Themes that were accepted when standards were low affect the reputation of the marketplace as a whole if they aren’t brought up to meet the standards.

We ran these guidelines by a number of authors, some who do have more than two dozen themes.

378 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh
says

If we will work on this new Submission Requirements, I hope themeforest can build a theme framework to us, then we can all build theme based on the framework. So the theme will meet the Submission Requirements. haha…

Have you tried using OptionTree at all?

378 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh
says

this requirement will force us as author to build BLOG themes with no creativity, or other feature that can be exposed. its just nightmare.

I’m really sorry that you feel this way, because realistically, that’s not at all the case.

378 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh
says

Do you expect that forcing authors to move features from theme to bespoke plugins will allow end users to switch from this to this seamlessy ?

More likely, each theme will include its own set of custom plugins that would need to be mandatory installed to replicate the demo and to mix them with previous themes custom plugins will lead to anything but a seamless experience for buyers and authors.

Who’s going to deal with raging buyers when everything will break horribly (because it will) ? Who’s going to bear the burden of support ? old theme author ? new one ? you think buyers will accept “we can only support our own theme/plugins when used together” kind of answer ?

Who asked for this changes ? buyers ? I doubt so, having dealt with thousands of them myself and not yet having found one who cares about the issues you’re trying to address with these new rules.

You make some interesting points, and we’ll definitely be discussing them.


You’re trying to enforce wp.org rules on TF when TF products are anything like wp.org ones.

Interesting distinction you make. Do you believe your customers will only use a ThemeForest theme and its bundled plugins, without any plugins from wp.org? And that plugins bought from CodeCanyon will only be used with ThemeForest themes, and not themes from wp.org?

Shouldn’t they all play as nicely together as possible?

378 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh
says

First of all, 3 weeks is a joke and even further grace period is a joke for existing themes. We simply needs MONTHS to apply these changes gradually.. like a few per update.

Three weeks was our initial thoughts before we start applying all these to newly submitted themes. We’re happy to take your feedback into consideration on this though, of course!

As for existing themes, we know it’s going to take months, and you’ll have them :)


“Inadmissible shortcodes” will not be allowed in “shortcode” plugins If that’s true do you know how buyers will react?

That’s not what we said, so let’s assume it’s not what we meant ;)

These will be inadmissible in the theme. Shortcodes should be in plugins, not the theme itself, as much as possible.

378 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Located in Australia
+4 more
Japh
says

Hi, Japh: I do not agree with this view. If you set the post counts options for category, not mean it will change the global posts_per_page parameter. Also If the theme has portfolio and blog, then the layouts of portfolio and blog are different, the users need to set each post count for the portfolio and blog.

Good point, thank you. Will take this into consideration.

by
by
by
by
by
by