Well 18 pages later and I’m still trying to work out half of this stuff
One thing I have to mention, again, is that for something so important to the core of this site, it’s products, and thousands of peoples sole way of earning a living, you did another awesome job of placing this on a blog (notes) that no one reads, started a forum thread on the 4th of July (the biggest holiday in the US and many have taken a few days off and may miss this), and didn’t put a message on authors dashboard, nothing in the notices section of my dashboard and no banner at the top to inform us.
A real disappointment yet again Envato – you do seem to excel at this issue…..
how about custom post type? on some case cpt need to be integral part of the themes.
Correct me if I am wrong (didn’t read the whole thread) but I think the point of using “shortcode plugins” is to prevent the “lock in” effect you get if you use a theme and then want to switch and none of your shortcodes work any longer.
Therefore it should be sufficient to provide a small self written plugin for your customers so they can switch theme whenever they want and keep their shortcodes working. Thats what I plan to do.
I definitely wouldn’t use a public repository plugin for my shortcodes. (And to be honest: if envato wants to enforce these requirements to existing themes that wouldnt work anyways, since all these plugins use different shortcodes than the ones used in themeforest themes. Implementing them now would break all existing shortcodes which is probably not the best idea ;D )
In all honesty I think Envato did a rather mediocre job with this requirements (most of them are good but a lot of them lack examples or clarification).A handfull Elite Authors were pitched with these requirements months back. I at least provided extensive feedback and I think none of my suggestions or clarifications found their way into this draft. I am not surprised about this 18 page discussion
Agree with Kriesi about everything. I’m stuck at the moment because I don’t know how to proceed with my works, there isn’t a clear line to follow. And also about the suggestions of the authors across the forum: they are often ignored without any clarification. And, instead, are taken decision without a dutiful (I think) debate with the community.
Correct me if I am wrong (didn’t read the whole thread) but I think the point of using “shortcode plugins” is to prevent the “lock in” effect you get if you use a theme and then want to switch and none of your shortcodes work any longer. Therefore it should be sufficient to provide a small self written plugin for your customers so they can switch theme whenever they want and keep their shortcodes working. Thats what I plan to do.
I’m still confused… It’s about working shortcodes when the user change the theme with another theme of the same authors?... or different authors, different framework etc?...
Tons of questions that need answering here. Here is another one:
After the grace period is over how will you handle themes that aren’t fully meeting these requirements. Will you be treating the top selling items and the not-so top selling items equally? If an existing item that isn’t selling much doesn’t meet these requirements, you will most likely soft reject it but will you do the same for an item that has 300+ sales a week?
* All HTML needs to be validated via the W3C validator. – will this be MANDATORY to whole theme? Sometimes at demo, you need use a style switcher, that usually will create warnings at validator, can you be more specific about validation, please?
no i don’t think that W3C validation is must because we can not gaurantee the w3c validation to be required even google does not pass the w3c validation (Once in google’s tech video it was spotted that (if they have to choose..) they will choose performance rather than some (css/w3c) validation)
So just to be sure
1. It will be ok to use shortcodes if I put them into a plugin? And for shortcodes that are inadmissible I have to provide other plugins to do the job? So all in all in the end we will provide a theme with TGM that will install 20 other plugins right?
2. About the wpautop – I know we cannot screw with the wp core but can we still filter for example our shortcodes to avoid p and br tags injection all over the theme?
- Sold between 100 000 and 250 000 dollars
- Author had a Free File of the Month
- Most Wanted Bounty Winner
- Exclusive Author
- Bought between 10 and 49 items
- Referred between 10 and 49 users
- Has been a member for 2-3 years
- Microlancer Beta Tester
Looks like we have an important discussion here.
I like that finally the WP authors got a list of requirements, is easy work with a defined requirements (at least with some doubts but everybody can make a checklist and see what is needed to be approved – of course, the design/creativity is always the clue)
Just one thing I disagree (as many others here); my honest opinion is that add a limit to the shortcodes functionality affects creativity and flexibility coding a WP theme; every author has a way to create great items to be released here.
The shortcodes is an interesting feature in the WordPress themes. A lot of people is happy adding just few words between  instead of adding widgets in (only) the available sidebars. Following the new requirements, sidebars would define the limit for the shortcodes usage.
Just my two cents.
I do not write a contact form because i think that it will sell my theme i write it for the following reasons:
1. Seamless integration. Plugins looks like a Porche fixed with Beetle parts. it’s ugly nobody wants ugly.
3. a lot of plugin authors support is notoriously absent and if a client does not get support from the authors they will come to me and send me 100 mails for assistance, and get angry if i give them the run around. Writing my own functionality means that i will save on time. save on support and have happy customers.
4. A lot of the customers do not choose the plugins that they are getting, but the developers that they appointed chose that. 3 years from buying the theme the customers clicks update on a plugin and all sorts of hell is loose and the developers do not fix their stuff they send the customer to the theme author. Writing my own code fixes all of that.5. Thinking that the customer will not try different plugins in his lifetime is a crazy idea, and there’s absolutely zero convergence between plugins, so the “loose my functionality if i change themes” is stupid. They loose it anyhow when they try a new plugin
1. You’re clearly using the wrong plugins or are completely ignorant to some of the great options out there. Gravity Forms, Formiddable, Ninja Forms—All three are excellent options that look and work great. In order to support them you need nothing more than a few lines of CSS.
2. Saves you time by spending hours writing your own contact form functionality (assuming it’s not just a simple email form that can be done in 20 minutes)? Utilizing an existing solution that provides far more advanced functionality than you can write in an hour actually saves so much more time. The three plugins I mentioned above are lead by development teams that operate their entire business around their form plugins. Trying to claim that they don’t offer support or that they don’t fix bugs is nothing short of pure arrogance.
3. Then choose the well supported plugins, like the three I mentioned.
4. Using the TGM Activation class you can choose the recommended plugin(s) for your buyers. If the customers choose to use something else, that’s their decision.
You may wish to add the following to exemption list:
RECOMMENDED: No reference to add_theme_support( ‘custom-header’, $args ) was found in the theme. It is recommended that the theme implement this functionality if using an image for the header.
RECOMMENDED: No reference to add_theme_support( ‘custom-background’, $args ) was found in the theme. If the theme uses background images or solid colors for the background, then it is recommended that the theme implement this functionality.
RECOMMENDED: No reference to add_editor_style() was found in the theme. It is recommended that the theme implement editor styling, so as to make the editor content match the resulting post output in the theme, for a better user experience.
Custom headers and custom backgrounds are not always needed. Similarly, add_editor_style() isn’t always needed if the theme’s typography matches the editor.