[theme-reviewers] Redux framework may be dialing home

[Dovy Paukstys]

Otto:
I will add documentation on how to remove the tracking and supply a
modified version in our builder then.

If we forked TGM and created a version that complies with your above
requirements would that be acceptable?

On Thu, Oct 16, 2014 at 2:29 PM, Otto <otto at ottodestruct.com> wrote:

> On Thu, Oct 16, 2014 at 3:16 PM, Dovy Paukstys <dovy at reduxframework.com>
> wrote:
>
>> Since I seem to have broken it, I've uploaded a "static" version of the
>> stats we typically display on Redux.
>> http://reduxframework.com/staticstats/  That's what we do with the data
>> we gather. As I said before developers can append their "hash" to get a
>> drill-down view of this data.
>>
>> Otto:
>> Thank you for chiming in.
>>
>> While I may agree partially with your statement about themes I fear
>> developers do more than WordPress originally designed it to do. That goes
>> beyond a design or a blog, and so you find more powerful themes.
>>
>> Our theme framework is in no-way a theme framework. It is only an option
>> framework. We provide a powerful interface to the settings API and that's
>> it. We don't provide templates or anything of the like.
>>
>> Truly Redux is to be run as a plugin, but I do believe TGM is not
>> permitted in WordPress.org themes, am I correct? If that was changed, then
>> there is a very easy solution! But I fear we won't get to that today.
>>
>> We justify because we do not hide. We're completely wide open and the
>> users have full choice and untraceable to the specific user. That's all it
>> boils down to. That and we are a plugin that developers choose to use in
>> their theme.
>>
>> Theme Developers know about the tracking. We have docs on it. We answer
>> any support issues, and we let people view the data. There is no hidden
>> agenda here.
>>
>> So what do you suggest?
>>
>
>
> Dovy,
>
> What I'm suggesting here is that, as it stands, I can't see us allowing
> themes to use your framework because of this tracking thing.
>
> For example, TGM is mostly disallowed, as you say. And don't get me wrong,
> TGM is a nice bit of code. Very powerful, easy to use. But it does things
> that we don't agree with. Specifically, it has the capability of
> auto-installing code without user intervention. It can install plugins from
> outside our repository. If a theme does any of these things with it, then
> that's cause for rejection. Themes can't have plugins be required, use the
> external_url or the force_activation features, etc.
>
> These are all off by default, and so that's fine, but even so it's one
> more thing that is required to be policed. And if the reviewers are fine
> with doing that extra policing, fine. Given my choice, TGM would still be
> disallowed because it contains this capability at all.
>
> Now, if a theme did tracking of this nature, by itself, then it would be
> rejected by the current standards, opt-in or not. So, since we're
> evaluating only the theme, and the theme includes the framework, then
> including this sort of tracking in themes is grounds for rejection. Which
> basically means that no theme in our directory can use your framework
> without removing that code. So, you can make your code do whatever you
> like, but we're going to have to disallow it if it does certain things or
> contains certain code.
>
> So, up to you in that case, but I would very much suggest making a version
> of the framework without the tracking at all, for use by developers who
> want their themes to be listed on WordPress.org.
>
> -Otto
>
>
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20141016/ada8acbf/attachment.html>