Posts by Japh

373 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

So let’s assume that You created theme with all new requirements. You have “base” theme with own css file and some javascript files. On top of that with use TGM You pack 5-10 plugins so few more css files and even more javascript files. Yey, we have theme that is with “standards” that load 10 css files and 20 javascript files. This is so nice solution! We are making things better! And question: After that all we have 100% that functionality from one theme will work with other? No.

If the implication here is that a problem has been created regarding the number of CSS and JS files, that is very easily rectified, by any customer who cares to do so, with a caching plugin. Again, this is why standards are important, as loading CSS or JS files in a non-standard way would mean this solution wouldn’t work.


And why TGM? Envato need own solution for this, solution that we can base on. If whole marketplace need split themes functionality to plugins and pack them with themes You can’t relay on some else to do this.

Because TGMPA already exists. Why duplicate effort? Why not contribute to something that already exists so everyone can use it? If it so happens that Thomas decides not to continue maintaining it, it’s open source and we can continue to maintain it ourselves.

Are you not relying on WordPress itself in much the same way already?

373 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

Just a quick question. Can we use social links (twitter/facebook etc) in the theme to share the posts? These links use iframe to display their buttons and you get the “INFO” message that the iFrame has been used.

Considering the number of plugins available that do this, I’d be interested to know why you’d want to?

373 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 I include all my functionality in one plugin or will it need to be different ones?:

one restaurant pack plugin

vs

1 plugin for food menus —1 plugin for reservations - 1 plugin for specials & promotions

Assuming the functionality makes sense together, this is exactly what I would expect. A restaurant plugin that gives all restaurant functionality to a theme that supports it.

373 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

Another questions: Is it OK to pack your own set of plugins inside the theme folder for buyers to upload and activate? Like said in the TGM instructions:
'source'                => get_stylesheet_directory() . '/lib/plugins/tgm-example-plugin.zip', // The plugin source
Does this mean every theme folder will be packed with plugin files? If so… is that a good thing since a plugin should be in de plugins folder ?

Yes, this is ok, and no that’s not how TGMPA works. The plugin is installed from the packaged location into the plugins directory by TGMPA.

373 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

CodeCanyon is great, but I don’t think it’s a viable solution here. If I’m a user and I buy a theme on TF that has some certain functionality, then I find out I have to buy a plugin on CC, I’m going to be very upset. Selling functionality twice is very dishonest, IMHO.

It would be dishonest, and it’s not what I’m suggesting. In this scenario, the theme would say something like “supports X functionality with [linkhere]Plugin Y[/linkhere]”. Modularity FTW!



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?
Personally, I think it a wash. You can make valid arguments for and against its usefulness.

What are the valid arguments against?


I believe scripts should ideally be loaded with no protocol specified ex:
//domain.tld/filename.ext
, but keep in mind that that doesn’t work on local (MAMP-based) servers where the protocol is
file://dir/dir2/filename.ext
.

Unless you configure your MAMP server to support it ;)


Because as Siddarth stated above, the reason you’re doing this in the first place is flexibility and modularity. ;)

Hmmm… that doesn’t make sense to me… using CodeCanyon is just as flexbile and modular!

373 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:

373 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 :(

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

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

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

by
by
by
by
by
by