billyf saidThe api change is massive, happened after theme release and would require complete rewrite of the code (no to mention the buyer api key). Most buyers would understand that the change is not under our control and the fact they bought a theme and not a twitter plugin.
But for those who have already purchased the themes, wouldn’t they complain if the feature is suddenly removed? After all, when they purchased it, ‘probably’ they bought it because there’s such feature (I know it’s very unlikely, but who says your buyer can’t use that reason?)
that plugin uses API 1.0 and will soon stop working.
New api is madness … oauth required even to just fetch tweets and api calls per hours are limited so data must be stored server side (a pure js solution is no longer an option)
Not to mention buyers will be obliged to create their own api keys before being able to use the widget and guess who they are going to ask help with …..
Not worth the effort, at least for us, so we just removed the twitter widget from our standard list of features.
twitter did the same thing, you can no longer fetch latest tweets without oauth/apikey and also required to store the content (because the per hour fetch limit restrictions) so a js only solution is out of question.
item support is already hard enough so we decided to just remove all social related custom widgets from our themes and buyers will have to rely on 3rd party plugins for this kind of features.
Android SDK emulator is nowhere comparable to the real device so it’s not really an option. We do test on android 4.x phone and tablet and ensure everything works as expected (layout/functions)
However, most of the times there’s not much you can do to optimize a plugin/template/theme for this platform when it comes to transition/scroll smoothness and touch events handling.
Truth is (omg i hate myself for saying this), apple mobile safari is still way ahead its competitor stock browser so you just end up optimizing for ios and to accept compromises on android.
when item is in home page, you can expect 1-2k unique visitor per day
I’d just check if plugin zip present, then print a notify in dashboard: “please remove $plugin.zip after the installation”
The user could secure them quite well depending on their server, but they won’t bother, we need to do that for them – if possible. Last idea we thought about was php rename and doing some mumbo jumbo with file names, how about that?
imho, there’s no real need for it. I mean, an evil user would have to know the exact zip name inside that folder to be able to download the plugin.