[theme-reviewers] Redux framework may be dialing home

Dovy Paukstys dovy at reduxframework.com
Thu Oct 16 20:16:37 UTC 2014


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?

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

> Okay, okay. Let's all calm down a second here.
>
>
> On Thu, Oct 16, 2014 at 2:49 PM, Dovy Paukstys <dovy at reduxframework.com>
>  wrote:
>
>> Emil:
>> Then can I request that Yoast has the same process be given to them? I'm
>> all for fairness here and I would never do anything that I didn't see
>> another market player doing.
>>
>
>
> Dovy,
>
> Firstly, there's no case where a plugin can't have tracking on an opt-in
> basis. If the user has the choice, and it defaults to disabled, then it's
> fine.
>
> However, I'm having a very hard time seeing where a theme should be
> allowed to have *any* tracking of this nature, even if it is on a fully
> opt-in basis.
>
> A theme is supposed to be changing the look of the site. Not adding
> features. Not adding crazy weird ways to do new things with content. It's a
> *theme*.
>
> Now, from what is being said, this wasn't "opt-in", probably because of a
> bug. Ignoring that, if a "theme" shouldn't have tracking of user data, then
> I'm definitely not seeing why a "theme-framework", which to me is like
> half-a-theme, should have this in any way.
>
> Theme authors are responsible for the behavior of their themes, same as
> plugin authors. But, and this is the important point here, you're not the
> theme author in this case. You're putting tracking code into a piece of
> code for other people to integrate into their theme, and then tracking
> those users a further level down. I can't see that as acceptable on any
> level, opt-in or not.
>
> Honestly, I've been against "frameworks" of all stripes being allowed in
> the repository for quite a while. This seems to cement it even further, to
> me. How can a *framework* justify tracking user data like this? If we're
> going to have to police frameworks at this level, then my vote is going to
> come down to "no frameworks period".
>
> In other words, yes, this seems pretty damn bad to me. Anonymous or not,
> if users are having their data sent elsewhere and even the person who wrote
> their theme may not know about it, then that is a real big problem, as I
> see it.
>
> -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/3ffdc272/attachment.html>


More information about the theme-reviewers mailing list