So, the solution we always used (and some other authors too) now seems to be no longer accepted by reviewers.
Result is, our latest theme got rejected due the above. Which is, frankly, quite shocking to me because that code only applies to our custom blocklevel shortcodes, doesn’t interfere in any way with the way wp works and just ignores any other native / 3rd party plugin defined shortcode.
So, should we assume that from now on, anything applied to “the_content” filter will just be rejected regardless its purpose ?
Actually raised the very same question in the mega thread about TF / WordCamp but didn’t get an official answer there. Imho, there’s no way for envato to enforce exclusivity for 100% GPL items.
revaxarts saidIt makes sense for mailing lists / newsletters but messages from buyers sent via our profile forms are none of them. Problem for us is that zendesk detects that header and suspends the tickets because it believes it’s a newsletter welcome mail.
List-Unsubscribeheader is optional and just a good idea to standardize the unsubscribe progress: http://www.list-unsubscribe.com
I just noticed we’re having issues with zendesk too: since envato switched to mandrill, all mails coming from our profile form and routed to zendesk are being marked as “Automated response email” and suspended.
i believe the issue relates to “List-Unsubscribe” header.
messages are being tagged as “Automated response email ” and auto suspended by zendesk. I believe this is due to the recent switch of envato over mandrill because wasn’t happening before.
I whitelisted some domains (envato.com, gmail.com so far), that prevents auto suspension and explains why some of you got auto reply while other didn’t.
I suspect this being related to “List-Unsubscribe” header added by mandrill:
i’m testing some changes in our ticketing system, could somebody please send us a message via our profile contact form ? content is not important (swearing allowed)
I don’t see why not, twentytwelve / twentythirteen define a couple of custom filters
revaxarts saidI can understand the choice for plugins because currently there’s no other way to give buyers auto updates.
Also the lack of support of WP plugins demands for a custom solution. I can also limit the amount of domains the plugin is used (regular license) which isn’t possible with the “native” method.
It would be much simpler if envato would just do for plugins what they did for themes. This would allow buyers to just configure their api key once per installation and being able to update all items purchased from TF/CC at once in the same way as they do for theme/plugins installed from wp.org
About the domain check, that’s really another subject.
revaxarts saidyou have to explain them how to obtain the purchase code as well and the value is different for each purchase. On the other hand, the api key only has to be generated once and then it works for any theme.
This method requires the username and the users API key (which has to be generated – which has to be explained). David’s method only requires only the purchase code.
I also assume the purchase verify is done on the update server or else it would be possible to bypass the check and obtain a download link without a purchase code. Even by caching the result, there’s still the possibility to hit the api limit.