2.next - faster

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

2.next - faster

Scott johnson-5
Faster, imho, involves tradeoffs at this point. My gut just on web apps is
that faster means "look hard at the SQL".  For example I learned TONS about
mysql scaling at Feedster that I think is applicable but it starts to get
specialized like memcache support, write versus read servers, etc.,
seriously playing with your table structure, etc.

Faster in what environment???  I'm happy to contribute ideas but given the
spectrum of sites WP runs on this question has major ramifications

Scott

On 2/6/06, Roy Schestowitz <[hidden email]> wrote:

>
> _____/ On Mon 06 Feb 2006 20:09:59 GMT, [Matt Mullenweg] wrote : \_____
>
> > The last thread about the next version of WP had some interesting
> > ideas in it, but I think the question may have been framed the wrong
> > way. What I'm far more interested in working on for the next version
> > is this:
> >
> > How can we make WordPress simpler in the next release?
> >
> > How can we reduce support requests on the forums?
>
>
> In my opinion, bugs should take precedence, then compatibility (browser,
> platform, and host testing) amd then comes the issue of extensibility
> (simplicity -> user independence).
>
>
> > How can we make it faster?
>
>
> Faster to /use/? Or is it a matter of load handling? Or responsiveness?
> It's
> a rope that you can always pull in different directions.
>
>
> > (To riff on an idea, consider starting a new thread.)
>
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>



--
-------------------------------------------------------
J. Scott Johnson
Ookles launches 2/28/06 - have you signed up yet?
new startup: http://ookles.com/
blog: http://fuzzyblog.com/
podcast: http://techwarstories.com/
[hidden email]
aim: fuzzygroup
cell: 857 222 6459
-------------------------------------------------------
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.next - faster

David House
On 06/02/06, Scott johnson <[hidden email]> wrote:
> Faster, imho, involves tradeoffs at this point. My gut just on web apps is
> that faster means "look hard at the SQL".  For example I learned TONS about
> mysql scaling at Feedster that I think is applicable but it starts to get
> specialized like memcache support, write versus read servers, etc.,
> seriously playing with your table structure, etc.

Most of the time taken for WordPress to load is down to the long time
needed for PHP to parse the thousands of lines of code, IIRC.

--
-David House, [hidden email], http://xmouse.ithium.net
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.next - faster

Roy Schestowitz-2
In reply to this post by Scott johnson-5
_____/ On Mon 06 Feb 2006 20:40:44 GMT, [Scott johnson] wrote : \_____

> On 2/6/06, Roy Schestowitz <[hidden email]> wrote:
>>
>> _____/ On Mon 06 Feb 2006 20:09:59 GMT, [Matt Mullenweg] wrote : \_____
>>
>> > The last thread about the next version of WP had some interesting
>> > ideas in it, but I think the question may have been framed the wrong
>> > way. What I'm far more interested in working on for the next version
>> > is this:
>> >
>> > <snip />
>> >
>> > How can we make it faster?
>>
>>
>> Faster to /use/? Or is it a matter of load handling? Or responsiveness?
>> It's a rope that you can always pull in different directions.
>>
>> <snip />
>
> Faster, imho, involves tradeoffs at this point.


Yes, but the definition of "fast" is of importance here. I edit my PHP-Nuke
sites using WordPress because it is fast and responsive (well, it used to
be more of that). In terms of page delivery, all is merely the same, but
for content creation, WordPress is excellent. A previous message of mine
raised the possibility of adding keybindings, but judging by the silence,
many tend to disagree or disregard that.


> My gut just on web apps is
> that faster means "look hard at the SQL". For example I learned TONS about
> mysql scaling at Feedster that I think is applicable but it starts to get
> specialized like memcache support, write versus read servers, etc.,
> seriously playing with your table structure, etc.


The last point conflicts with backward compatibility, unless you consider
some opaque conversions.


> Faster in what environment???  I'm happy to contribute ideas but given the
> spectrum of sites WP runs on this question has major ramifications


One has to accept the fact that WordPress cannot remain feather-light,
assuming it extends to offer more hooks and keep up with flashy
technologies which the competition boasts.

I am admittedly among those who prefer Web-based bloatware at times,
especially if it obviates the need to run around the Web, collecting your
favourite 'bits', keeping them up-to-date (without interference) to create
a customised CMS 'distribution'.

Roy

--
Roy S. Schestowitz      |    "Oops. My brain just hit a bad sector"
http://Schestowitz.com  |    SuSE Linux     |     PGP-Key: 0x74572E8E
  9:00pm  up 20 days 16:16,  11 users,  load average: 0.42, 0.49, 0.53

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

Re: 2.next - faster [flat/static build]

Douglas Daulton
In reply to this post by Scott johnson-5
In addition to tweaking SQL, creating a native option for a flat/static
build (like Moveable Type) would reduce server load and increase SEO for WP
2.next.  There are some plug-ins out there that do this.  Why not look at
them all and build a "best of show" into the core.

This would have the added benefit of making WP more attractive to MT users
who need/want static builds.

DD


On 2/6/06 12:40 PM, "Scott johnson" <[hidden email]> wrote:

> Faster, imho, involves tradeoffs at this point. My gut just on web apps is
> that faster means "look hard at the SQL".  For example I learned TONS about
> mysql scaling at Feedster that I think is applicable but it starts to get
> specialized like memcache support, write versus read servers, etc.,
> seriously playing with your table structure, etc.
>
> Faster in what environment???  I'm happy to contribute ideas but given the
> spectrum of sites WP runs on this question has major ramifications
>
> Scott

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

Re: 2.next - faster

David Chait
In reply to this post by David House
As I mentioned in the earlier 2.next, maybe it is time to 'adopt' wp-cache
(which is an offshoot of matt's own Staticize -- correct me if I'm recalling
wrongly...) back into the core?  Even as a plugin, it'd be great.  If
actually integrated, it should be an option (like the object cache should
be).

Stats have shown wp-cache to be one of the biggest wins aside from purely
static-page generation (or lightpress).

Any testing of ways to improve the speed of the non-cached system on general
hosting (shared) would be good.  For instance, maybe one particular query
being cached would make an impact, or adding a few keys here or there?

Also, discussion/testing of 'optional environments' would be good,
especially if we can find hosts willing to 'play ball with us'.  I'm
thinking specifically thttpd and/or lighttpd, which have proven speed over
apache (and big, major sites use one of the two in many cases for static
content, but they've proven useful for php as well...).

-d

----- Original Message -----
From: "David House" <[hidden email]>
To: <[hidden email]>
Sent: Monday, February 06, 2006 3:48 PM
Subject: Re: [wp-hackers] 2.next - faster


On 06/02/06, Scott johnson <[hidden email]> wrote:
> Faster, imho, involves tradeoffs at this point. My gut just on web apps is
> that faster means "look hard at the SQL".  For example I learned TONS
> about
> mysql scaling at Feedster that I think is applicable but it starts to get
> specialized like memcache support, write versus read servers, etc.,
> seriously playing with your table structure, etc.

Most of the time taken for WordPress to load is down to the long time
needed for PHP to parse the thousands of lines of code, IIRC.

--
-David House, [hidden email], http://xmouse.ithium.net
_______________________________________________
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
|  
Report Content as Inappropriate

Re: 2.next - faster [flat/static build]

Matt Mullenweg
In reply to this post by Douglas Daulton
Douglas Daulton wrote:
> In addition to tweaking SQL, creating a native option for a flat/static
> build (like Moveable Type) would reduce server load and increase SEO for WP
> 2.next.  There are some plug-ins out there that do this.  Why not look at
> them all and build a "best of show" into the core.

Just to dispel a common misperception, there is NO SEO benefit by having
static files as opposed to WP's nice permalinks. They both look "static"
to search engines.

--
Matt Mullenweg
  http://photomatt.net | http://wordpress.org
http://automattic.com | http://akismet.com
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.next - faster [flat/static build]

Douglas Daulton
Agreed.  However isn't there an SEO gain from parsing the static page
itself?  Happy to be educated to the contrary.

On 2/6/06 2:31 PM, "Matt Mullenweg" <[hidden email]> wrote:

> Douglas Daulton wrote:
>> In addition to tweaking SQL, creating a native option for a flat/static
>> build (like Moveable Type) would reduce server load and increase SEO for WP
>> 2.next.  There are some plug-ins out there that do this.  Why not look at
>> them all and build a "best of show" into the core.
>
> Just to dispel a common misperception, there is NO SEO benefit by having
> static files as opposed to WP's nice permalinks. They both look "static"
> to search engines.

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

Re: 2.next - faster [flat/static build]

Pete Prodoehl
Douglas Daulton wrote:
> On 2/6/06 2:31 PM, "Matt Mullenweg" <[hidden email]> wrote:
>> Douglas Daulton wrote:
>>> In addition to tweaking SQL, creating a native option for a flat/static
>>> build (like Moveable Type) would reduce server load and increase SEO for WP
>>> 2.next.  There are some plug-ins out there that do this.  Why not look at
>>> them all and build a "best of show" into the core.
>> Just to dispel a common misperception, there is NO SEO benefit by having
>> static files as opposed to WP's nice permalinks. They both look "static"
>> to search engines.

 > Agreed.  However isn't there an SEO gain from parsing the static page
 > itself?  Happy to be educated to the contrary.

How? The HTML that gets served to the client (your browser, or in this
case, an indexer) is no different whether it is a static file, or
assembled via WP or any other technology. In the ideal world, you would
not be able to tell static from dynamic, and in many cases, you can't.

Pete

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

Re: 2.next - faster [flat/static build]

David Chait
In reply to this post by Douglas Daulton
Nope.  A static (or WP-Cache'd) page literally looks the same to the bot or
browser.  Many 'dynamic' pages are actually the same every pageload, have no
changing content, thus are very well sped up just by using wp-cache (or
similar caching on other systems).

-d

----- Original Message -----
From: "Douglas Daulton" <[hidden email]>
To: "WP Hackers" <[hidden email]>
Sent: Monday, February 06, 2006 6:25 PM
Subject: Re: [wp-hackers] 2.next - faster [flat/static build]


| Agreed.  However isn't there an SEO gain from parsing the static page
| itself?  Happy to be educated to the contrary.
|
| On 2/6/06 2:31 PM, "Matt Mullenweg" <[hidden email]> wrote:
|
| > Douglas Daulton wrote:
| >> In addition to tweaking SQL, creating a native option for a flat/static
| >> build (like Moveable Type) would reduce server load and increase SEO
for WP
| >> 2.next.  There are some plug-ins out there that do this.  Why not look
at
| >> them all and build a "best of show" into the core.
| >
| > Just to dispel a common misperception, there is NO SEO benefit by having
| > static files as opposed to WP's nice permalinks. They both look "static"
| > to search engines.
|
| _______________________________________________
| 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
|  
Report Content as Inappropriate

Re: 2.next - faster

Matt Mullenweg
In reply to this post by David House
David House wrote:
> Most of the time taken for WordPress to load is down to the long time
> needed for PHP to parse the thousands of lines of code, IIRC.

Yep, and an opcode cache helps a HUGE amount here. So much that it might
not be worth optimizing for this case for the very small percentage of
users that need that performance but can't run an opcode cache.

--
Matt Mullenweg
  http://photomatt.net | http://wordpress.org
http://automattic.com | http://akismet.com

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

Re: 2.next - faster

Scott johnson-5
Correct.  While I hate to say "wait for people to upgrade to php5",
the opcode cache is standard (from what I know) in php5.  Waiting for
people to upgrade to php5 would save a lot of engineering effort.

Note: I hate to NOT be definitive on something like this but most of
my experience is in php 4.1.x since that's what our systems ran.  That
said when we moved to APC and were able to use it (not always) we did
see a reliable 50%+ improvement.  The reasons we didn't run it as a
standard were more us than anything else.

S

On 2/6/06, Matt Mullenweg <[hidden email]> wrote:

> David House wrote:
> > Most of the time taken for WordPress to load is down to the long time
> > needed for PHP to parse the thousands of lines of code, IIRC.
>
> Yep, and an opcode cache helps a HUGE amount here. So much that it might
> not be worth optimizing for this case for the very small percentage of
> users that need that performance but can't run an opcode cache.
>
> --
> Matt Mullenweg
>   http://photomatt.net | http://wordpress.org
> http://automattic.com | http://akismet.com
>
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>


--
-------------------------------------------------------
J. Scott Johnson
Ookles launches 2/28/06 - have you signed up yet?
new startup: http://ookles.com/
blog: http://fuzzyblog.com/
podcast: http://techwarstories.com/
[hidden email]
aim: fuzzygroup
cell: 857 222 6459
-------------------------------------------------------
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.next - faster

Sebastian Herp
In reply to this post by Scott johnson-5
Speeding things up in 2.next would be nice. Making the function
"current_time()" pluggable (overwriting it with something using the
value from the following plugin), together with a plugin like the one
found here (http://txfx.net/files/wordpress/post-query-accelerator.phps)
would greatly improve the chance that a query can be cached by mysql
itself. I did this on a blog and the overall time needed for queries is
now 30ms if they are all in the mysql cache which is the case most of
the time!!!

However, this is not the main time eater on my setup. It's mainly the
php code execution. Wordpress (always on my server and speaking of the
frontpage) takes 150 to 200 ms to get to the point where it actually
outputs html. The other big thing is the content loop. Formatting every
posting each time takes a while. Getting categories and other
information also eats some milliseconds. Summed up the content display
stuff takes around 300 ms to execute.

So it's nearly 500 ms for code execution version 30 ms for mysql queries
... fix the code I say :-) We can savely assume that hosters use
powerful hardware with caches everywhere. They would be stupid not to ...

What needs to be done to improve Wordpress' performance (in my opinion)?
1. don't use now() or aquivalents in any query! That one should be core
and not solved with a plugin!
2. find out what takes so long before content is displayed (it's not a
sql query!)
3. don't filter the content of posts/comments each time they are
displayed, instead do it on updates of the content only (the columns for
that exist in the database) This should also be core and not solved with
a plugin!
4. fix the content loop! The  posts array should include all necessary
information (kategories with names, comment cound, etc) without the need
for seperate queries or whatever happens in those getter-functions that
lets them eat away so many precious milliseconds.
5. encourage plugin authors of popular plugins to do some performance
tuning, too ;-)

Greetings,
Sebastian

Scott johnson wrote:

> Faster, imho, involves tradeoffs at this point. My gut just on web apps is
> that faster means "look hard at the SQL".  For example I learned TONS about
> mysql scaling at Feedster that I think is applicable but it starts to get
> specialized like memcache support, write versus read servers, etc.,
> seriously playing with your table structure, etc.
>
> Faster in what environment???  I'm happy to contribute ideas but given the
> spectrum of sites WP runs on this question has major ramifications
>
> Scott
>
>  

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

Re: 2.next - faster

Theodor Ramisch
In reply to this post by Scott johnson-5
Hi,

> > How can we make it faster?
> Faster to /use/?

Separation of the ping process was a good idea. But the post page
is till to slow. It would be great if other "time-hungry" actions
like pinging technorati are asynchronous to the user too.

Plugins which calculate statistics, build sitemaps or do something
similar could also use this process, so a hook should be available.

There is only the problem that there is no possibility to notice
the user if something fails like missing file permissions. A small
log at the dashboard could solve this problem.

Just some ideas...


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

Re: 2.next - faster

Robert Deaton
In reply to this post by Scott johnson-5
On 2/7/06, Scott johnson <[hidden email]> wrote:
> Correct.  While I hate to say "wait for people to upgrade to php5",
> the opcode cache is standard (from what I know) in php5.  Waiting for
> people to upgrade to php5 would save a lot of engineering effort.
>

Hate to be a slap of reality, but PHP5 does not include an opcode
cache, although there are PECL extensions such as APC for it.

On the bright side, PHP6 has talk of including an opcode cache,
however nothing is in concrete, and PHP6 is still, at the very least,
over a year away from its first stable release, more likely a year and
a half away from its first RC release.

--
--Robert Deaton
http://somethingunpredictable.com

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

Re: 2.next - faster

David Chait
In reply to this post by Sebastian Herp
Have you tried WP-Cache on your system?  Most of what you discuss would be
solved with WP-Cache built-in to WP in the future (on an option, of course).

I believe that caching should occur at the page/request level whenever
possible -- even though my own site right now won't work well, as I have
truly dynamic content (ads, etc.) that are invoked directly in the php
rather than via secondary content loading (img tag, javascript, etc.).  With
page caching in place, very little else needs be optimized/cached.

Now, given that, some of the things you've pointed out are useful bits.
Even with page caching, things that invalidate the cache frequently enough
(i.e., new comments) could still be an impact on large/heavy sites unless
there is other performance enhancements.

-d

----- Original Message -----
From: "Sebastian Herp" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, February 07, 2006 11:57 AM
Subject: Re: [wp-hackers] 2.next - faster


| Speeding things up in 2.next would be nice. Making the function
| "current_time()" pluggable (overwriting it with something using the
| value from the following plugin), together with a plugin like the one
| found here (http://txfx.net/files/wordpress/post-query-accelerator.phps)
| would greatly improve the chance that a query can be cached by mysql
| itself. I did this on a blog and the overall time needed for queries is
| now 30ms if they are all in the mysql cache which is the case most of
| the time!!!
|
| However, this is not the main time eater on my setup. It's mainly the
| php code execution. Wordpress (always on my server and speaking of the
| frontpage) takes 150 to 200 ms to get to the point where it actually
| outputs html. The other big thing is the content loop. Formatting every
| posting each time takes a while. Getting categories and other
| information also eats some milliseconds. Summed up the content display
| stuff takes around 300 ms to execute.
|

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

Re: 2.next - faster

Sebastian Herp
David Chait wrote:
> Have you tried WP-Cache on your system?  Most of what you discuss would be
> solved with WP-Cache built-in to WP in the future (on an option, of course).
>
>  
Yes, I tried WP-Cache. It does not speed up things versus Staticize
Reloaded and even the later one modified to store the files in the
database itself is fast enough (around 80 ms for every request). And
yes, it is the ideal solution with some restrictions. Nothing some
modifications shouldn't fix ;-)
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.next - faster

Jamie Talbot
In reply to this post by Sebastian Herp
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sebastian Herp wrote:

<snip>

> 3. don't filter the content of posts/comments each time they are
> displayed, instead do it on updates of the content only (the columns for
> that exist in the database) This should also be core and not solved with
> a plugin!

Some nice ideas there, +1 especially for removing now(), but we can't really do 3. because that
would break the ability to create filters that work based on the current time, or other
run-time-available-only information.

Jamie.


- --
http://jamietalbot.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD6crTrovxfShShFARAn94AJ9tOyux3dgNsYK8tWiACYdsacS0nQCeJENj
f65SEZPioPMBZELbdql311M=
=20C/
-----END PGP SIGNATURE-----
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.next - faster

Sebastian Herp
Jamie Talbot wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sebastian Herp wrote:
>
> <snip>
>
>  
>> 3. don't filter the content of posts/comments each time they are
>> displayed, instead do it on updates of the content only (the columns for
>> that exist in the database) This should also be core and not solved with
>> a plugin!
>>    
>
> Some nice ideas there, +1 especially for removing now(), but we can't really do 3. because that
> would break the ability to create filters that work based on the current time, or other
> run-time-available-only information.
>  

That's true. But those filters could still be executed on the
"pre-rendered" content. But plugins like dofollow, textile, markdown,
external link finders, etc do not need to filter the content every time
it's displayed, do they?
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.next - faster

Jamie Talbot
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sebastian Herp wrote:

> Jamie Talbot wrote:
>> Some nice ideas there, +1 especially for removing now(), but we can't
>> really do 3. because that
>> would break the ability to create filters that work based on the
>> current time, or other
>> run-time-available-only information.
>>  
>
> That's true. But those filters could still be executed on the
> "pre-rendered" content. But plugins like dofollow, textile, markdown,
> external link finders, etc do not need to filter the content every time
> it's displayed, do they?

That's true :) But we'd need a way to distinguish between those plugins that do and don't...

Jamie.

- --
http://jamietalbot.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD6c9WrovxfShShFARAr4+AJ97usv+K9CT7giTu4S62M56rC0jgwCePdRU
QQoFfMJ8bJiA0UsJj+tTnuk=
=CLXp
-----END PGP SIGNATURE-----
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.next - faster

Kimmo Suominen-3
On Wed, Feb 08, 2006 at 08:00:38PM +0900, Jamie Talbot wrote:
> Sebastian Herp wrote:
> > That's true. But those filters could still be executed on the
> > "pre-rendered" content. But plugins like dofollow, textile, markdown,
> > external link finders, etc do not need to filter the content every time
> > it's displayed, do they?
>
> That's true :) But we'd need a way to distinguish between those
> plugins that do and don't...

Different hook for each place, then --> fix plugin.  :)

I think it would be a good thing, and not so difficult to fix in the
plugins.

It would be good to have a standard way for the plugins to figure out
what version of WP they are in.  Maybe there is, and I just haven't
learned about it?

Best regards,
+ Kimmo
--
<A HREF="http://kimmo.suominen.com/">Kimmo Suominen</A>

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