Plugin conflicts with latest version of Jetpack

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Plugin conflicts with latest version of Jetpack

Ian Dunn
I just spent a couple hours tracking down a problem that was reported
with one of my plugins, and it turns out that the latest version of
Jetpack is causing problems with a lot of different plugins. I've seen
reports of at least half a dozen different ones, so I thought I'd pass
these links along in case it might save anyone else some time:

http://wordpress.org/support/topic/jetpack-204-breaks-nextgen-galleries
http://wordpress.org/support/topic/jetpack-204-upgrade-breaks-several-plugins
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Plugin conflicts with latest version of Jetpack

Mika Epstein
Just in case someone doesn't know, when you find plugin bugs, remember
to tell the plugin devs directly. In the case of Jetpack it's this:

http://en.support.wordpress.com/contact/?jetpack=needs-service

(I know Ian knows that, but just as a reminder in general ;) )

Ian Dunn wrote:

>
> I just spent a couple hours tracking down a problem that was reported
> with one of my plugins, and it turns out that the latest version of
> Jetpack is causing problems with a lot of different plugins. I've seen
> reports of at least half a dozen different ones, so I thought I'd pass
> these links along in case it might save anyone else some time:
>
> http://wordpress.org/support/topic/jetpack-204-breaks-nextgen-galleries
> http://wordpress.org/support/topic/jetpack-204-upgrade-breaks-several-plugins 
>
>
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Plugin conflicts with latest version of Jetpack

Otto-19
The bug is the same one that's plagued me for years with SFC and SGC.

Basically, NextGen is just totally terrible and is doing-it-wrong. Not
a bug in Jetpack.

-Otto


On Tue, Jan 1, 2013 at 5:02 PM, Mika A Epstein <[hidden email]> wrote:

> Just in case someone doesn't know, when you find plugin bugs, remember to
> tell the plugin devs directly. In the case of Jetpack it's this:
>
> http://en.support.wordpress.com/contact/?jetpack=needs-service
>
> (I know Ian knows that, but just as a reminder in general ;) )
>
>
> Ian Dunn wrote:
>>
>>
>> I just spent a couple hours tracking down a problem that was reported
>> with one of my plugins, and it turns out that the latest version of
>> Jetpack is causing problems with a lot of different plugins. I've seen
>> reports of at least half a dozen different ones, so I thought I'd pass
>> these links along in case it might save anyone else some time:
>>
>> http://wordpress.org/support/topic/jetpack-204-breaks-nextgen-galleries
>>
>> http://wordpress.org/support/topic/jetpack-204-upgrade-breaks-several-plugins
>>
>> _______________________________________________
>> wp-hackers mailing list
>> [hidden email]
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Plugin conflicts with latest version of Jetpack

Otto-19
In reply to this post by Ian Dunn
Ian, the bug is actually in your plugin, and how you're using shortcodes.

In http://plugins.svn.wordpress.org/basic-google-maps-placemarks/trunk/core.php
you have a function called mapShortcodeCalled() which says it is
supposed to "Checks the current posts to see if they contain the map
shortcode."

However, what it's actually doing is to set up the post data and then
call get_the_content(). This would be fine if you wanted to get the
resulting HTML output, because what you're actually doing with that
call is to have it process the shortcodes.

Instead, you should examine the post->post_content directly to
determine if the shortcode is contained in it. Although honestly, I'm
not sure why you'd go to all that trouble. You can enqueue things like
scripts and such in shortcode functions directly now, they'll get
included in the footer instead of the header, so you don't need to
pre-process the content to determine that sort of thing.

But basically, shortcodes and filters need to have a specific
behaviorism that you're not really adhering to very well, and that is
this: No side effects. A filter should filter some input in a certain
way, and do it every time, because it can be called more than once. A
shortcode is really just a special case of filter, it should take the
shortcode as input and return the resulting HTML to be put into the
post. By making filters or shortcodes have dependencies outside of
their inputs, then you introduce strange cases like this.

Jetpack is doing it right here. They want to get the_content, so they
run it through the the_content filter. This is not unusual or
unexpected. What is unexpected is the way your plugin behaves oddly
when some other piece of code is filtering something with the_content
filter. Your plugin is making assumptions about the ordering of
filters and when the_content runs that are not always true, basically.
Moreso since any theme can call the_content any number of times, and
in any place.

-Otto


On Tue, Jan 1, 2013 at 4:42 PM, Ian Dunn <[hidden email]> wrote:

> I just spent a couple hours tracking down a problem that was reported with
> one of my plugins, and it turns out that the latest version of Jetpack is
> causing problems with a lot of different plugins. I've seen reports of at
> least half a dozen different ones, so I thought I'd pass these links along
> in case it might save anyone else some time:
>
> http://wordpress.org/support/topic/jetpack-204-breaks-nextgen-galleries
> http://wordpress.org/support/topic/jetpack-204-upgrade-breaks-several-plugins
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Plugin conflicts with latest version of Jetpack

Ian Dunn
Er, my bad. I'll change it to check $post directly. Thanks for the
detailed explanation.

The reason I'm checking if the shortcode is called is to avoid loading
CSS and JavaScript files on pages where the shortcode isn't used
<http://wordpress.stackexchange.com/questions/20854/conditionally-loading-javascript-css-for-shortcodes>.
I didn't realize that we can use wp_enqueue_script() directly within the
shortcode callback
<http://scribu.net/wordpress/conditional-script-loading-revisited.html>
now, but I originally wrote that method about 6 months before 3.3 came
out. I could start doing that now for the JavaScript, but the CSS still
needs to be enqueued inside the head tag, so it wouldn't really save me
anything.


On 01/01/2013 03:59 PM, Otto wrote:

> Ian, the bug is actually in your plugin, and how you're using shortcodes.
>
> In http://plugins.svn.wordpress.org/basic-google-maps-placemarks/trunk/core.php
> you have a function called mapShortcodeCalled() which says it is
> supposed to "Checks the current posts to see if they contain the map
> shortcode."
>
> However, what it's actually doing is to set up the post data and then
> call get_the_content(). This would be fine if you wanted to get the
> resulting HTML output, because what you're actually doing with that
> call is to have it process the shortcodes.
>
> Instead, you should examine the post->post_content directly to
> determine if the shortcode is contained in it. Although honestly, I'm
> not sure why you'd go to all that trouble. You can enqueue things like
> scripts and such in shortcode functions directly now, they'll get
> included in the footer instead of the header, so you don't need to
> pre-process the content to determine that sort of thing.
>
> But basically, shortcodes and filters need to have a specific
> behaviorism that you're not really adhering to very well, and that is
> this: No side effects. A filter should filter some input in a certain
> way, and do it every time, because it can be called more than once. A
> shortcode is really just a special case of filter, it should take the
> shortcode as input and return the resulting HTML to be put into the
> post. By making filters or shortcodes have dependencies outside of
> their inputs, then you introduce strange cases like this.
>
> Jetpack is doing it right here. They want to get the_content, so they
> run it through the the_content filter. This is not unusual or
> unexpected. What is unexpected is the way your plugin behaves oddly
> when some other piece of code is filtering something with the_content
> filter. Your plugin is making assumptions about the ordering of
> filters and when the_content runs that are not always true, basically.
> Moreso since any theme can call the_content any number of times, and
> in any place.
>
> -Otto
>
>
> On Tue, Jan 1, 2013 at 4:42 PM, Ian Dunn <[hidden email]> wrote:
>> I just spent a couple hours tracking down a problem that was reported with
>> one of my plugins, and it turns out that the latest version of Jetpack is
>> causing problems with a lot of different plugins. I've seen reports of at
>> least half a dozen different ones, so I thought I'd pass these links along
>> in case it might save anyone else some time:
>>
>> http://wordpress.org/support/topic/jetpack-204-breaks-nextgen-galleries
>> http://wordpress.org/support/topic/jetpack-204-upgrade-breaks-several-plugins
>> _______________________________________________
>> wp-hackers mailing list
>> [hidden email]
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Plugin conflicts with latest version of Jetpack

Otto-19
On Tue, Jan 1, 2013 at 6:44 PM, Ian Dunn <[hidden email]> wrote:
> could start doing that now for the JavaScript, but the CSS still needs to be
> enqueued inside the head tag, so it wouldn't really save me anything.

For CSS, I'd just include it all the time. Shouldn't make any speed
difference, the browser loads it once, then it's browser-side cached.

-Otto
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Plugin conflicts with latest version of Jetpack

Mike Schinkel-6
On Jan 2, 2013, at 12:03 AM, Otto <[hidden email]> wrote:
> For CSS, I'd just include it all the time. Shouldn't make any speed
> difference, the browser loads it once, then it's browser-side cached.

If I'm not mistaken the browser still requests the file and the server returns a 304 telling the browser to use the cached version, at least that's what HTTPScoop[1] tells me. Having to check and getting a 304 response isn't the same as never having to issue an HTTP GET request and wait, especially if a site has many CSS and/or JS files to check from many different plugins.

On Jan 1, 2013, at 7:44 PM, Ian Dunn <[hidden email]> wrote:
> The reason I'm checking if the shortcode is called is to avoid loading CSS and JavaScript files on pages where the shortcode isn't used <http://wordpress.stackexchange.com/questions/20854/conditionally-loading-javascript-css-for-shortcodes>. I didn't realize that we can use wp_enqueue_script() directly within the shortcode callback <http://scribu.net/wordpress/conditional-script-loading-revisited.html> now, but I originally wrote that method about 6 months before 3.3 came out. I could start doing that now for the JavaScript, but the CSS still needs to be enqueued inside the head tag, so it wouldn't really save me anything.


I've been meaning to tackle this same problem for a while and have been planning to use a technique that I described as an answer to your WordPress Answers question. Your question gave me the motivation to tackle it today:

http://wordpress.stackexchange.com/a/77946/89

Basically the approach I implemented checks for shortcode use on the first page load and then saves the status to a post meta key which it uses to check from them on.  Hope this helps and I'd be interested to know your thoughts on this approach.

-Mike
[1] http://www.tuffcode.com
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Plugin conflicts with latest version of Jetpack

Otto-19
On Wed, Jan 2, 2013 at 1:06 AM, Mike Schinkel <[hidden email]> wrote:
> If I'm not mistaken the browser still requests the file and the server returns a 304 telling the browser to use the cached version, at least that's what HTTPScoop[1] tells me. Having to check and getting a 304 response isn't the same as never having to issue an HTTP GET request and wait, especially if a site has many CSS and/or JS files to check from many different plugins.

This happens because you either:

a) don't have a proper "Expires:" header being sent with the static content,
b) the expiration has, well... expired, or
c) you manually refreshed or hit F5 or something to that effect when
you were testing your theory. Browsers treat a refresh differently
than normal browsing.

Content that is browser-cached and has an expiration date will not be
re-retrieved, or even checked for last-modified, in a normal browsing
situation... until the content has expired. Refreshing is not a normal
browsing situation, it's an explicit request by the user to get new
data.

Check that you are correctly setting Expires headers for your static
content, and see what happens when you're browsing among pages
normally instead of reloading a page for testing purposes.

-Otto
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Plugin conflicts with latest version of Jetpack

Mike Schinkel-6
On Jan 2, 2013, at 6:04 AM, Otto <[hidden email]> wrote:

> This happens because you either:
>
> a) don't have a proper "Expires:" header being sent with the static content,
> b) the expiration has, well... expired, or
> c) you manually refreshed or hit F5 or something to that effect when
> you were testing your theory. Browsers treat a refresh differently
> than normal browsing.
>
> Content that is browser-cached and has an expiration date will not be
> re-retrieved, or even checked for last-modified, in a normal browsing
> situation... until the content has expired. Refreshing is not a normal
> browsing situation, it's an explicit request by the user to get new
> data.
>
> Check that you are correctly setting Expires headers for your static
> content, and see what happens when you're browsing among pages
> normally instead of reloading a page for testing purposes.

I've been studying HTTP since 2006, but I'll be honest I'm often confused by what I see in practice so I could well learn something here.

Let's take this CSS file as an example since I know the setup of that server and it's a newly installed WordPress 3.5:

http://hardcorewp.com/wp-content/themes/the-bootstrap/style.css

If I do an HTTP request using a free Mac tool called HTTP Client I get these headers:

Content-Length: 9216
Date: Wed, 02 Jan 2013 17:02:37 GMT
Server: Apache
Last-Modified: Sat, 22 Dec 2012 09:21:13 GMT
Accept-Ranges: bytes
Connection: close
Content-Type: text/css

That is on a bog-standard CPanel install without a caching plugin.  As you can see, no Expires header.  Given the setup which is pretty similar to a lot of shared hosting wouldn't you expect similar for most WordPress installs?  My understanding is the server needs to be configured explicitly to serve Expires headers for static content which is something that most WordPress users are unlikely to have done.  Or am I missing something or misunderstanding?

On the other hand would you not agree that an Expires header does not help with the first page load and we know from Google's campaign to focus site owners on site speed that a first page load is critical for serendipitous surfing and discovery via search engines?  If you have a page that loads 10+ plugin's CSS and JS files it's going to be slower on 1st load than if it only serves what it needs. Of course if all the CSS files are bundled into one or just a few CSS files then that changes the equation but that too is not something I understand most WordPress users to have configured.

Educate me.

-Mike


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Plugin conflicts with latest version of Jetpack

Bryan Petty
On Wed, Jan 2, 2013 at 10:45 AM, Mike Schinkel <[hidden email]> wrote:
> Given the setup which is pretty similar to a lot of shared hosting wouldn't you expect similar for most WordPress installs?  My understanding is the server needs to be configured explicitly to serve Expires headers for static content which is something that most WordPress users are unlikely to have done.  Or am I missing something or misunderstanding?

Bluehost uses servers configured to use ETags, and as such, this is
the behavior seen there (at no point are Expires headers even used):

On subsequent page load (no refresh): Static assets served from
browser cache, no server request made (just as Otto describes).
On soft refresh (F5, or clicking Reload): Server request made, but if
still cached, this will still result in 304.
On hard refresh (Ctrl-Reload): Full CSS file returned from server and
re-cached by browser.

At least, this is Chrome's behavior, other browsers may be different.
GoDaddy also uses ETags with the same behavior.

Regards,
Bryan Petty
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Plugin conflicts with latest version of Jetpack

Jeff Morris
In reply to this post by Mike Schinkel-6
Mike: no disrespect, but there's a whiff of BS about that G claim.
First-page load equates to every time you F5/refresh. Nobody can get
around that, so what is G on about?.
If you want to discuss the tarpit issue with WordPress plugins, lets
talk about the fact that so many of them load everything including the
kitchen sink into the server process despite most of it being
irrelevant/redundant.

This guy has his eye on the ball:

http://www.dev4press.com/2012/blog/benchmark/plugins-performance-testing-2012-january/

And if WordPress itself can send HTTP headers, it stands to reason that
so can any coder.
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Plugin conflicts with latest version of Jetpack

Mike Schinkel-6
On Jan 2, 2013, at 1:17 PM, Bryan Petty <[hidden email]> wrote:

> Bluehost uses servers configured to use ETags, and as such, this is
> the behavior seen there (at no point are Expires headers even used):
>
> On subsequent page load (no refresh): Static assets served from
> browser cache, no server request made (just as Otto describes).
> On soft refresh (F5, or clicking Reload): Server request made, but if
> still cached, this will still result in 304.
> On hard refresh (Ctrl-Reload): Full CSS file returned from server and
> re-cached by browser.
>
> At least, this is Chrome's behavior, other browsers may be different.
> GoDaddy also uses ETags with the same behavior.

Thanks for the follow up.  My understanding with ETags is you have to submit a request with the ETag to have the server decide if it needs to serve or not.  If not can you elaborate on how ETags keep static assets from being re-requested?  

On Jan 2, 2013, at 1:20 PM, Jeff Morris <[hidden email]> wrote:
> Mike: no disrespect, but there's a whiff of BS about that G claim.

http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html

> First-page load equates to every time you F5/refresh. Nobody can get around that, so what is G on about?.

Forgive me but I'm at a loss for what you are trying to say here.  Are you saying first page load performance is not important?

> If you want to discuss the tarpit issue with WordPress plugins, lets talk about the fact that so many of them load everything including the kitchen sink into the server process despite most of it being irrelevant/redundant.

Also here, what exactly do you mean by "load everything including the kitchen sink into the server process?"  Can you give some specifics? I'm again at a loss for your point.

> And if WordPress itself can send HTTP headers, it stands to reason that so can any coder.

Yes, sending headers from a .php file is easy.  How does the WordPress plugin developer do that for static files?  Are you advocating serving .js and .css files using .php, i.e. styles.js.php and styles.css.php? That is an option, but doesn't address first page load performance.

-Mike


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Plugin conflicts with latest version of Jetpack

Jeff Morris
In reply to this post by Bryan Petty
Bryan:

In my experience, Etags are globally pretty useless except for one
thing, which is to workaround incorrect 304s returned by caching proxies
acting above their pay grade.
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Plugin conflicts with latest version of Jetpack

Jeff Morris
In reply to this post by Mike Schinkel-6
Mike:

Real-net experience:

Just about any eCommerce site I click on from the top of a G SERPS takes
an age to load because it's so bloated, but that didn't stop them
getting up there.

Kitchen Sink Syndrome:

Take a look at the source of just about any popular WP plugin. See how
well it's segmented. Not.
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Plugin conflicts with latest version of Jetpack

Mike Schinkel-6
On Jan 2, 2013, at 1:44 PM, Jeff Morris <[hidden email]> wrote:
> Real-net experience:
>
> Just about any eCommerce site I click on from the top of a G SERPS takes an age to load because it's so bloated, but that didn't stop them getting up there.

Quoting from the Google link I provided:

Speeding up websites is important — not just to site owners, but to all Internet users. Faster sites create happy users and we've seen in our
internal studies that when a site responds slowly, visitors spend less time there.

So while eCommerce sites may be slow I assume you are not saying that's an ideal to strive for. And that brings us back to the question of best practices for loading externals in a plugin.

> Kitchen Sink Syndrome:
>
> Take a look at the source of just about any popular WP plugin. See how well it's segmented. Not.

With almost 23k plugins in the repo, it's hard to know which you refer to and which techniques you take issue with.  Specifics would be more helpful.

-Mike

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Plugin conflicts with latest version of Jetpack

Jeff Morris
Mike:

#1: Secede from the Church of G

#2: Ease the pain: search on 'WordPress top ten plugins' or similar
(what,  I need to suggest this?)

#3: Smell the coffee.
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Plugin conflicts with latest version of Jetpack

Otto-19
In reply to this post by Mike Schinkel-6
On Wed, Jan 2, 2013 at 11:45 AM, Mike Schinkel <[hidden email]> wrote:

> If I do an HTTP request using a free Mac tool called HTTP Client I get these headers:
>
> Content-Length: 9216
> Date: Wed, 02 Jan 2013 17:02:37 GMT
> Server: Apache
> Last-Modified: Sat, 22 Dec 2012 09:21:13 GMT
> Accept-Ranges: bytes
> Connection: close
> Content-Type: text/css
>
> That is on a bog-standard CPanel install without a caching plugin.  As you can see, no Expires header.  Given the setup which is pretty similar to a lot of shared hosting wouldn't you expect similar for most WordPress installs?

If you're telling me that you think most servers are not configured
appropriately for serving real-world content, then you'll get no
argument from me.

The "default" setup is never the optimal one. You need to be
configuring your webserver correctly first, before you ever try to
optimize your code or your content. If you're not serving
appropriately from the ground up, then you're not doing it correctly
from the starting line.

A server should be configured to send correct caching headers for
static content (which, note, is served *outside* of WordPress).
Cache-Control. Expires. Maybe Etags if you're having issues (but
generally ETags isn't worth the trouble). These are basics which all
sites should configure appropriately before serving a single byte. And
you can do this via .htaccess or nginx config files, no problems.

I agree that most sites do not have this configured appropriately. But
I don't agree that you should make your plugin slower and more complex
by assuming this to be the case. The principle of KISS applies here:
Keep the plugin simple and doing things appropriately.

Yes, it is not particularly optimal to output a CSS link on every page
(or even a JS link, for that matter). However, it is far simpler, and
the workarounds to make the system smarter about it are complex and
can cause incompatibilities if done incorrectly. And in a case where
the system has been properly optimized, the workarounds cause no
significant real-world gain.


> On the other hand would you not agree that an Expires header does not help with the first page load

Speed is important, but it is not the end-all be-all of the world of
the World Wide Web. Simplicity matters too. Ease of development. Ease
of use. Compatibility. If you have a non-optimal site, then optimizing
it is a good thing, certainly. If you're writing a plugin, then making
it more complex and more difficult to maintain and more incompatible
with other things, in order to shave a millisecond or two off
somebody's non-optimized site load time... probably not worth it.

-Otto
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Plugin conflicts with latest version of Jetpack

Mike Schinkel-6
Hi Otto,

Thanks for clarifying.  I've learned from this thread and with clarification I think we mostly agree in principle but disagree a bit in the best way to optimize. But then that's okay as we each get to choose what works before for ourselves, right? :)

-Mike

On Jan 2, 2013, at 6:36 PM, Otto <[hidden email]> wrote:

> On Wed, Jan 2, 2013 at 11:45 AM, Mike Schinkel <[hidden email]> wrote:
>> If I do an HTTP request using a free Mac tool called HTTP Client I get these headers:
>>
>> Content-Length: 9216
>> Date: Wed, 02 Jan 2013 17:02:37 GMT
>> Server: Apache
>> Last-Modified: Sat, 22 Dec 2012 09:21:13 GMT
>> Accept-Ranges: bytes
>> Connection: close
>> Content-Type: text/css
>>
>> That is on a bog-standard CPanel install without a caching plugin.  As you can see, no Expires header.  Given the setup which is pretty similar to a lot of shared hosting wouldn't you expect similar for most WordPress installs?
>
> If you're telling me that you think most servers are not configured
> appropriately for serving real-world content, then you'll get no
> argument from me.
>
> The "default" setup is never the optimal one. You need to be
> configuring your webserver correctly first, before you ever try to
> optimize your code or your content. If you're not serving
> appropriately from the ground up, then you're not doing it correctly
> from the starting line.
>
> A server should be configured to send correct caching headers for
> static content (which, note, is served *outside* of WordPress).
> Cache-Control. Expires. Maybe Etags if you're having issues (but
> generally ETags isn't worth the trouble). These are basics which all
> sites should configure appropriately before serving a single byte. And
> you can do this via .htaccess or nginx config files, no problems.
>
> I agree that most sites do not have this configured appropriately. But
> I don't agree that you should make your plugin slower and more complex
> by assuming this to be the case. The principle of KISS applies here:
> Keep the plugin simple and doing things appropriately.
>
> Yes, it is not particularly optimal to output a CSS link on every page
> (or even a JS link, for that matter). However, it is far simpler, and
> the workarounds to make the system smarter about it are complex and
> can cause incompatibilities if done incorrectly. And in a case where
> the system has been properly optimized, the workarounds cause no
> significant real-world gain.
>
>> On the other hand would you not agree that an Expires header does not help with the first page load
>
> Speed is important, but it is not the end-all be-all of the world of
> the World Wide Web. Simplicity matters too. Ease of development. Ease
> of use. Compatibility. If you have a non-optimal site, then optimizing
> it is a good thing, certainly. If you're writing a plugin, then making
> it more complex and more difficult to maintain and more incompatible
> with other things, in order to shave a millisecond or two off
> somebody's non-optimized site load time... probably not worth it.

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Plugin conflicts with latest version of Jetpack

Ben Lobaugh
I agree to disagree!

*snicker*


On 1/2/13 3:46 PM, Mike Schinkel wrote:

> Hi Otto,
>
> Thanks for clarifying.  I've learned from this thread and with clarification I think we mostly agree in principle but disagree a bit in the best way to optimize. But then that's okay as we each get to choose what works before for ourselves, right? :)
>
> -Mike
>
> On Jan 2, 2013, at 6:36 PM, Otto <[hidden email]> wrote:
>> On Wed, Jan 2, 2013 at 11:45 AM, Mike Schinkel <[hidden email]> wrote:
>>> If I do an HTTP request using a free Mac tool called HTTP Client I get these headers:
>>>
>>> Content-Length: 9216
>>> Date: Wed, 02 Jan 2013 17:02:37 GMT
>>> Server: Apache
>>> Last-Modified: Sat, 22 Dec 2012 09:21:13 GMT
>>> Accept-Ranges: bytes
>>> Connection: close
>>> Content-Type: text/css
>>>
>>> That is on a bog-standard CPanel install without a caching plugin.  As you can see, no Expires header.  Given the setup which is pretty similar to a lot of shared hosting wouldn't you expect similar for most WordPress installs?
>> If you're telling me that you think most servers are not configured
>> appropriately for serving real-world content, then you'll get no
>> argument from me.
>>
>> The "default" setup is never the optimal one. You need to be
>> configuring your webserver correctly first, before you ever try to
>> optimize your code or your content. If you're not serving
>> appropriately from the ground up, then you're not doing it correctly
>> from the starting line.
>>
>> A server should be configured to send correct caching headers for
>> static content (which, note, is served *outside* of WordPress).
>> Cache-Control. Expires. Maybe Etags if you're having issues (but
>> generally ETags isn't worth the trouble). These are basics which all
>> sites should configure appropriately before serving a single byte. And
>> you can do this via .htaccess or nginx config files, no problems.
>>
>> I agree that most sites do not have this configured appropriately. But
>> I don't agree that you should make your plugin slower and more complex
>> by assuming this to be the case. The principle of KISS applies here:
>> Keep the plugin simple and doing things appropriately.
>>
>> Yes, it is not particularly optimal to output a CSS link on every page
>> (or even a JS link, for that matter). However, it is far simpler, and
>> the workarounds to make the system smarter about it are complex and
>> can cause incompatibilities if done incorrectly. And in a case where
>> the system has been properly optimized, the workarounds cause no
>> significant real-world gain.
>>
>>> On the other hand would you not agree that an Expires header does not help with the first page load
>> Speed is important, but it is not the end-all be-all of the world of
>> the World Wide Web. Simplicity matters too. Ease of development. Ease
>> of use. Compatibility. If you have a non-optimal site, then optimizing
>> it is a good thing, certainly. If you're writing a plugin, then making
>> it more complex and more difficult to maintain and more incompatible
>> with other things, in order to shave a millisecond or two off
>> somebody's non-optimized site load time... probably not worth it.
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers