Another thing to point out is the required use of “
What if a theme only needs to echo the thumbnail url, and not the complete.. then Theme Check will say “
<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; ?>
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
if ( false ) the_post_thumbnail();
Just kidding, but yeah, it should not be required.
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.
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.
...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.
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.
“index.php should be reserved for the normal blogroll.” What is “normal blogroll”? List of posts?
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.
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.
..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.
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!