1466 posts
  • Has been a member for 2-3 years
  • Exclusive Author
  • Sold between 10 000 and 50 000 dollars
  • Bought between 10 and 49 items
  • Referred between 1 and 9 users
  • Croatia
OriginalEXE says

I know what it falls back on, but that makes the whole cpt into plugin useless. I really think custom post types should be kept inside the theme and not in a plugin. I think the concept is a waste of time if tgere is no way to display the taxonomy properly using a plugin.

The point is not a frontend display but a backend one.

136 posts
  • Author had a File in an Envato Bundle
  • Bought between 1 and 9 items
  • Referred between 1 and 9 users
  • Sold between 50 000 and 100 000 dollars
  • Exclusive Author
  • Estonia
  • Has been a member for 1-2 years
BonfireThemes says

I have a question about widgets and the_post_thumbnail():

1) WIDGETS

In a theme I’m currently creating, I have a full-screen slideout that will hold a custom page along with widgets. Since I want to give users the option of using this slideout, the widget area code is loaded from the plugin;if users want it, they’ll install it. Because the widget area is loaded from a plugin however, ThemeCheck says the widget area is missing from the theme.

As I don’t want to include widgets elsewhere, is this something that qualifies as a ‘rare exception made at a reviewer’s discretion’?

2) the_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_url0; ?>

.. then Theme Check will say the_post_thumbnail() is not used.

Again, is this something that qualifies as a ‘rare exception made at a reviewer’s discretion’? When submitting, would I just point these things out to the reviewer?

Thanks.

631 posts
  • United Kingdom
  • Sold between 10 000 and 50 000 dollars
  • Most Wanted Bounty Winner
  • Interviewed on the Envato Notes blog
  • Referred between 50 and 99 users
  • Bought between 100 and 499 items
  • Envato Studio (Microlancer) Beta Tester
  • Exclusive Author
  • Has been a member for 2-3 years
+1 more
UBLThemes says


Your themecheck plugin doesn’t supress the usage of cURL. Is that intended?
Yes, that is intended. Instead of using cURL, you should use WordPress’ wp_remote_request() function.

What about scripts that use curl, for instance we are using sharrre which uses curl, also a twitter plugin which is from wordpress.org uses curl.

Does this mean we are not allowed to use this in future?

631 posts
  • United Kingdom
  • Sold between 10 000 and 50 000 dollars
  • Most Wanted Bounty Winner
  • Interviewed on the Envato Notes blog
  • Referred between 50 and 99 users
  • Bought between 100 and 499 items
  • Envato Studio (Microlancer) Beta Tester
  • Exclusive Author
  • Has been a member for 2-3 years
+1 more
UBLThemes says

I can understand why themeforest are wanting to put shortcodes etc into plugins, but I have a problem with this.

If you are putting them into plugins, Im assuming you have to include the css, javascript for every shortcode you give.

I personally don’t want someone to be able to use my page builders/shortcode generators/shortcodes/styling on other themes, if I wanted that I would have submitted to wordpress.org and not themeforest.net

It also makes it very easy for distributing around the web, because plugins should be standalone and not rely on anyone theme…

This could become a problem, especially when it comes to page builders and shortcode generators.

When adding as a plugin, do we need to include css and javascript for shortcodes and page builders?

366 posts WordPress Guy
  • Envato Staff
  • Australia
  • Has been a member for 5-6 years
  • Contributed a Tutorial to a Tuts+ Site
  • Exclusive Author
  • Sold between 100 and 1 000 dollars
  • Bought between 50 and 99 items
  • Referred between 1 and 9 users
  • Repeatedly Helped protect Envato Marketplaces against copyright violations
Japh Staff says

Hey everyone, just letting you know I’m back and working through to see what I missed that hasn’t been answered yet. Post incoming shortly to hopefully answer those questions.

631 posts
  • United Kingdom
  • Sold between 10 000 and 50 000 dollars
  • Most Wanted Bounty Winner
  • Interviewed on the Envato Notes blog
  • Referred between 50 and 99 users
  • Bought between 100 and 499 items
  • Envato Studio (Microlancer) Beta Tester
  • Exclusive Author
  • Has been a member for 2-3 years
+1 more
UBLThemes says


I was talking about custom metaboxes which, according to your replies in this thread, should be moved into plugins in phase 2. My point is that plugins should implement common features (as in, a project custom post type) but theme specific custom metaboxes should still be defined in theme (as in, “layout: media|content, media/content”
I would say for theme specific metaboxes, relating to layout and content etc., this would be fine to be in the theme.

Does this go with shorcodes also?

366 posts WordPress Guy
  • Envato Staff
  • Australia
  • Has been a member for 5-6 years
  • Contributed a Tutorial to a Tuts+ Site
  • Exclusive Author
  • Sold between 100 and 1 000 dollars
  • Bought between 50 and 99 items
  • Referred between 1 and 9 users
  • Repeatedly Helped protect Envato Marketplaces against copyright violations
Japh Staff says

Apologies for the HUGE post! Ok, here goes…


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 ?

Is there a technical need to omit the closing head and body tags? Otherwise, I think you should include them for the sake of readability. Just because you can omit something, doesn’t necessarily mean you should, as with the curly brace requirement.


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.

We haven’t said that you need to strictly follow all those standards at this point, but it’d be nice if you could aim for them. As for namespaces etc. it’s probably not practical to start early-adopting PHP features that are going to cause you support problems with customers who’s hosting cannot handle them.


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?

Can you explain why this can’t be done using wp_enqueue_style or wp_enqueue_script?


4. JavaScript “the code shouldn’t raise any errors or notices”. Do you mean errors in browser? JSHint? JSLint?

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?

We are referring to the browser. We have removed the requirement that mentioned JSHint in favour of using strict mode.


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?

We are working on this already! :)


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.

Thank you, we’ve noted this feedback and will be raising it internally to get further clarification for you all.


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?

I’ll see if we can get some sort of list of examples here so that it’s clarified better for you.


The ones for portfolio should be activated when the plugin for portfolio CPT is activated I suppose…

Absolutely, they should be part of the portfolio plugin that would include custom post types, widgets, etc. for the portfolio features.


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?

I would recommend that your plugins focus on a theme or area of related functionality. So for Twitter, perhaps the plugin could actually be a social plugin, that handled Twitter, Social Icons, Social Icons Alternative, and Flickr, as an example.


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.

I’ll have to discuss this one with the review team and get back to you.


if custom post type must be in plugin so metabox, template page and single page also because to make compatibility when switch other theme.

The separation should be: is this visual (theme), or functional (plugin)? However, there will be exceptions to both cases of course, because nothing is black and white.


You have a mistake in the PHP section #5, which conflicts with the “child theme” rule. Your code:
<img src="<?php echo get_stylesheet_directory_uri(); ?>/images/filename.png" />

Instead of using get_stylesheet_directory_uri(), themes should almost always use get_template_directory_uri().

I know this is just an example, but if you want to facilitate the use of child themes, the themes here need to be referencing the correct directory.

Thanks, Justin. The example was assuming that this would want to be overridden in a child theme, but you’re right, and I’ll get this updated.


What i’m wondering is, why would we need to include metaboxes in plugins ? Once switched theme, those values can’t be used by new theme anyways, unless i’m missing something.

You don’t. Metaboxes can be in both themes and plugins, as above, the separation is visual VS functional.


Options Framework come with metabox support, so integrating the theme options, but placing metaboxes in a plugin is not an option

Yes, good point, see my previous answer above this one.


1) WIDGETS

In a theme I’m currently creating, I have a full-screen slideout that will hold a custom page along with widgets. Since I want to give users the option of using this slideout, the widget area code is loaded from the plugin;if users want it, they’ll install it. Because the widget area is loaded from a plugin however, ThemeCheck says the widget area is missing from the theme.

As I don’t want to include widgets elsewhere, is this something that qualifies as a ‘rare exception made at a reviewer’s discretion’?

Widgets are a core feature of WordPress that users will expect to be able to use. You should still provide an area that supports use of WordPress’ default widgets.


2) the_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_url0; ?>

.. then Theme Check will say the_post_thumbnail() is not used.

Again, is this something that qualifies as a ‘rare exception made at a reviewer’s discretion’? When submitting, would I just point these things out to the reviewer?

If this is a common enough need, I can see about adding it into ThemeForest-Check for you. Otherwise, I imagine it could be a ‘rare exception’ if you point it out to the reviewer, at their discretion.


What about scripts that use curl, for instance we are using sharrre which uses curl, also a twitter plugin which is from wordpress.org uses curl. Does this mean we are not allowed to use this in future?

These requirements are for themes, and cURL shouldn’t be used in a theme. Plugins are a separate matter.


If you are putting them into plugins, Im assuming you have to include the css, javascript for every shortcode you give.

...

When adding as a plugin, do we need to include css and javascript for shortcodes and page builders?

You should provide a base level of CSS and JavaScript in the plugin, but only that which would otherwise need to be repeated in each of your themes. The rest should be the theme theming the plugin, as it were.


Does this go with shorcodes also?

Shortcodes should be in a plugin.

17 posts
  • Author had a File in a Mini Bundle
  • Europe
  • Has been a member for 1-2 years
  • Exclusive Author
  • Sold between 10 000 and 50 000 dollars
  • Referred between 10 and 49 users
  • Bought between 10 and 49 items
prestahome says

Japh thanks for the reply!

I think the one huge post is better than few small :) It help easily finding all answers.

631 posts
  • United Kingdom
  • Sold between 10 000 and 50 000 dollars
  • Most Wanted Bounty Winner
  • Interviewed on the Envato Notes blog
  • Referred between 50 and 99 users
  • Bought between 100 and 499 items
  • Envato Studio (Microlancer) Beta Tester
  • Exclusive Author
  • Has been a member for 2-3 years
+1 more
UBLThemes says


If you are putting them into plugins, Im assuming you have to include the css, javascript for every shortcode you give.

...

When adding as a plugin, do we need to include css and javascript for shortcodes and page builders?
You should provide a base level of CSS and JavaScript in the plugin, but only that which would otherwise need to be repeated in each of your themes. The rest should be the theme theming the plugin, as it were.

Some of my shortcodes are bootstrap driven, does this mean I have to supply the bootstrap css and javascript within a plugin, is this not a theme thing?

366 posts WordPress Guy
  • Envato Staff
  • Australia
  • Has been a member for 5-6 years
  • Contributed a Tutorial to a Tuts+ Site
  • Exclusive Author
  • Sold between 100 and 1 000 dollars
  • Bought between 50 and 99 items
  • Referred between 1 and 9 users
  • Repeatedly Helped protect Envato Marketplaces against copyright violations
Japh Staff says

Some of my shortcodes are bootstrap driven, does this mean I have to supply the bootstrap css and javascript within a plugin, is this not a theme thing?

This might have to be a case-by-case scenario left to the reviewer’s discretion.

Personally, I would try to keep generic styling and scripting in the plugin, to then customise with further styling across my themes.

by
by
by
by
by
by