[wp-hackers] wp-hackers Digest, Vol 71, Issue 96
肖晗
xiaohan2012 at gmail.com
Fri Dec 17 16:00:22 UTC 2010
ok,really thanks!!
2010/12/17 <wp-hackers-request at lists.automattic.com>
> Send wp-hackers mailing list submissions to
> wp-hackers at lists.automattic.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.automattic.com/mailman/listinfo/wp-hackers
> or, via email, send a message with subject or body 'help' to
> wp-hackers-request at lists.automattic.com
>
> You can reach the person managing the list at
> wp-hackers-owner at lists.automattic.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of wp-hackers digest..."
>
>
> Today's Topics:
>
> 1. Re: Confusion About WordPress Cache (Austin Matzko)
> 2. Re: Batch Change Post Authors (Joaquin Rodriguez Montero)
> 3. Re: Confusion About WordPress Cache (Otto)
> 4. Re: WP Development & Production Sites (Ankur Oberoi)
> 5. Re: exclude category from main loops via plugin (Jeremy Clarke)
> 6. Re: exclude category from main loops via plugin (Paul)
> 7. Re: Confusion About WordPress Cache (Brian Layman)
> 8. Re: Batch Change Post Authors (Philip M. Hofer (Frumph))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 17 Dec 2010 08:46:49 -0600
> From: Austin Matzko <austin at ilfilosofo.com>
> Subject: Re: [wp-hackers] Confusion About WordPress Cache
> To: wp-hackers at lists.automattic.com
> Message-ID:
> <AANLkTinB-Z4LsarirJFOOwG-JM1vmKeZ_Vp4i5KcMsph at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Fri, Dec 17, 2010 at 8:42 AM, ?? <xiaohan2012 at gmail.com> wrote:
> > I wonder if I got the wrong idea of what *cache* is. I have it in mind
> that
> > *cache *can be preserved even in different requests
>
> The cache API in core WordPress provides just an object cache, but you
> can use a persistent caching tool to extend it to do what you want.
>
> See <http://codex.wordpress.org/Function_Reference/WP_Cache> under
> "Persistent Caching Plugins."
>
> Also, you may be able to accomplish what you need with transients:
> <http://codex.wordpress.org/Transients_API>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 17 Dec 2010 11:46:52 -0300
> From: Joaquin Rodriguez Montero <yojoaquin at gmail.com>
> Subject: Re: [wp-hackers] Batch Change Post Authors
> To: wp-hackers at lists.automattic.com
> Message-ID:
> <AANLkTinf8x_Q7vO-Q0qnYvJA458i20UzEs2K2n45jzQ1 at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> >> How about exporting by date range? Should be able to get smaller files
> without having to mess with anything else.
>
> Wow! I missed that alternative! Damn I'm stupid.
>
> Thanks Jon!
>
> >> Drop down the screen options tab (top right of posts panel) and set the
> number to "show on screen" to be 370.
>
> Cool! Thanks for the tip Mike!
>
>
>
> Message: 4
> Date: Fri, 17 Dec 2010 13:14:47 +0000
> From: Jon Cave <jon at lionsgoroar.co.uk>
> Subject: Re: [wp-hackers] Batch Change Post Authors
> To: wp-hackers at lists.automattic.com
> Message-ID:
> <AANLkTinEopcdnPtBwYMLCThq0bh8xaV-a24nDhaWGXum at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Dec 17, 2010 at 1:10 PM, Joaquin Rodriguez Montero
> <yojoaquin at gmail.com> wrote:
> >
> > Then I thought: why not change the authors of the posts and export them
> by
> > author. That generates a smaller size file, therefore the import process
> is
> > smooth.
>
> How about exporting by date range? Should be able to get smaller files
> without having to mess with anything else.
>
> ------------------
>
> Message: 5
> Date: Fri, 17 Dec 2010 13:15:51 +0000
> From: Mike Little <wordpress at zed1.com>
> Subject: Re: [wp-hackers] Batch Change Post Authors
> To: wp-hackers at lists.automattic.com
> Message-ID:
> <AANLkTinVO-N93i5JwXEB7SxVSa0pXFgTQ0vr6Di-_oMb at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Drop down the screen options tab (top right of posts panel) and set the
> number to "show on screen" to be 370.
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 17 Dec 2010 08:57:17 -0600
> From: Otto <otto at ottodestruct.com>
> Subject: Re: [wp-hackers] Confusion About WordPress Cache
> To: wp-hackers at lists.automattic.com
> Message-ID:
> <AANLkTinswxncOZkuMHb8zPVM4aoiEWZbfQ7hXpYpLbjJ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> The object cache doesn't default to storing data between requests,
> because it doesn't have anywhere to store it between those requests.
> So for normal usage, it just acts like a memory cache in a single
> request. However, if you do have a persistent storage medium, like a
> memcached setup or something, then there are plugins which will extend
> the wp_cache system to be persistent across requests. Example:
> http://wordpress.org/extend/plugins/memcached/. For this reason, the
> object cache should be treated as if it's (unreliable) persistent
> storage even when it's not that way by default.
>
> Like Austin said, the Transients API is also another option if you
> need to store data with an expiration date attached to it. However,
> this should not be used for storing data that is retrieved from the
> database, since transients are (by default) stored in the database
> anyway. Transients are intended to be used to store data that is
> expensive to create and which will need to be re-created every so
> often (such as data retrieved from another server, or data that takes
> a lot of processing to calculate).
>
> -Otto
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 17 Dec 2010 10:03:45 -0500
> From: Ankur Oberoi <aoberoi at gmail.com>
> Subject: Re: [wp-hackers] WP Development & Production Sites
> To: wp-hackers at lists.automattic.com
> Message-ID: <4A60E12B-597A-430D-A571-6C75706DBA0C at gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
> lol no i know it needs to be on the internet, that wasn't the issue at all.
> in fact, all the steps i took should be the same (i think) for the setup in
> which the stage is on the same machine as the live site. im not specifying
> any IP addresses, the subdomain gets resolved by the DNS, so it doesn't
> matter what machine the stage is on, the buffering just needs to put that
> subdomain in there. i just had 127.0.0.1 in the hosts because i wanted to
> test (on my machine) what a request going to stage would look like. i guess
> i didn't phrase that clearly, but i was trying to mimic the staging machine
> on my own dev machine before touching the server we use for live.
>
> i actually figured out why i couldn't get to wp-admin after digging into
> the code myself, i was just hoping someone was up that had done this before
> and gave me a quick answer. the problem was that output buffering doesn't
> apply to response headers which get sent immediately. therefore by the time
> the callback is fired, a redirect in the header has already taken place. the
> fix i found to work so far is to add this somewhere (i put it in my theme
> for now, but i'm thinking ill put it in a plugin later):
>
> // Redirect Plug for Development
> function redirect_to_stage($location, $status) {
> $location = str_replace('example.com', 'stage.example.com',
> $location);
> return $location;
> }
> add_filter('wp_redirect', 'redirect_to_stage');
>
> On Dec 17, 2010, at 7:37 AM, Otto wrote:
>
> > On Fri, Dec 17, 2010 at 1:39 AM, Ankur Oberoi <aoberoi at gmail.com> wrote:
> >>> Okay, let's say your production site is live.example.com and your
> >>> staging site is stage.example.com.
> >>>
> >>> On your staging site, you set it up to think it's the live site, with
> >>> the live URL. This is to make it identical in content and database and
> >>> such with the live site.
> >>>
> >>> Then, in some file that is not going to the live site (wp-config, any
> >>> plugin, etc), you'd do something sorta like this:
> >>>
> >>> ob_start('my_callback');
> >>> function my_callback($out) {
> >>> return str_replace('live.example.com', 'stage.example.com', $out);
> >>> }
> >>>
> >>> Output buffering. It's easy.
> >>> http://php.net/manual/en/function.ob-start.php
> >>
> >> I just got around to trying this out. At first I thought this was
> perfect and I took ur advice on modifying the hosts file to point to my own
> machine for the live URL. Then I tried to access wp-admin and I have an
> issue, maybe you've dealt with this so you can help me out.
> >>
> >> I (will) have a staging server at 'stage.example.com' and the site
> lives at 'example.com', so I set my output buffering callback function
> like this:
> >>
> >> function my_callback($out) {
> >> str_replace('example.com', 'stage.example.com', $out);
> >> return str_replace('http://example.com', '
> http://stage.example.com', $out);
> >> }
> >>
> >> I am trying to be extra cautious about the url, although i don't like
> the fact that if anywhere in my content i talk about example.com it will
> automatically be changed to stage.example.com, but in this case that won't
> happen so lets just ignore that.
> >>
> >> on my staging machine I added a line to /etc/hosts:
> >>
> >> 127.0.0.1 stage.example.com
> >>
> >> the machine also has a vhost running whose ServerName (apache specfic i
> guess) is set to stage.example.com and points to the directory in which
> the site lives.
> >>
> >> I am pretty sure I did all the steps right, but what would it take for
> my client to be able to visit stage.example.com/wp-admin in order to see
> the admin section as usual?
> >
> > If you want your client to see the staging site, then the staging site
> > has to be somewhere that they can see it. This means that if you're
> > running it on the local machine, then that ain't going to work.
> >
> > I was kind of assuming that stage.example.com was a live site
> > somewhere on the internet. If you're developing locally, then no magic
> > in the world will put the local install on the live internet... short
> > of actually putting the machine on the live internet as a server with
> > a domain name pointing to it.
> >
> > -Otto
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
>
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 17 Dec 2010 10:05:00 -0500
> From: Jeremy Clarke <jer at simianuprising.com>
> Subject: Re: [wp-hackers] exclude category from main loops via plugin
> To: wp-hackers at lists.automattic.com
> Message-ID:
> <AANLkTiniRZNDzbRVTmkUsp6WxHyr+d-XsuWemmBNrak4 at mail.gmail.com<AANLkTiniRZNDzbRVTmkUsp6WxHyr%2Bd-XsuWemmBNrak4 at mail.gmail.com>
> >
> Content-Type: text/plain; charset=windows-1252
>
> On Mon, Dec 13, 2010 at 8:17 AM, Erick Hitter <ehitter at gmail.com> wrote:
>
> >
> > Here's a sample:
> > function my_query( $query ) {
> > $query->query_vars[ 'category_name' ] = 'mycategory';
> > return $query;
> > }
> > add_action( 'pre_get_posts', 'my_query' );
> >
> >
> I recently struggled through this exact situation and will add that you
> should be very careful to test any other queries in your theme and make
> sure
> they aren't being affected. The code above will affect ALL posts queries
> everywhere on your site because it is added to the general pre_get_posts
> hook.
>
> In my case this meant that my 'recent posts' in the sidebar and other
> secondary loops were affected in ways I couldn't predict and didn't want.
>
> To get around this I wanted the query var to only be added for the 'main'
> query for any given page. My solution was to add the 'pre_get_posts' hook
> during the 'parse_request' action because it runs only once per pageload at
> the time when the main query and status of the current page is being
> determined. Then, inside my manipulation callback the first thing I do is
> run remove_action() on itself. This ensures that the manipulated query vars
> only take effect once, on the first query run after parse_query, which in
> my
> testing was always the 'main' query for the page.
>
> The code, massively simplified, looks like this (
> http://pastebin.com/B3YxmSGh )
>
>
> function gv_query_manipulation_parse_request() {
>
> add_action('pre_get_posts', 'gv_query_manipulation_pre_get_posts');
> }
> add_action('parse_request', 'gv_query_manipulation_parse_request');
>
> function gv_query_manipulation_pre_get_posts($wp_query){
> global $excluded_category;
>
> remove_action('pre_get_posts', 'gv_query_manipulation_pre_get_posts');
>
> if (is_admin() OR is_feed())
> return;
>
> $wp_query->query_vars['category__not_in'][] = $excluded_category;
>
> return;
> }
>
> Note that I've explicitly excluded is_admin and is_feed from being
> affected.
> You should consider these other situations where pre_get_posts takes effect
> and add negative checks as necessary.
>
>
> Jeremy Clarke ? jeremyclarke.org
> Code and Design ? globalvoicesonline.org
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 17 Dec 2010 10:33:03 -0500
> From: Paul <paul at codehooligans.com>
> Subject: Re: [wp-hackers] exclude category from main loops via plugin
> To: wp-hackers at lists.automattic.com
> Message-ID: <5AE49596-28C0-4A93-98A8-09469F92B3D8 at codehooligans.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Dec 17, 2010, at 10:05 AM, Jeremy Clarke wrote:
>
> > On Mon, Dec 13, 2010 at 8:17 AM, Erick Hitter <ehitter at gmail.com> wrote:
> >
> > function gv_query_manipulation_parse_request() {
> >
> > add_action('pre_get_posts', 'gv_query_manipulation_pre_get_posts');
> > }
> > add_action('parse_request', 'gv_query_manipulation_parse_request');
> >
> > function gv_query_manipulation_pre_get_posts($wp_query){
> > global $excluded_category;
> >
> > remove_action('pre_get_posts', 'gv_query_manipulation_pre_get_posts');
> >
> > if (is_admin() OR is_feed())
> > return;
> >
> > $wp_query->query_vars['category__not_in'][] = $excluded_category;
> >
> > return;
> > }
> >
> > Note that I've explicitly excluded is_admin and is_feed from being
> affected.
> > You should consider these other situations where pre_get_posts takes
> effect
> > and add negative checks as necessary.
> >
>
>
> Jeremy,
>
> In your code you are calling the function is_feed(). Isn't this wrong?
>
> When you call the is_* functions (exluding is_admin()) like is_home(),
> is_search(), is_archive() etc. they check the setting of the global
> $wp_query object. But this is not always the correct instance of the
> WP_Query object being queried. In other words some other part of the code
> may create a new instance.
>
> Instead the better solution (IMHO) is to check the $query object like:
>
> if ($query->is_feed) {
> }
>
> if ($query->is_home) {
> }
>
> if ($query->is_archive) {
> }
>
> if ($query->is_single) {
> }
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 17 Dec 2010 10:33:17 -0500
> From: Brian Layman <bulk at thecodecave.com>
> Subject: Re: [wp-hackers] Confusion About WordPress Cache
> To: wp-hackers at lists.automattic.com
> Message-ID: <4D0B82BD.1090400 at thecodecave.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 12/17/2010 9:57 AM, Otto wrote:
> > For this reason, the
> > object cache should be treated as if it's (unreliable) persistent
> > storage even when it's not that way by default.
> Unreliable - in that it should only be used for short to medium term
> storage as the data goes away when the daemon or machine restarts. So
> your retrieval of values should always fall back to generating the values.
>
> So in psuedocode, you'd have something like this:
>
> if (!$value = retrievefunction($networkid . '_' . $blogid .
> '_variablename')) {
> long();
> drawnout();
> generation();
> $value = finalprocessing();
> }
>
> Obviously that will look nothing like your final code, but I wanted to
> show that the actually value you store will, as with any global
> variable, needs to have a unique name or it will be overwritten.
>
> So, in a multisite environment, you should store your values under names
> that specify their scope. So, something that is global to all your
> networks needs to have nothing or perhaps a standardized 'global_'
> prefix. If it is for all sites on one network, prefix it with the
> network id. If it is specific to a site on a network, prefix it with the
> network AND site id.
>
> Even in a single site blog, setting up your cache names correctly now
> will save you headaches when 2 years down the line you decide to merge
> two blogs together or move your theme over to a multisite blog.
>
> -Brian
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 17 Dec 2010 07:37:02 -0800
> From: "Philip M. Hofer \(Frumph\)" <philip at frumph.net>
> Subject: Re: [wp-hackers] Batch Change Post Authors
> To: <wp-hackers at lists.automattic.com>
> Message-ID: <EE1E938E376A4B35A59E73F863891365 at frumph.net>
> Content-Type: text/plain; format=flowed; charset="UTF-8";
> reply-type=original
>
> doesnt wpmuguru's plugin advanced export allow you to export by author? I
> think it does.
>
>
>
> ----- Original Message -----
> From: "Joaquin Rodriguez Montero" <yojoaquin at gmail.com>
> To: <wp-hackers at lists.automattic.com>
> Sent: Friday, December 17, 2010 5:10 AM
> Subject: [wp-hackers] Batch Change Post Authors
>
>
> > Hi guys! Straight to the subject:
> >
> > I have +3700 posts which I'd like to export, but as you could imagine
> it'd
> > create a massive file "impossible" to import into another WP install. So
> I
> > thought, well, MySQL Dumper -> quite a decent file size, etc. Issue is,
> > content is in Spanish so each entry that has a "?" or letters with tilde
> > (?,?,?,?,?) produces entries without title.
> >
> > Then I thought: why not change the authors of the posts and export them
> by
> > author. That generates a smaller size file, therefore the import process
> > is
> > smooth. Now, is there a way to batch change this? Say, via SQL? Or
> > displaying more than 20 entries per page? That way I could batch change
> > the
> > authors via the Post panel.
> >
> > I'd create 10 authors and assign to each one of them 370 posts. Any
> > suggestion?
> >
> > Thanks!
> >
> > J
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
>
>
>
>
> ------------------------------
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
>
> End of wp-hackers Digest, Vol 71, Issue 96
> ******************************************
>
More information about the wp-hackers
mailing list