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

Another thing to point out is the required use of “get_post_thumbnail”..

What if a theme only needs to echo the thumbnail url, and not the complete <img src="url" />? If something like this is used to get the url only: <?php $image_id = get_post_thumbnail_id(); $image_url = wp_get_attachment_image_src($image_id,'large', true); echo $image_url[0]; ?>

.. then Theme Check will say “get_post_thumbnail” is not used… Unless someone knows a better way to do the above, this should probably be under the exceptions as well.

Maybe like this :P

if ( false ) 
the_post_thumbnail();

Just kidding, but yeah, it should not be required.

649 posts
  • Has been part of the Envato Community for over 3 years
  • Has sold $10,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Sells items exclusively on Envato Market
+1 more
ChapterThemes says

Builders and all the beautiful options, features and possibilities should stay – period. The ability to create such things with tools and hooks provided by WordPress IS the power of WordPress.

The realy big problem is what to do when theme related functions are portable plugins. Will themes get prices around 100 bucks? If not: Can you develop the plugin in a way it can only be used with the theme?

No way i’m going to create portable plugins with a beautiful theme so that people can purchase a nice set of plugins for only 45 bucks.

Maybe there’s a second agenda to give codecanyon a boost i don’t know, But besides all the “good practises” idea etc, that’s the real problem for authors who make a living creating beautiful items.

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

Well the way I’ll do it is if my theme is not used, but plugin is, only cpt’s and meta fields will be displayed, as well as shortcodes parsed in content, but nothing else.

6 posts
  • Has been part of the Envato Community for over 1 year
  • Located in Canada
StyledThemes says

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

Unfortunately a lot of customers do base their buying decision on the visual aspects of themes and huge list of features showing 200+ shortcodes, thinking wow! But even though I completely support the standards that Envato is implementing (finally), there is one thing that has become the norm at TF….that’s making a designer feel they have to load up their themes with so much crap in order to compete and be approved by reviewers to make the massive $$ that they see.

Still, it’s really more of a balance of good looks and properly coded themes that will be good for the end-user with the changes, as well enabling the ease of tension when it comes time to upgrade WordPress or plugins without worrying if something is going to crash and burn. Providing support is also a key factor in a good theme.

33 posts
  • Has been part of the Envato Community for over 2 years
  • Has collected 1+ items on Envato Market
  • Sells items exclusively on Envato Market
  • Located in United States
JonnyShogun says

I notice that in the Theme Check plugin when running tests, it displays that it is REQUIRED for add_theme_page() to be used in place of add_menu_page().

I’m not understanding why add_menu_page() is REQUIRED instead of RECOMMENDED? Since add_menu_page() adds a top level menu item, whereas add_theme_page() only adds a submenu under the Appearance top level menu. Why does the Theme Check plugin have this as REQUIRED instead of RECOMMENDED, when WordPress Codex has that method available for wp developers to use? And the various themes sold on ThemeForest have top level menu items to group and organize their option page menus for usability to the end user.

If my admin options I’m making for a theme have many option pages, I want to group my theme pages together under my own top level menu item. It will be very impractical to use add_theme_page(), which would make all my option pages submenus under the Appearance menu. I want to group my option pages together so the end user doesn’t get confused when using my theme and navigating the backend which is a usability issue! That is why i would use add_menu_page().

Anyone else seeing this error thrown in the Theme Check plugin? And think that it should be RECOMMENDED instead of REQUIRED?

I emailed Enavto Support regarding this issue with the Theme Check plugin, and will post if I receive an answer.

thanks!

21 posts
  • Has been part of the Envato Community for over 3 years
  • Sells items exclusively on Envato Market
amabil says

“index.php should be reserved for the normal blogroll.” What is “normal blogroll”? List of posts?

1 post
  • Has been part of the Envato Community for over 2 years
  • Has collected 1+ items on Envato Market
  • Sells items exclusively on Envato Market
wecodemore says

Some additional notes:

Tabs/Spaces – as IDEs, text- and online code editors interpret tabs differently, it’s not OK to use tabs after the first character on each line. The rule is simple: Never ever use spaces before the first CHAR in a line. And never ever use tabs after the first CHAR in a line.

Just copy/paste the code from following gist into some IDEs (and play around with key length) to see that in some IDEs some lines will “jump” and be misaligned. https://gist.github.com/franz-josef-kaiser/5943797

The reason is simple: Every IDE interprets tabs in a different way. And you can as well set a custom length – from 4 to 8 spaces, etc.

Curly brackets vs. endif/endforeach/etc. – As discussed in a lot of threads on the whole internet, there’s no point in this discussion where people will agree with each other. But, there’s one thing to keep in mind, when it comes to WordPress: Some developers bring in the argument that it’s easier for users to read and understand code when they see the end*; parts. And those devs tell that they will only use it inside tempaltes – “for the user”. The thing those developers forget is, that WordPress is using the “Plugins API” – in other words the action/filter/hook-callback hell. Now a lot of code is buried there. Starting from nav menu callbacks to gallery shortcode MarkUp, etc. So if you’re not consequent on don’t use the end* everywhere(!), you better avoid it, as you’ll force your users to learn both(!) styles of coding.

Wish all you a happy coding day and please keep those two things in mind.

Best wishes, Kaiser.

20 posts
  • Has been part of the Envato Community for over 1 year
teamCrisis says

Please, explain why and how users will create columns, accordions and toggles, if they have no idea about html/css? Thank you.

I don’t think the new requirements are saying you can’t have the shortcodes at all. I think they are saying that these shortcodes cannot be bundled within the actual theme. If you want to provide these shortcodes, you must do it by including them in a plugin so they are portable.

63 posts
  • Has sold $10,000+ on Envato Market
  • Has been a beta tester for an Envato feature
  • Has collected 10+ items on Envato Market
  • Sells items exclusively on Envato Market
+1 more
PrimeThemes says

..In the end, over all this, what worries me too much is that now everyone will be able to use parts of our theme as plugins. And use these plugins with themes created by someone else. So why would someone purchase more themes from us, if they have all the functionallity already. They can go now and download free themes and use use our plugins to create the site they want, plus they have free updates for our plugins. Hmm, this is awesome, for somebody, but not for me as theme developer.

Absolutely!

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

I’m about 50% done of moving my code into separate plugins, and as far as I can tell, the plugins will keep working when switching themes, but without any extensive coding knowledge, it’s impossible for users to get a nice, beautiful looking layout. You’ll get a mess, for example Bootstrap columns on Twenty Eleven won’t fit in its main container as a row on Bootstrap is 1200px, the columns will overflow/vertically stacked. So no worries about users using the plugins on other themes, as of course there will be no documentation about the plugin API and the one who knows how to use it properly is only you!

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