147 posts
  • Has referred 100+ members
  • Has sold $125,000+ on Envato Market
  • Has been a beta tester for an Envato feature
  • Elite Author: Sold more than $75,000 on Envato Market
+3 more
Jozoor says


Moving towards a plugin centric is a good idea however for it to work I think we will also need some standardized plugins for the common theme features. Otherwise, we are going to end up with 1000 different shortcode plugins, 1000 different portfolio plugins, etc which is going to make things just as complicated. I know this was something that was suggested a while back but I don’t know how far the idea progressed.
That’s not good. Maybe one uses bootstrap for all their themes, maybe another uses skeleton, limiting the authors to certain plugins is like limiting clients from modifying the themes they buy

+1 i’m with you for that , really should envato team see that.

1476 posts
  • Has referred 1+ members
  • Has sold $10,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Made it to the Authors' Hall of Fame
+3 more
OriginalEXE says


@nagaemas did you check this: https://gist.github.com/bitfade/4555047
Yes I know about this, but I thought this is no longer allowed after this change? Correct me if I’m wrong ;)
It should be since it only affects shortcodes you define and does not mess with filters.
49 posts
  • Has been part of the Envato Community for over 6 years
  • Has collected 1+ items on Envato Market
carlhancock says

Regarding column shortocde, I really don’t understand why it needs to mess with filters for it’s functionality?

Like I said in one of my replies just before this one, the issue isn’t necessarily the column shortcode directly. Although sometimes it is. It depends on how the column functionality is implemented.

In some situations the column shortcode itself isn’t the issue, it’s the fact that auto-formatting that WordPress does on content placed within a column shortcode causes issues with the display of the columns and the content on the front end.

Because of that it is typically paired with another shortcode such as RAW or NOFORMAT so that the content placed within the column is encapsulated in a shortcode that does not apply the WordPress auto-formatting. Because the WordPress auto-formatting can cause issues with the content within the columns lining up properly, etc.

Obviously there are ways to get around this if you really put your mind to it. The problem is most people aren’t doing that. They are re-using existing code, etc. without realizing the consequences. People are copy-n-pasting code to accomplish something and that code is doing it in a destructive way. Which is how the RAW/NOFORMAT shortcode spread to so many themes both on ThemeForest and elsewhere.

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

@carlhancock Let’s not talk about the restrictions of shortcodes on ThemeForest, but is there anyway to fix the broken shortcodes caused by wpautop that you can think of without modifying wpautop and without using filters? Because the native shortcode_unautop is not very useful before they patch it :(

Like I mentioned to another commenter, I don’t have a solution to this particular issue. But the one on github pointed out by @OriginalEXE might possibly be an option, although i’ve never used it and I can’t say if it is or isn’t allowed under Envato guidelines.

I just know that the RAW/NOFORMAT method that lots of theme developers have been using is very destructive and should be avoided.

I completely understand the issue it’s trying to solve. It’s a real issue that can be a pain in the butt to deal with. Unfortunately this particular solution causes far bigger problems in the process of fixing a single problem. It’s a destructive solution.

731 posts
  • Has referred 500+ members
  • Has sold $125,000+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Elite Author: Sold more than $75,000 on Envato Market
+7 more
mordauk says

Like Carl, I do not know of a solution that actually fixes the formatting caused by wpautop, but I can say that the issues caused by messing with the default content filters are much more drastic than the inability to easily use column short codes.

The entire idea of a column short code is against what short codes are supposed to be anyway, but that’s a whole other debate :D

3231 posts
  • Has sold $5,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Located in United States
  • Has been part of the Envato Community for over 4 years
+1 more
organicbee says

Like Carl, I do not know of a solution that actually fixes the formatting caused by wpautop, but I can say that the issues caused by messing with the default content filters are much more drastic than the inability to easily use column short codes.

The only real solution would be something in the core, for example wptexturize has the no_texturize_shortcodes filter there needs to be one similar shortcodes as well but thats a discussion for another thread

607 posts
  • Has sold $10,000+ on Envato Market
  • Has been a beta tester for an Envato feature
  • Has collected 1+ items on Envato Market
  • Member of the Envato Team
+10 more
Siddharth Envato team says

At this juncture, I’d like to ask everyone, politely of course, to stick to the topic at hand. You’re more than welcome to open a separate thread with your tangential questions. Thanks for listening!

With that, I’m out for the week end as well. I’ve made a list of specific posts, and the questions they raise, so the team can further discuss things and tweak a few things. Topics like page builders and bespoke, super specialized themes are definitely on the list.

Rest assured that, as the famous Dr. Crane says, I’m listening.

Have a great week end everyone!

147 posts
  • Has referred 100+ members
  • Has sold $125,000+ on Envato Market
  • Has been a beta tester for an Envato feature
  • Elite Author: Sold more than $75,000 on Envato Market
+3 more
Jozoor says

really some points good , but others need more discussions about that.

my ask now :
are all this Requirements for our old themes , or just new themes .. ?
i mean , should update old themes to be okay with all this Requirements ..? or not ?

thanks.

1476 posts
  • Has referred 1+ members
  • Has sold $10,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Made it to the Authors' Hall of Fame
+3 more
OriginalEXE says

really some points good , but others need more discussions about that.

my ask now :
are all this Requirements for our old themes , or just new themes .. ?
i mean , should update old themes to be okay with all this Requirements ..? or not ?

thanks.

Yes you should but as they said, you will have much more time (undefined, but in months) to standarize the old themes.

11 posts Performance Experts
  • Has referred 1+ members
  • Has sold $75,000+ on Envato Market and is now an Elite Author
  • Has collected 1+ items on Envato Market
  • Elite Author: Sold more than $75,000 on Envato Market
+3 more
JoNa 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

by
by
by
by
by
by