136 posts
  • Sold between 50 000 and 100 000 dollars
  • Referred between 50 and 99 users
  • Bought between 10 and 49 items
  • Exclusive Author
  • Has been a member for 3-4 years
  • United Kingdom
ThemeShaper says

The problem is, unless the plugin is the same across lots of different themes (and theme authors) users will still have mostly useless shortcodes upon switching a theme. That isn’t to say all would be useless (things such as columns would still work) but at best you would have a theme with working shortcodes obviously styled for a different theme.

Unless the shortcodes are standardised in some way (either via a semi official WP plugin, or Envato one) I don’t think getting sellers to pluginify shortcodes would help a huge amount. Certainly it helps individual authors using ‘their plugin’ with sales (as previous buyers can switch easy, so it is an incentive to buy from the same brand), but as a community it needs a more ‘official’ plugin for the job. (and it needs to work well , work responsively and be updated etc)

The nature of shortcodes is really the issue here. They are the only way to get the advanced functionality that the buyers want (and now expect), but they are dirty as hell from a forward compatibility perspective. Something of a pandoras box scenario ;)

It is also worth considering how bothered really are buyers and users by this? – Playing devils advocate here (as I do appreciate the problem) – but wouldn’t buyers vote with their dollars? – are we keeping this in perspective?

6 posts
  • Exclusive Author
  • Has been a member for 3-4 years
  • United States
arconix says

The problem is, unless the plugin is the same across lots of different themes (and theme authors) users will still have mostly useless shortcodes upon switching a theme. That isn’t to say all would be useless (things such as columns would still work) but at best you would have a theme with working shortcodes obviously styled for a different theme.
I hardly think that’s worse than after switching themes, looking at pages and posts with [shortcode] content [/shortcode] sprinkled throughout. Even if the shortcodes do not have an integrated appearance, at least they’d still function.
304 posts
  • Austria
  • Envato Studio (Microlancer) Beta Tester
  • Exclusive Author
  • Has been a member for 3-4 years
  • Referred between 10 and 49 users
  • Sold between 10 000 and 50 000 dollars
squaredWeb says

I hardly think that’s worse than after switching themes, looking at pages and posts with [shortcode] content [/shortcode] sprinkled throughout. Even if the shortcodes do not have an integrated appearance, at least they’d still function.

The problem is that this is just not true.

Lets take the Average Joe WordPress user with no coding skills who just wants a working homepage.

If he has to add all shortcodes and content every time he changes themes again (i agree this shouldnt be the case in theory) he can do this on his own using the themes documentation and a saturday afternoon.

In the plugin usecase he would still have his content, which is great, but how does this help him when all his content is still there, but makes his awesome designed website look like a mess all of a sudden because the shortcodes dont match the themes style. In this case he cant even change this by himself, he has to pay a freelancer to edit all the plugins css styles. Or he might decide that its the themes fault and demands that the author of the new theme changes all the plugin css styles to match his theme. Its hardly reasonable that every themeforest author has to implement css styles for 700 different author plugins.

This is not to say that i dont agree that a plugin should be best practice – i certainly do -, but while this is extremely easy to implement for the average themeclub where everybody works together on a single code basis it provides a tough challenge for a place like themeforest where everybody has his own way of doing things.

Its not as cut and dry as “a plugin is best for users because they keep their content” because unstyled content is useless to users without the coding skills to make it match their new theme.

158 posts
  • Exclusive Author
  • Has been a member for 5-6 years
  • Referred between 50 and 99 users
  • Sold between 1 000 and 5 000 dollars
  • United States
greenshady says

Can we stop with the “it can’t be done” attitude? No, it can’t be done if folks aren’t willing to try. There’s a lot of very smart people in the WordPress community. I’d wager there’s quite a few smart people in the ThemeForest section of that community too.

I agree that shortcodes should be bundled/used with content, not presentation. But there are some cases where this is simply not possible: for example, column shortcodes. Theme A uses 12 columns grid, theme B uses 16 columns grid. Make shortcodes work in both? I don’t think so.

I have a plugin I’m building where this will work in both Theme A, Theme B, as well as fall back gracefully to the plugin defaults with any other theme. I’m not sure about the policy of linking here in the forums, but it’s on my GitHub page.

The current problem with the column shortcode is that theme authors are making column shortcodes (plural). The original tutorial that nearly everyone here uses for this was poorly written. That tutorial has 20+ shortcodes when it should’ve only been 1, not to mention the other problems it causes. I’m seeking to fix this issue with my plugin, but it’s going to take some rethinking on the part of some theme authors.

158 posts
  • Exclusive Author
  • Has been a member for 5-6 years
  • Referred between 50 and 99 users
  • Sold between 1 000 and 5 000 dollars
  • United States
greenshady says
You can’t rely on a simple regex text search to unveil the intentions of the theme code, can’t you? Thing is – code is much more complex than this. Therefore, this plugin can be considered as a joke, or a dumb tool.

If you have specific things you’d like to see changed about the plugin, join the Theme Review mailing list and voice your concerns.

No tool will ever be perfect when it comes to checking code for issues. The purpose of the Theme Check plugin is to catch as much stuff as it can and to issue notifications based on what it catches. It’s still up to the theme author and reviewer to manually look through the code, even see the “intention” of the code when there’s a possible issue. Theme Check is just a place to start. It’s not an end-all-be-all plugin for catching all issues.

The Theme Review team and many theme authors don’t think it’s a joke though. Since that script (wasn’t originally a plugin) was written and eventually turned into a plugin, it’s saved countless hours of reviewers’ time and helped many theme authors become better coders who adhere to WordPress standards. If you look at the quality of code of themes submitted to WordPress.org over the past two years, you’ll see a definite trend upwards. We owe much of that to the development of Theme Check.

3189 posts
  • Sold between 5 000 and 10 000 dollars
  • United States
  • Bought between 10 and 49 items
  • Has been a member for 4-5 years
  • Exclusive Author
organicbee says

I’m not sure about the policy of linking here in the forums, but it’s on my GitHub page.

its frowned upon in most situations as its considered self promotion

nice work as always though, would it be possible to filter the output, then authors could modify it to fit their needs but would still default on other themes, just a thought

https://github.com/justintadlock/columns
814 posts
  • Author had a Free File of the Month
  • Exclusive Author
  • Sold between 10 000 and 50 000 dollars
  • Bought between 1 and 9 items
  • Referred between 1 and 9 users
  • Serbia
  • Has been a member for 5-6 years
rvision_ says

I agree that shortcodes should be bundled/used with content, not presentation. But there are some cases where this is simply not possible: for example, column shortcodes. Theme A uses 12 columns grid, theme B uses 16 columns grid. Make shortcodes work in both? I don’t think so.
I have a plugin I’m building where this will work in both Theme A, Theme B, as well as fall back gracefully to the plugin defaults with any other theme. I’m not sure about the policy of linking here in the forums, but it’s on my GitHub page.

Issues I see with this:

- You’re locking down the layout in the content. I suppose grid=”12” says to the plugin what is the maximum of columns. Therefore, when user changes theme from 12-col layout to 16 (or whatever other number), he has to go through all the content and change all the shortcodes. If it’s calculated proportionally, I’m not sure that 8/12 has an equivalent in 10-col grid.

[ column grid="12" span="8"]Content.[/column]
[ column grid="10" span="8"]Content.[/column]

- Other way around – presentation is locked in the plugin. Who says this css fits all the themes/styles? What if I am using modified 960.gs with bigger margins? Why is css there in the first place?

158 posts
  • Exclusive Author
  • Has been a member for 5-6 years
  • Referred between 50 and 99 users
  • Sold between 1 000 and 5 000 dollars
  • United States
greenshady says

@rvision_

If you’d like to discuss the details of this work-in-progress plugin, feel free to submit changes on the GitHub page, start up another topic, or shoot me an email. I’d be more than happy to explain things or even take your ideas to make it better under consideration.

4 posts
  • Exclusive Author
  • Has been a member for 3-4 years
chipbennett says




Documentation in the Codex is great, but utilising tools like Theme-Check is good too, because as the plugin is updated, authors are automatically conforming to any new guidelines.
Theme-Check plugin is a joke.
Would you be able to explain why you think Theme-Check is a joke? Comments like that without qualification don’t add much to the discussion. We need to know the problem before we can find the solution.

You can’t rely on a simple regex text search to unveil the intentions of the theme code, can’t you? Thing is – code is much more complex than this. Therefore, this plugin can be considered as a joke, or a dumb tool.

You misunderstand the purpose and use of Theme Check. The results are returned with a criticality rating of “critical”, “required”, “recommended”, and “info”.

The results returned as “critical” or “required” are a NO-GO result. The Theme will be resolved as “not approved”. The results returned as “recommended” are informational for the Theme Developer, to consider for implementation. The results returned as “info” are for the Theme Reviewer, as items that may bear further, human scrutiny: in order to ascertain the developer’s intent, and thus determine appropriateness.

As for your specific example: Base64 encoding doesn’t belong in Theme PHP code, period. Base64 encoding is not necessary for implementing a Theme options export-import feature. Exporting/importing as plain text works just fine. (I’ll give the benefit of the doubt, and assume that you’re using best practices, by using the Settings API , and by having a single options array as a single WP_Options DB table entry? How difficult is it to export/import a single array?)

http://themeforest.net/forums/thread/timthumb-script-and-theme-check-plugin/48408?page=1#447753 http://themeforest.net/forums/thread/code-quality-on-themeforest-items/67178?page=7#594200 http://themeforest.net/forums/thread/cant-find-thumbsdb/73196?page=1#635811 http://themeforest.net/forums/thread/theme-check-infos-errors/67715?page=1#596061

TimThumb doesn’t belong in WordPress Themes, period. Use the WordPress core Post Thumbnails functionality. You’re doing your users a disservice by using TimThumb.

The last link demonstrates the point about how Theme Check is intended to be used. Those two “INFO” results would be flagged by the Theme Reviewer, to examine the code to see how IFRAME and hard-coded links are being used.

814 posts
  • Author had a Free File of the Month
  • Exclusive Author
  • Sold between 10 000 and 50 000 dollars
  • Bought between 1 and 9 items
  • Referred between 1 and 9 users
  • Serbia
  • Has been a member for 5-6 years
rvision_ says

As for your specific example: Base64 encoding doesn’t belong in Theme PHP code, period. Base64 encoding is not necessary for implementing a Theme options export-import feature. Exporting/importing as plain text works just fine. (I’ll give the benefit of the doubt, and assume that you’re using best practices, by using the Settings API , and by having a single options array as a single WP_Options DB table entry? How difficult is it to export/import a single array?)

In my case it belongs. I am doing a serialization of an custom options object and I need this. Exported data is a plain text.

Why is this a problem?

by
by
by
by
by
by