16 posts
  • Has been part of the Envato Community for over 5 years
  • Located in Brazil
  • Has collected 1+ items on Envato Market
  • Sells items exclusively on Envato Market
theux says

Hello everyone,

I’m personally really happy with these guidelines, maybe because my most recent themes already comply with them! :P

However, I strongly disagree with the CDATA requirement:

JavaScript loaded directly into HTML documents (template files) should be CDATA encoded to prevent errors in older browsers.

What older browsers? Browsers others than the ones officially supported by the Theme?

According to the W3C (see http://www.w3.org/TR/xhtml1/#h-4.8 ), wrapping inline JavaScript code with CDATA markers will prevent ”<” and “&” to be treated as the start of markup by the XML processor.

The above is true for XML document (including XHTML), but not for HTML documents (including HTML5). Therefore, whether we should use CDATA markers or not depends on both the doctype declaration and the inline javascript content. Please see Should I use CDATA in HTML5?.

For any HTML documents, not only CDATA is useless, but it is cumbersome as it requires to be commented out as they are not valid HTML syntax (i.e. <!--//--><![CDATA[//><!--...//--><!]]>...), while for XHTML or any other XML document (like SVG or MathML) the simpler basic syntax is to be used (i.e. <![CDATA[...]]).

I believe that the “errors in older browsers” mentioned in the Submission Requirements, refers in fact to the errors caused by the use of CDATA wrapper itself in HTML documents (which should not be used in such documents)! Those errors are solved by commenting out the CDATA wrapper with an appropriate syntax – or should I say a “complex” commenting syntax – and the older the browser you want to fix this misuse for, the more complex the syntax gets (see Joel Purra’s answer on this).

Requiring to add CDATA markers in all cases for all Themes is irrelevant and totally cumbersome. The reason why WordPress adds CDATA markers to the XML outputs (i.e. RSS) is because those are… XML documents. And regarding the wp_localize_script() method, it isn’t aware of the doctype being used, nor if the inline javascript outputted will contain any of the problematic characters (i.e. ”<” and “&”), and it does so with special commenting syntax to not break HTML documents (for which the CDATA marker is not compatible with).

I believe you should definitely review this requirement for better code quality. You could simply rewrite it like so:

  • Inline JavaScript should be wrapped with CDATA markers if the Theme uses an XHTML Doctype
  • Inline JavaScript should not be wrapped with CDATA markers if the Theme uses an HTML Doctype
  • CDATA wrappers, if used, should be commented if the Theme uses mixed XHTML and HTML Doctypes
  • CDATA wrappers, if used, should be escaped using special syntax if the Theme uses mixed XHTML and HTML Doctypes, and if the Theme supports pre-IE6 browsers, “to prevent errors in older browsers
I sincerely hope that my thoughts clear things up a little so the Submission Requirements can be improved in order to avoid useless degradation of the global code quality on ThemeForest :) Best, Jonathan

Jonathan is right. The CDATA requirement must be reviewed.

98 posts
  • Has referred 10+ members
  • Has sold $500,000+ on Envato Market
  • Has collected 100+ items on Envato Market
  • Elite Author: Sold more than $75,000 on Envato Market
+4 more
bringthepixel says


I don’t understand why “Tabs must be used for indentation—not spaces’’ is a better guideline than let’s say “Responsive design is a must have”. And guess what, everybody makes responsive themes without guidelines :) regards, Michael

Firstly, it’s standard practice for WordPress to use tabs over spaces.

http://make.wordpress.org/core/handbook/php/

Secondly, it results in smaller file sizes. One character, instead of four.

Third, consistency. One isn’t strictly better than the other (tabs v spaces)—the point is to be consistent, and TF just happened to request consistency in keeping with WordPress standards and practices.

None of the more stringent code formatting rules—just use tabs instead of spaces. It probably makes reviewer’s lives easier.

If it irritates you, indent each level four tabs instead of four spaces. That’ll teach ‘em!

I get it. And I use tab indentation:). My point is that coding rules are really important just for a small group of our clients, and responsive design affects everyone. Most clients don’t care if there are four spaces at the beginning of each line instead of one tab.

49 posts
  • Has been part of the Envato Community for over 6 years
  • Has collected 1+ items on Envato Market
carlhancock says

I get it. And I use tab indentation:). My point is that coding rules are really important just for a small group of our clients, and responsive design affects everyone. Most clients don’t care if there are four spaces at the beginning of each line instead of one tab.

I’m sorry, did I just read you say clients don’t care about coding standards as if therefore it shouldn’t matter to you? The average customer doesn’t care about coding rules and standards because they don’t know what they are which is why they are buying your theme expecting you to be a professional and apply best practices, code rule and standards for them.

Sure the average customer buys superficially. Design and features. But they damn sure car when their beautifully designed themes is a disaster under the hood causing plugin conflicts, etc. Then they learn to care.

That’s why it is so damn important that if you are selling themes (or plugins) that you apply best practices. You abide by coding rules and standard. You do the right thing even when the customer wouldn’t have any idea because you simply want to do the right thing.

A good theme should be just as beautiful under the hood as the design the client and visitors see.

I can’t believe I actually heard you say the customer doesn’t care about code rules and standards so why should the developers building the them? Incredible.

If I ran Envato I’d ask any author that thought that this was a good idea to kindly leave and sell their good elsewhere.

If you are going to sell themes (or plugins) you better know your shit. That means applying best practics. That means applying good coding rules and standards to your code both on the fronted and backed. You damn sure shouldn’t fight having best practices and coding standards that are ultimately improve your product.

There’s a lot of people selling commercial themes and plugins that have absolutely have no business doing so and the code quality and problems they cause cost other people money.

We’ve fixed so many ThemeForest themes while supporting Gravity Forms so to poor code causing a plugin conflict and breaking functionality. We helped them. We fixed the issue. Now every one of those customers will no longer buy from ThemeForest as a whole because the theme authors bad code makes ThemeForest and Envato look bad in the process.

The theme author ultimately has no clue their poor code just cost us more support time which means as one of the co-founders of our company those support hours cost me money. A lot of support dollars wasted by theme developers who didn’t know what they are doing and had they followed best practices, has they applied the rules and guidelines their new coding standards call for, these conflicts would not have occurred.

These coding standards are a positive thing for the entire community. Instead of complaining or fighting these new rules, people should go learn what they need to change to meet the standards and start applying them. This change by Envato is fantastic and long term ThemeForest will be a more reliable source of WordPress themes because of these changes.

It may also help weed out the authors that shouldn’t be selling themes because they really don’t know what they are doing.

It’s easy to make a WordPress theme. It’s much harder to make a good WordPress theme.

106 posts
  • Has been part of the Envato Community for over 4 years
  • Has referred 1+ members
  • Located in Australia
  • Has sold $1,000+ on Envato Market
+2 more
pjtops says

Firstly, it’s standard practice for WordPress to use tabs over spaces.

Secondly, it results in smaller file sizes. One character, instead of four.

Third, consistency. One isn’t strictly better than the other (tabs v spaces)—the point is to be consistent, and TF just happened to request consistency in keeping with WordPress standards and practices.

None of the more stringent code formatting rules—just use tabs instead of spaces. It probably makes reviewer’s lives easier.

If it irritates you, indent each level four tabs instead of four spaces. That’ll teach ‘em!

Meanwhile, in the larger PHP community, when they require the use of tabs over spaces, its usually only on April 1st – april fools day ( http://philsturgeon.co.uk/blog/2013/04/psr2-the-tough-decision ) . I think on this one, Envato should just let authors pick whatever they are comfortable with, as long as they apply it consistently, whther its tabs or spaces.

98 posts
  • Has referred 10+ members
  • Has sold $500,000+ on Envato Market
  • Has collected 100+ items on Envato Market
  • Elite Author: Sold more than $75,000 on Envato Market
+4 more
bringthepixel says

@carlhancock

Sorry for misunderstanding. I’ll try to be more specific this time.

Responsive design is a must have option today and it should be a standard TOO

366 posts
  • Has referred 10+ members
  • Has sold $40,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Made it to the Authors' Hall of Fame
+2 more
codenegar says

One of my clients has bought a theme that uses WordPress options framework which is published under GPL license, but the theme uses split licensing. Should I do something about it or just it’s not my business?

1 post
  • Has been part of the Envato Community for over 5 years
  • Located in Australia
  • Has collected 10+ items on Envato Market
ahortin says

There’s not a lot that I can say that hasn’t already been said by the likes of @carlhancock, @mordauk and @japh. What I would like to say though, is congrats to @japh, @collis and the rest of the Envato team for implementing these new guidelines. They’ll go a long way to improving the quality of the themes sold on ThemeForest.

I’ve implemented a huge number of themes in the past, for clients, on behalf of other designers and agencies. A large number of those have been themes from ThemeForest, simply because it is such a huge market (They’ll typically provide the theme they want implemented). Without fail, it’s always the ThemeForest themes that are the absolute worst to work with. This includes themes from the so called “Power Elite Authors”. Sure, the themes look beautiful, but the code behind them is (usually) absolutely shocking. It’s ridiculous that so many of these themes can’t be used with child themes, so after making a few changes, they’re virutally impossible to update. It’s even come to the point, several times, where it was easier to re-code the design myself, from scratch, than trying to modify the theme. Just this last week I had to tell one of my clients that they will need to look at buying another theme because the (ThemeForest) theme they chose for their client, broke when I updated WordPress to v3.5.2. You can’t roll that out to a paying customer. It’s completely unconscionable.

Moving elements like shortcodes and sliders, to separate plugins, rather than being bundled in the theme will be great to see. They should be in plugins! Your theme shouldn’t provide 200 shortcodes, 15 sliders, contact forms and CPT’s. 99% of the time your customers don’t need, nor use, even three-quarters of these features. They base their purchase on how your theme looks and in the end, they end up with this bloated and slow theme. I’ve lost count the number of times I’ve seem themes include dozens of scripts and stylesheets for various sliders, when only one slider is being used! That’s just terrible coding!

After reading through these replies (yes, all 58 pages!), it’s disappointing (but not surprising) to see the number of theme authors against these changes, even to the point of arguing that they should be allowed to use inline styles! Having themes that adhere to WordPress standards and best practices is a good thing, guys! If it turns out, that as a theme author, you’ve got a lot of work to do to tidy up your themes, then you’ve obviously been doing it wrong! As a theme developer, you owe it to your paying customers to develop themes using best practices and if you’re saying that “most clients don’t care”, then you shouldn’t be developing themes, fullstop! You’re right, most people who buy themes wont know anything about code, but that doesn’t mean that you should write badly coded themes or sloppy code. Take some pride in your work. I’m guessing there wouldn’t be too many themes here that would get past the strict guidelines implemented on the official WordPress Theme Directory. It’s great to see that Envato are making such an effort to improve their theme quality, along these sorts of guidelines. It’ll be a great day when people can buy a ThemeForest theme, knowing that they’ve got some quality code behind their site.

78 posts
  • Has referred 100+ members
  • Has sold $40,000+ on Envato Market
  • Has collected 100+ items on Envato Market
  • Has been part of the Envato Community for over 6 years
+2 more
adiacone says

It’s great that there’s now a common language theme authors can use!

I chose not to invest time in creating my own complex framework, but I totally understand why some authors might be concerned about the issues they will encounter when updating existing themes. It’s gonna be a challenge and it’s gonna make many, many lines of code previously written difficult to adapt or even unusable for some.

When it comes to new releases, I think authors should understand that the days of “all in one” themes are over and that from now on they should ditch the composers and builders and focus on creating more nicely designed niche themes that use little options and the leverage default WordPress features. It’s what I intend to do from now on.

If you’re thinking “buyers won’t like this and that” or “buyers want this and that in their themes”, remember that in most cases (and I don’t mean to offend anyone here) buyers don’t know what they want, so you should give them what they need, not what they want.

These requirements will definitely make a lot of unhappy authors and while they are still work in progress, I hope they won’t suffer major changes. I also hope that once they are in place, everyone will get equal treatment during the review process.

138 posts
  • Has referred 10+ members
  • Has sold $75,000+ on Envato Market and is now an Elite Author
  • Has collected 50+ items on Envato Market
  • Elite Author: Sold more than $75,000 on Envato Market
+3 more
M-Theme says

Hi, Japh:

If we are using the TGM plugin, will get the RECOMMENDED information from theme check, is it allowed?

158 posts
  • Elite Author: Sold more than $75,000 on Envato Market
  • Has sold $125,000+ on Envato Market
  • Sells items exclusively on Envato Market
  • Made it to the Authors' Hall of Fame
+6 more
nagaemas says

When it comes to new releases, I think authors should understand that the days of “all in one” themes are over and that from now on they should ditch the composers and builders and focus on creating more nicely designed niche themes that use little options and the leverage default WordPress features. It’s what I intend to do from now on.

Don’t do that! You can still be creative with your themes ;)

Helpful Information

  • Please read our community guidelines. Self promotion and discussion of piracy is not allowed.
  • Open a support ticket if you would like specific help with your account, deposits or purchases.
  • Item Support by authors is optional and may vary. Please see the Support tab on each item page.

Most of all, enjoy your time here. Thank you for being a valued Envato community member.

Post Reply

Format your entry with some basic HTML. Read the Full Details, or here is a refresher:

<strong></strong> to make things bold
<em></em> to emphasize
<ul><li> or <ol><li> to make lists
<h3> or <h4> to make headings
<pre></pre> for code blocks
<code></code> for a few words of code
<a></a> for links
<img> to paste in an image (it'll need to be hosted somewhere else though)
<blockquote></blockquote> to quote somebody

:grin: :shocked: :cry: Complete List of Smiley Codes

by
by
by
by
by
by