Posts by Japh

374 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

Envato should stop the non sense of the plugin concept and keep the rest, unless we are to add to every theme’s description “What you see is not what you get – you have download aaaaaall kinds of plugins for it to work”.

As has been said already, the theme should work fine without the plugins installed, just have reduced functionality.


It’s up to the theme anyways on handling the output of the plugins :)

This.


But If I (authors) won’t update my old theme in next eight week, what would be happen?

Nothing until a bit further down the track, once the requirements list has had a few adjustments, when we begin the project to gradually ensure all existing themes comply with them too. There’ll be a LOT of notice given before we require this though, and we’ll work with authors to help the transition.


This is exactly what I was referring to in my previous post. It is not up to authors, such as Carlhancock or even Envato itself to decide what a “theme” is meant to be, it is the buyers who decide what they want for their cash. If you aren’t selling what buyers expect and want, care to hazard a guess as to what’s going to happen to Themeforest’s reputation and sales numbers? Currently Themeforest themes are turnkey solutions, you buy it, install it and bam you have a full website for under $50. And what has happened over time? Themes became more and more complete over the years and has led to more and more buyers buying themes. This being right or wrong doesn’t matter, it’s the reality of the TF market and changing themes to be more like “skins” would affect everything.

This is an interesting mentality… the problem is, buyers also want to be able to use the plethora of plugins and resources available for WordPress outside of ThemeForest. In that case do you believe buyers should choose one or the other? Either you have a WordPress theme from ThemeForest and accept that your site will probably break using outside plugins, or does ThemeForest make some changes to try and make their themes play nicely within the rest of the WordPress ecosystem?

What are your thoughts?


+1 I’m totally disappointed, no words :( 2 years of hard work, branding custom developed page builder and now I have to become a plugin developer instead of creating cool themes.

Why do you feel this is mutually exclusive? Why not convert your page builder into a plugin, and use that plugin across all your themes? Is this really such a terrible change for you? I genuinely want to understand the issue for you here.


I agree with you. Until now it has 360+ replies. I think it will not make any changes. We can all stop to talk about the topic. All are going to sleep.

These 360+ replies will be the basis for the first round of changes to the requirements list. We’re not going to make an adjustment after each of the 360+ posts ;) But trust me, we are reading and listening and trying to understand so we can make this work for everyone.


3. Themes will be required to use whichever version of jQuery ships with that version of WordPress.
4. Authors are not allowed to deregister the default version of jQuery and load another one.

Whats wrong if we use the newer version of jquery?

There’s no need to do so, and it means you’re using a version of jQuery that’s not been thoroughly tested with WordPress. Considering how often WordPress updates, is there really some new feature in jQuery that you can’t wait a few months to have available? Surely not!


How should i rewrite this theme with plugins?

I’d love to sit down with you on Skype sometime and work that out! Good real-world case for you to demonstrate some of the points from this thread to me.

374 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?

374 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?

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

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

374 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!

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

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

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

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

by
by
by
by
by
by