No subject
Sun Feb 20 18:20:38 UTC 2011
using my plugin, a small percentage are using this theme, and a small
percentage of those have written a custom function that filters out my
attribution comments. The bottom line is: a fraction of a percent of
plugin users are removing my attribution comments. I'm not worried about
it. If something so trivial was upsetting to me, I wouldn't be coding
GPL plugins in the first place.
*Do you put a link in your theme to an external site?
> *
Yes. By default, my theme includes a "Powered by..." link in the footer,
which links to my theme's website. However, the theme options allow the
site administrator to remove the link, edit it, or add the
rel="nofollow" attribute to it. I believe this strikes a reasonable
balance between my "business" goals and my users' freedom.
On Fri, Jul 1, 2011 at 11:43 PM, Angelo Bertolli
<angelo.bertolli at gmail.com>wrote:
>
>
> On Sat, Jul 2, 2011 at 12:21 AM, Darren Slatten <darrenslatten at gmail.com>wrote:
>
>> Real examples of things I've personally used this functionality to
>> accomplish on my own sites:
>>
>> - Remove redundant references to jQuery (for example, 2 plugins queue
>> the latest versions of jQuery that were available at the time of writing,
>> however both plugins will function with one or the other--removing the
>> redundant jQuery reference allows pages to load faster).
>> - Remove plugin author attribution HTML comments (in compliance with
>> GPL, of course).
>> - Remove duplicate rel="canonical" tag (caused by plugins
>> incorporating this feature before WP core...and then WP catching up, adding
>> a second occurrence).
>> - Remove WP core scripts (e.g. reply.js and l10n.js) because I've
>> already appended them to the end of a global custom .js file.
>> - Remove favicon references.
>> - Change order of CSS and JS to optimize page load speed and prevent
>> FOUC.
>>
>> How do you ensure that this doesn't mess up plugin functionality when
> you're wrong about the necessity of the code a plugin is using? Also, I'm
> curious if you really save anything by buffering and processing it this way
> (given the sophistication of the filter).
>
>
>
>> Please note that my real examples rebut the following arguments:
>>
>> - *Notify the plugin author or submit patches*--not a solution in
>> cases where plugin author has intentionally inserted a 4-line HTML comment
>> into my <head> section, essentially advertising his/her website. More
>> generally, not a solution for cases where "the right way" is subjective.
>>
>> It's true they won't likely just change that, but how is it that the
> plugin authors are unable to code around your filter then? So does this
> just end up being a code war between the theme developers and the plugin
> developers both trying to code around each other to get links in? Do you
> put a link in your theme to an external site?
>
>
>>
>> - *If Theme and Plugins all enqueue jQuery properly, then there will
>> *never* be duplicate jQuery scripts enqueued.*--not true in cases
>> where specific/multiple jQuery versions are referenced. Also,
>> wp_enqueue_script is @since 2.8, so backwards compatibility can't be
>> ignored.
>>
>> I agree with the point you're basically making with these two bullets that
> expecting plugins to be cleaned up is unrealistic, and there are legacy
> issues. But the question is really if the solution is to code around that
> in the theme. I understand your point of view, but at the bigger picture
> what needs to happen is if this stuff is coded around at all, it needs to be
> coded around via WP itself. More likely the plugin developers just need a
> stricter set of standards.
>
> I think you can make a case for allowing this kind of thing temporarily
> when there isn't a solution for you or your theme users, but ultimately it
> shouldn't stay that way.
>
> My 2c
>
>
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>
--20cf307d01bede443204a71d81d1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<blockquote style=3D"margin: 0pt 0pt 0pt 6.8ex; border-left: 1px solid rgb(=
204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><i style=3D"color=
: rgb(153, 153, 153);">How do you ensure that this doesn't mess up plug=
in functionality when <br>
you're wrong about the necessity of the code a plugin is using? </i><br=
></blockquote><br>Keep in mind that the theme doesn't actually change a=
nything by default; <br>it merely enables the user to make changes. Therefo=
re, this question <br>
would have to be answered on a case-by-case basis by users who have <br>opt=
ed to take advantage of the functionality provided by the theme. <br><br><b=
r><br><blockquote style=3D"margin: 0pt 0pt 0pt 6.8ex; border-left: 1px soli=
d rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">
<i style=3D"color: rgb(153, 153, 153);">Also, I'm curious if you really=
save anything by buffering and <br>processing it this way (given the sophi=
stication of the filter). </i><br></blockquote><br>If you're referring =
to page load times, the "savings" are on the client <br>
side. Naturally, there would be an additional cost on the server side, <br>=
but it would be 1 or 2 magnitudes less than the client-side savings. <br><b=
r><br><br><blockquote style=3D"margin: 0pt 0pt 0pt 6.8ex; border-left: 1px =
solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">
<i style=3D"color: rgb(153, 153, 153);">It's true they won't likely=
just change that, but how is it that the <br>plugin authors are unable to =
code around your filter then? So does this <br>just end up being a code war=
between the theme developers and the plugin <br>
developers both trying to code around each other to get links in? </i><br><=
/blockquote><br>Again, the theme doesn't make any changes by default. R=
emoving plugin <br>author attribution comments would be something the site =
administrator <br>
would have to code themselves. <br><br>From the plugin author's perspec=
tive, this means: out of all the people <br>using my plugin, a small percen=
tage are using this theme, and a small <br>percentage of those have written=
a custom function that filters out my <br>
attribution comments. The bottom line is: a fraction of a percent of <br>pl=
ugin users are removing my attribution comments. I'm not worried about =
<br>it. If something so trivial was upsetting to me, I wouldn't be codi=
ng <br>
GPL plugins in the first place. <br><br><br><br><blockquote style=3D"margin=
: 0pt 0pt 0pt 6.8ex; border-left: 1px solid rgb(204, 204, 204); padding-lef=
t: 1ex; color: rgb(153, 153, 153);" class=3D"gmail_quote"><i>Do you put a l=
ink in your theme to an external site? <br>
</i></blockquote><br>Yes. By default, my theme includes a "Powered by.=
.." link in the footer, <br>which links to my theme's website. How=
ever, the theme options allow the <br>site administrator to remove the link=
, edit it, or add the <br>
rel=3D"nofollow" attribute to it. I believe this strikes a reason=
able <br>balance between my "business" goals and my users' fr=
eedom.<br><br><br><br><div class=3D"gmail_quote">On Fri, Jul 1, 2011 at 11:=
43 PM, Angelo Bertolli <span dir=3D"ltr"><<a href=3D"mailto:angelo.berto=
lli at gmail.com">angelo.bertolli at gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><br><br>
<div class=3D"gmail_quote"><div class=3D"im">On Sat, Jul 2, 2011 at 12:21 A=
M, Darren Slatten <span dir=3D"ltr"><<a href=3D"mailto:darrenslatten at gma=
il.com" target=3D"_blank">darrenslatten at gmail.com</a>></span> wrote:<br>
<blockquote style=3D"border-left:#ccc 1px solid;margin:0px 0px 0px 0.8ex;pa=
dding-left:1ex" class=3D"gmail_quote">Real examples of things I've pers=
onally used this functionality to accomplish on my own sites:<br>
<ul>
<li>Remove redundant references to jQuery (for example, 2 plugins queue the=
latest versions of jQuery that were available at the time of writing, howe=
ver both plugins will function with one or the other--removing the redundan=
t jQuery reference allows pages to load faster).</li>
<li>Remove plugin author attribution HTML comments (in compliance with GPL,=
of course).</li>
<li>Remove duplicate rel=3D"canonical" tag (caused by plugins inc=
orporating this feature before WP core...and then WP catching up, adding a =
second occurrence).</li>
<li>Remove WP core scripts (e.g. reply.js and l10n.js) because I've alr=
eady appended them to the end of a global custom .js file.</li>
<li>Remove favicon references.</li>
<li>Change order of CSS and JS to optimize page load speed and prevent FOUC=
.<br></li></ul></blockquote>
</div><div>How do you ensure that this doesn't mess up plugin functiona=
lity when you're wrong about the necessity of the code a plugin is usin=
g?=A0 Also, I'm curious if you really save anything by buffering and pr=
ocessing it this way (given the sophistication of the filter).</div>
<div class=3D"im">
<div>=A0</div>
<div>=A0</div>
<blockquote style=3D"border-left:#ccc 1px solid;margin:0px 0px 0px 0.8ex;pa=
dding-left:1ex" class=3D"gmail_quote">Please note that my real examples reb=
ut the following arguments:<br>
<ul>
<li><i><b>Notify the plugin author or submit patches</b></i>--not a solutio=
n in cases where plugin author has intentionally inserted a 4-line HTML com=
ment into my <head> section, essentially advertising his/her website.=
More generally, not a solution for cases where "the right way" i=
s subjective.</li>
</ul></blockquote>
</div><div>It's true they won't likely just=A0change that, but=A0ho=
w is it that the plugin authors are unable to code around your filter then?=
=A0 So does this just end up being a code war between the theme developers =
and the plugin developers both trying to code around each other to get link=
s in?=A0 Do you put a link in your theme to an external site?</div>
<div class=3D"im">
<div>=A0</div>
<blockquote style=3D"border-left:#ccc 1px solid;margin:0px 0px 0px 0.8ex;pa=
dding-left:1ex" class=3D"gmail_quote">
<ul>
<li><i><b>If Theme and Plugins all enqueue jQuery properly, then there will=
*never* be duplicate jQuery scripts enqueued.</b></i>--not true in cases w=
here specific/multiple jQuery versions are referenced. Also, wp_enqueue_scr=
ipt is @since 2.8, so backwards compatibility can't be ignored.<br>
</li></ul></blockquote>
</div><div>I agree with the point you're basically making with these tw=
o bullets that expecting plugins to be cleaned up is unrealistic, and there=
are legacy issues.=A0 But the question is really if the solution is to cod=
e around that in the theme.=A0 I understand your point of view, but at the =
bigger picture what needs to happen is if this stuff is coded around at all=
, it needs to be coded around via WP itself.=A0 More likely the plugin deve=
lopers just need a stricter set of standards.</div>
<div>=A0</div>
<div>I think you can make a case for allowing this kind of thing temporaril=
y when there isn't a solution for you or your theme users, but ultimate=
ly it shouldn't stay that way.</div>
<div>=A0</div>
<div>My 2c</div>
<div>=A0</div></div><br>
<br>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href=3D"mailto:theme-reviewers at lists.wordpress.org">theme-reviewers at list=
s.wordpress.org</a><br>
<a href=3D"http://lists.wordpress.org/mailman/listinfo/theme-reviewers" tar=
get=3D"_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers<=
/a><br>
<br></blockquote></div><br>
--20cf307d01bede443204a71d81d1--
More information about the theme-reviewers
mailing list