Well i had some bad experiences trying to embed .htaccess files. Some buyers/hosting company have weird server configurations and , as a result, .htaccess may cause the “500 internal server error”.
i know you’re using only in that folder but since Murphy is right, some of them will eventually test the url (for unknown reasons), get the error and blame your theme for destroying their server.
I’d just rename the zip and place an index.html in the folder to avoid listing, less secure but more reliable (for you)
Just a few technical consideration: if the toolkit is embedded in a theme, it cannot work on network installs. Also, it happened a few times that a request timeout due to slow response times of the envato api server wasn’t handled properly by the Envato_Protected_API class and the results was a fatal error.
Buyer experiencing the above would notice the error coming from a file included in the theme folder and assume it’s a theme bug (while it’s not).
By using an external plugin, both the issue would be solved (buyers would eventually blame the plugin itself).
There would be no reason to force authors to bundle it in their themes as it would be enough just to mention in docs “hey, if you want auto updates, feel free to use this thing but i have nothing to do with it.”
And yes, I agree that we need way better communication when we make changes to the review process.
Frankly speaking, If the team is too busy to communicate with us, then put the new rules on hold until you’ve got the time to properly announce them to authors.
Doing the opposite it’s just unprofessional and disrespectful towards our work.
digitalimpact saidnope it’s not, but i’m way too lazy to add admin options for that.
But is editing
wp-config.phpthe only way for a customer to get it working?
after all, it’s something they will set once and never need to change again, even when switching theme.
btw, the class uses some filters you could hook to provide custom username/api values by fetching them in your theme options page.
Would you mind sharing some technical details about the exploit ? being a sysadmin myself, i’m very interested in the matter.
Here’s the plugin
Unlike the theme bundled class, the plugin also works in network installs.
Here’s how it looks when there are theme updates available
i used a couple of other authors themes i had purchased myself a while ago, hope they don’t mind being visible in the shots. If so, let me know and i’ll remove them.
actually, 2012 functions.php has only 450 lines
Exactly, why is that required ? why authors have not been informed about it ?
We already have update capabilities in our themes using just the class-envato-protected-api.php, why we should be forced to use the toolkit ?
To just hook in the WordPress update system is way simpler and more reliable than using the toolkit and its custom Theme_Upgrader class. It just requires few lines and we even released a class that other authors are using in their own themes.
Envato should just release (or sponsor) a plugin using the very same hook method. There’s no need for a custom Theme_Upgrader class. The plugin will be able to update all themeforest themes installed by the buyer at the same time, regardless the author.
The api allows that, we already tested and it works.
All themes require integration with the Envato WordPress Toolkit Library.
this is starting to get ridiculous now ….
there are all these new rules in place and nobody knows about them but reviewers. There’s nothing more frustrating for an author than waiting days in queue and then being rejected for reasons not mentioned anywhere.