Posts by JoNa

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
+2 more
JoNa says


As the user can choose to use the default version of jQuery included in WordPress, does that make my themes acceptable? Leaving the option for the users to go beyond the limitations of an old and locally-hosted version of jQuery is an important key for speeding up the page-load performance and provide the best experience possible.

Making sure the default version isn’t swapped by default is a good start. Having said that, I have some reservations.

Going from version 1.9 to 2.0, jQuery has dropped lots of legacy code that might be a deal breaker for other plugins that the buyers might be using which will break browser compatibility. Not to mention other breaking and/or API changes that plugins may rely on which will break it outright. Using migrate is a good choice here, as you’ve done so but I’d advice judicious use of this feature you’ve built as there could be lots of pain points in the future.

As long as the default behavior isn’t breaking and this behavior is documented pre-sales, it should be good to go.

Awesome, thanks for the detailed reply!


nothing against your page speed optimizations, we do ship with minified css/js as well but jQuery is wp core and shouldn’t be altered in any way, most recent version could still break 3rd party plugins.

The jQuery Migrate plugin is here to keep compatibility with old third-party plugins, please take a look at the jQuery site for more information: http://jquery.com/upgrade-guide/1.9/#jquery-migrate-plugin

And if that’s not enough, the users of my themes can simply select to restore the default, older version of jQuery included in WordPress via a simple checkbox in the backend ;)

I truly believe in giving the choice to the users. Letting them choose which version of jQuery they want to use for their site, and if they want a recent one but also need to keep compatibility with old plugins, then they simply enable the jQuery Migrate plugin. This is all optional and up to the user, nothing is imposed, they can very well use the old version of jQuery packaged with WordPress. This is all the beauty of giving the ability to choose and not being restricted to our choice.

Now if you’re concerned about the added complexity and the eventual confusion added by those advanced options, I can prove otherwise with good backend structure and documentation, let me quote a recent comment I’ve received recently:

The most simple wordpress theme i have ever used, superb.
sunlife2000

:sunglasses:

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
+2 more
JoNa says


As you might already know, this introduces a compatibility issues: Starting with jQuery 1.9, all previously deprecated methods have been removed, therefore it might break old code relying on those deprecated methods.
imho, you should remove the jQuery part, even if optional. Inexperienced buyers would still enable that option without knowing the implications, some plugins would break, and they’re going to require support from either you or the plugin author.

Most buyers purchase my themes for their PageSpeed performance, and I can say after a few thousands sales that I received very few support requests related to the Speed Mode or the jQuery options. I believe that the very clear documentation included straight in the backend and displayed next to each option helps a lot! :)

Inexperienced buyers would still enable that option without knowing the implications
By the way, it’s the other way around: currently all my themes and templates come with the most recent version of jQuery, with both the jQuery Migrate plugin and noConflict() mode disabled by default.
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
+2 more
JoNa says

Hello,

Thank you for the great update! I’m very happy with these requirements. I have one question however regarding the “WordPress Assets” part.

I specialize in page-load speed performance (see my Hybrid Responsive & Retina WordPress Theme), and for that purpose I have developed what I call a “Speed Mode” for my themes. Besides other optimizations, the Speed Mode will minify and merge all CSS and javascript files. Also, for pure performance reasons, it offers to replace the WordPress’s jQuery with a newer version hosted on a public CDN (with a local fallback of course). This is for two main reasons:
  • The latest version of jQuery is faster and lighter
  • The jQuery file hosted on Google CDN is likely to be already cached in most browsers

As you might already know, this introduces a compatibility issues: Starting with jQuery 1.9, all previously deprecated methods have been removed, therefore it might break old code relying on those deprecated methods. The jQuery Migrate plugin has been created especially to address this issue and keep compatibility with old code. That is why my themes also offer the possibility to enable the jQuery Migrate.

All these options are available straight from the backend of my themes:

As the user can choose to use the default version of jQuery included in WordPress, does that make my themes acceptable? Leaving the option for the users to go beyond the limitations of an old and locally-hosted version of jQuery is an important key for speeding up the page-load performance and provide the best experience possible.

Of course, my implementation makes use of the native wp_enqueue_style() and wp_enqueue_script() methods.

Thanks for your confirmation! Best, Jonathan

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
+2 more
JoNa says

If we save through get_option there is a limit, saving in database table removes that problem and the slider can be use in multiple places , You cant have that if slider is created for a post only. Another alternative would be custom posts but it depends on author. For page builder same concept applies as templates can be reused again.

It is true that add_option/update_option has a limit, but a very high limit of 2^32 bytes, which is 4 GB of data, that’s a lot! :)

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
+2 more
JoNa says

Project Source: Lightning-Fast & Responsive HTML5 Website Template
featuring hybrid sticky/collapsing header, modern parallax landing-page and exceptional pagespeed performance

http://themeforest.net/item/project-source-corporate-html5-responsive-website/3158481

:)

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
+2 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

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
+2 more
JoNa says

That’s great! I’m in 8-)

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
+2 more
JoNa says

Envato meetup:

I couldn’t stop laughing :bigsmile:

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
+2 more
JoNa says

That’s great! :)

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
+2 more
JoNa says

There’s a spelling mistake on the word “Envato” at the end of article (14):

if the Product was bought using Envato Credits, the Buyer will be refunded in Envator credits;

;)

by
by
by
by
by
by