Okay great, thanks for the prompt answers Japh.
Last one from me, can you define “theme-dependant widgets/meta boxes”?
Generally speaking I think these new requirements are needed and thank you for better explaining them. I do have additional questions:1. Must we use exactly TGM activation class or can we use our own?
Is TGM a must from now?
I got few another questions:
1. ThemeCheck reports error on lack of closing head and body tags, while it’s perfectly valid to omit these tags in HTML5
Is this a “rare exception” you mentioned in “WordPress Core API” point 2 ?
2. Do we need to strictly follow all WordPress Coding Standards specifically mentioned in http://goo.gl/ub4mY ?
It could be nice to start using PHP namespaces and autoloaders. And it’s very difficult if not impossible to follow WP Naming Conventions with SPL Autoloader.
3. WordPress Assets… How can we enqueue all stylesheets with wp_enqueue_style and support for example custom Google Fonts?
Are tools like Google Web Font Loader, Google Loader, Modernizr.load, RequireJS which loads scripts and styles asynchonously forbidden from now?
If in JSHint, than is it possible to provide default .jshintrc with predefined settings required by TF?
And what about vendor scripts that raise notices in JSHint?
Can Envato make a checklist that separates the functionality of these to be in the plugins and those that are to be in the template?
Plugins: - shortcodes - Custom meta boxes - Functionall widgets
Template: - Image sizes - Widgets zones – custom sidebars - Default widgets like calendar, last posts, last comments, archive, etc..
Overall changes are fine but licensing and integrating 3rd part plugins like Layer Slider must be well explained because it is a standard template for TF and now the authors of plugins can be deceived.
Ok, thanks for clarifying the above things. Sleep tight!
I just wanted to quickly pop in and say thanks for your feedback and questions for additional clarification in so many places. We’re capturing this feedback and will be discussing it with the team and clarifying further as soon as we can.
A big thanks to Japh, our WordPress Evangelist, for doing a smashing job answering questions here until late into the night and providing really fantastic assistance in getting this update out as soon as we could. Now that it’s late for Japh and I, we’ll be getting some sleep and will catch up with this thread first thing in the morning.
In the mean time, Sid, our Review Projects Lead and CodeCanyon Senior Reviewer, will be available for awhile longer to answer questions.
I have next custom theme widgets: Advertisment, Contact Form, Contact Information, Custom Links, Most Read Posts, Popular Portfolio Posts, Popular Posts, Recent Portfolio Posts, Recent Posts, Related Posts, Social Icons, Social Icons Alternative, Side Navigation, Twitter and Flickr.
Which one of the above widgets are theme-dependent and which aren’t except Twitter?
The ones for portfolio should be activated when the plugin for portfolio CPT is activated I suppose…
If there are another widget from the above which are not theme-dependent, then there should be a plugin for them I think. Which are the ones that should make part from this plugin and could this plugin to include Twitter widget also or not?
Thanks… This will be my last question today. At least I think…
Regarding theme frameworks, is it still possible to use Yootheme’s Warp framework, which uses profiles instead of child themes? I know that there’s been a few themes in the past that have used it and one wordpress one that does now – http://themeforest.net/item/beauty-salon-responsive-wordpress-template/2948075?WT.ac=search_item&WT.seg_1=search_item&WT.z_author=bdthemes.
- 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
Thanks for your confirmation! Best, Jonathan