不错,终于移到了phpfog上面了。效率也不错,只是不知道能撑多久。
因为,好象如果量多,可能会收费。
不错,终于移到了phpfog上面了。效率也不错,只是不知道能撑多久。
因为,好象如果量多,可能会收费。
内容内容
内容内容

内容内容
内容内容
关于匿名函数的调用,以前司徒正美【博客园】专门有写过,常见的大约也就那么几种,比如
(function(x,y){
alert(x+y);
return x+y;
}(3,4)); //注意这里的括号顺序
除了上面这种,还有一种是
(function(x,y){
alert(x+y);
return x+y;
})(3,4); //看这里与上面同样的位置
这是几种比较妖的调用方式:
-function(x,y){
alert(x+y);
return x+y;
}(3,4);
+function(x,y){
alert(x+y);
return x+y;
}(3,4);
--function(x,y){
alert(x+y);
return x+y;
}(3,4);
++function(x,y){
alert(x+y);
return x+y;
}(3,4);
好象还记得有这种:
~function(x,y){
alert(x+y);
return x+y;
}(3,4);
//如果前面没任何操作符,直接就
function(x,y){
alert(x+y);
return x+y;
}(3,4);
//这种就是错误的的了。
本文参考:
1、Snandy(http://www.cnblogs.com/snandy/archive/2011/02/28/1966664.html)
2、司徒正美(http://www.cnblogs.com/rubylouvre/archive/2010/03/25/1667364.html)
迁移成功。记录一下。
遇到了很多问题,比如500之类的。明天会写篇博客记录一下。。。
Original page url is:http://www.cnblogs.com/teddyma/archive/2010/02/23/1672295.html ,Author is Teddy.
let’s read the file…
Background
Caching is an very important topic in enterprise-level multi-tier application, especially for web application. A general rule for applying caching is you should consider do necessary caching at each tier of your application if possible. The other basic rule for applying caching is the closer the cache is near the user, the cheaper the cost to implement it is. For example, to implement browser side caching is much cheaper than at server side.
For a B/S application, from client to server side, possible tiers to implement caching include:
* Browser: local sandbox cache, memory cache
* Network Router: CDN
* Web Server: HTTP output cache, memory cache, distributed cache
* Application Server: memory cache, distributed cache
* Database Server: memory cache, file system cache
The Cache-Control HTTP Headers standardizes the cache policy from browser, to network router and to Web server. Different Web browsers implement their internal caching according to the standard Web protocols.
CDN helps us cache and distribute content through Network routers between browsers and Web servers automatically.
Modern database systems could manage the caching of database server well enough by themselves.
So the only places need additional implementation for caching are in our application code, for a B/S application it may include:
* Browser side code (scripts, Flash/Silverlight, Java Applet/MS ActiveX/Smart Client, etc)
* Application code
* Database query code
I don’t want to talk much about caching in browser side code and database query code, because browser side caching more means how many memory you want the browser to occupy at client machine and there are no “thread synchronization” problems to be considered; and database side caching has its own guideline according to the database query language standards and different database system implementation.
So what left, worth to be discussed more is the caching in main application code. For a .NET C# application, this should mean the C# code to be compiled into executables to be deployed onto different tier servers. To be simple for discussion, let’s make our discussion below focus on .NET C# application only.
Caching in Application Code
1. Output Cache
The word “output cache” seems be invented by Microsoft together with ASP.NET. But its principle is simple. It caches the entire HTTP response message by a key which consists of a specified set of fields in a HTTP request. Since with output cache, a HTTP request could get the response message without further execution if the key exists in the output cache active key list, the performance of the Web server could be improved a lot. Especially, from II6, page level output cache could be dealt at IIS instead of at the ASP.NET ISAPI, there for, the performance is even much better than before.
So, as a general rule, for any request, if the response is possible to be reused to some extent, you should consider use output cache. But before use it, according to the “the closer the cheaper” rule, you should consider apply caching at “closer” places than Web server first. For example, practically, if possible, pay for CDN to extend the benefit of output cache out of your Web server to 3rd party CDN servers.
2. ASP.NET Cache Class and EntLib Caching Application Block
Behind the output cache, is the caching for application data. ASP.NET provides the Caching class, and similarly, the EntLib provides the caching application block. Each of the Cache class implements not only a thread safe hash table, but also common cache expiration policies. But so far, there are still not build-in cache replacement algorithms, such as FIFO & LRU, which are required by most real enterprise application. That’s why I implements a set of cache classes with LRU algorithms in NIntegrate. And either of the Cache classes is still in-process caching only, which means, in a load-balanced farm, the application data cached in Cache instances may exists duplicated in each of the server in the farm.
3. Caching Service & Distributed Hash Table
If you want to shared cached data among processes and even among servers, you need shared caching service in separate process or distributed hash table.
A caching service is a service wrapping a hash table executing in a separate process, but store shared data among different processes on the same server. For example, I could implement it as a namedpipe binding based WCF service, exposing methods for operating an internal hash table, which stores shared application data of 3 ASP.NET application deployed on the same Web server.
Furthermore, a distributed hash table is more like a caching service be deployed on a separate server or even farm, which stores shared application data of different applications deployed on different servers and farms. The biggest benefit of distributed hash table is the cached data is not duplicated in different server, so you could expire cached data centrally. But you should realize that the performance of a distributed hash table is worse than a caching service deployed on the same server of an application, and of course far worse than in-process caching. But in practice, because in most cases, the performance bottle neck of enterprise applications is database server, and compare to querying database, the performance of distributed hash table is still much faster and it could be scale-out easier than database, so distributed hash table could still benefit a lot on performance and is a indispensable part of enterprise applications.
–the end –
Yes ,you know the caching must be using three types on ouput or application or database ,so you can optimize it with these types on php.if use outpucache ,you can choose ob_* function.if use application cache,you can choose APC or Eacceraltor or ZendOptimizer.If use database cache ,you can choose memcached or filecache .
前段时间,yhustc问群里的人说是,如果有两个4G的文件,怎么样把其中相同的URL取出来?(文件大小4G,每行一个URL,每个URL64个字节),一下子迷惘了。后来他说了这个Bloom Filters,于是找了点资料 。
以下为部分资料,下次贴带图片(公式)的。。【文中有图片,但事实上原文并没有图片,来源于http://www.chinaunix.net/jh/25/601028.html】
仙子注:这篇文章是半年前翻译的,最早贴于公司内部的BBS上,并引起一些争论。Bloom Filters是一种效率较高的内存索引算法,它本身具有矛盾性:一方面能快速测试目标成员是否存在,另一方面又不可避免的具有假命中率。如下文档仅供参考。
由于不知道如何在这里粘贴图片,因此本文中没有包含图片说明,请对照原文档来阅读,原文档在:http://www.perl.com/pub/a/2004/04/08/bloom_filters.html?page=1 或可email给我索取中文PDF文档。
使用Bloom Filters
原作者:Maciej Ceglowski
April 08, 2004
任何perl使用者都熟悉hash查询,一个存在测试的语句可以这样写:
foreach my $e ( @things ) { $lookup{$e}++ }
sub check {
my ( $key ) = @_;
print "Found $key!" if exists( $lookup{ $key } );
}
虽然hash查询很有用,但对非常大的列表,或keys自身非常大时,这种查询可能变得不实用。当查询hash增长得太大,通常的做法是将它移到数据库或文件中,只在本地缓存里保存最常用的关键字,这样能改善性能。
许多人不知道有一种优雅的算法,用以代替hash查询。它是一种古老的算法,叫做Bloom filter。 Bloom filter允许你在有限的内存里(你想在这块内存里存放关键字的完整列表),执行成员测试,这样就能避开使用磁盘或数据库进行查询的性能瓶颈。也许你会认为,空间的节省是有代价的:存在着可大可小的假命中率风险,并且一旦你增加key到filter后,就不能删除它。然而在许多情形下,这些局限是可接受的,bloom filter能编制有用工具。(仙子注:例如代理服务器软件Squid就使用了bloom filter算法。)
例如,假如你运行了一个高流量的在线音乐存储站点,并且如果你已知歌曲存在,就可以通过仅获取歌曲信息的方法,来最大程度的减少数据库压力。你可以在启动时构建一个bloom filter,在试图执行昂贵的数据库查询前,可以用它执行快速的成员存在测试。
use Bloom::Filter;
my $filter = Bloom::Filter->new( error_rate => 0.01, capacity => $SONG_COUNT );
open my $fh, "enormous_list_of_titles.txt" or die "Failed to open: $!";
while (< $fh>) {
chomp;
$filter->add( $_ );
}
sub lookup_song {
my ( $title ) = @_;
return unless $filter->check( $title );
return expensive_db_query( $title ) or undef;
}
在该示例里,该测试给出假命中的几率是1%,在假命中率情况下程序会执行昂贵的数据库索取操作,并最终返回空结果。尽管如此,你已避开了99%的昂贵查询时间,仅使用了用于hash查询的一小片内存。更进一步,1%假命中率的filter,每个key的存储空间在2字节以下。这比你执行完整的 hash查询所需的内存少得多。
bloom filters在Burton Bloom之后命名,Burton Bloom 1970年首先在文档里描述了它们,文档名 Space/time trade-offs in hash coding with allowable errors.在那些内存稀少的日子里,bloom filters因其简洁而倍受重视。事实上,最早的应用之一是拼写检查程序。然而,由于有少数非常明显的特性,该算法特别适合社会软件应用。
因为bloom filters使用单向hash来存储数据,因此不可能在不做穷举搜索的情况下,重建filter里的keys列表。甚至这点看起来并非象很有用,既然来自穷举搜索的假命中会覆盖掉真正的keys列表。所以bloom filters能在不向全世界广播完整列表的情况下,共享关于已有资料的信息。因为这个理由,它们在peer-to-peer应用中特别有用,在这个应用中大小和隐私是重要的约束。
bloom filters如何工作
bloom filter由2部分组成:1套k hash函数,1个给定长度的位向量。选择位向量的长度,和hash函数的数量,依赖于我们想增加多少keys到设置中,以及我们能容忍的多高的假命中率。
bloom filter中所有的hash函数被配置过,其范围匹配位向量的长度。例如,假如向量是200位长,hash函数返回的值就在1到 200之间。在filter里使用高质量的hash函数相当重要,它保证输出等分在所有可能值上--hash函数里的“热点”会增加假命中率。(仙子注:所谓“热点”是指结果过分频繁的分布在某些值上。)
要将某个key输入bloom filer中,我们在每个k hash函数里遍历它,并将结果作为在位向量里的offsets,并打开我们在该offsets上找到的任何位。假如该位已经设置,我们继续保留其打开。还没有在bloom filter里关闭位的机制。
在本示例里,让我们看看某个bloom filter,它有3个hash函数,并且位向量的长度是14。我们用空格和星号来表示位向量,以便于观察。你也许想到,空的bloom filter以所有的位关闭为开始,如图1所示。
图1:空的bloom filter
现在我们将字符apples增加到filter中去。为了做到这点,我们以apples为参数来运行每个hash函数,并采集输出:
hash1(“apples”) = 3
hash2(“apples”) = 12
hash3(“apples”) = 11
然后我们打开在向量里相应位置的位--在这里就是位3,11,和12,如图2所示。
图2:激活了3位的bloom filter
为了增加另1个key,例如plums,我们重复hash运算过程:
hash1(“plums”) = 11
hash2(“plums”) = 1
hash3(“plums”) = 8
再次打开向量里相应的位,如图3里的高亮度显示。
图3:增加了第2个key的bloom filter
注意位置11的位已被打开--在前面的步骤里,当我们增加apples时已设置了它。位11现在有双重义务,存储apples和plums两者的信息。当增加更多的keys时,它也会存储其他keys的信息。这种交迭让bloom filters如此紧凑--任何位同时编码多个keys。这种交迭也意味着你永不能从filter里取出key,因为你不能保证你所关闭的位没有携载其他keys的信息。假如我们试图执行反运算过程来从filter里删除apples,就会不经意的关闭编码plums的1个位。从bloom filter里剥离key的唯一方法是重建filter,剔除无用key。
检查是否某个key已经存在于filter的过程,非常类似于增加新key。我们在所有的hash函数里遍历key,然后检查是否在那些 offsets上的位都是打开的。假如任何一位关闭,我们知道该key肯定不存在于filter中。假如所有位都打开,我们知道该key可能存在。
我说“可能”是因为存在一种情况,该key是个假命中。例如,假如我们用字符mango来测试filter,看看会发生什么情况。我们运行mango遍历hash函数:
hash1(“mango”) = 8
hash2(“mango”) = 3
hash3(“mango”) = 12
然后检查在那些offsets上的位,如图4所示。
图4:bloom filter的假命中
所有在位置3,8,和12的位都是打开的,故filter会报告mango是有效key。
当然,mango并非有效key--我们构建的filter仅包含apples和plums。事实是mango的offsets非常巧合的指向了已激活的位。这就找到了1个假命中--某个key看起来位于filter中,但实际不是。
正如你想的一样,假命中率依赖于位向量的长度和存储在filter里的keys的数量。位向量越宽阔,我们检查的所有k位被打开的可能性越小,除非该key确实存在于filter中。在hash函数的数量和假命中率之间的关系更敏感。假如使用的hash函数太少,在keys之间的差别就很少;但假如使用hash函数太多,filter会过于密集,增加了冲突的可能性。可以使用如下公式来计算任何filter的假命中率:
c = ( 1 – e(-kn/m) )k
这里c是假命中率,k是hash函数的数量,n是filter里keys的数量,m是filter的位长。
当使用bloom filters时,我们先要有个意识,期待假命中率多大;也应该有个粗糙的想法,关于多少keys要增加到filter里。我们需要一些方法来验证需要多大的位向量,以保证假命中率不会超出我们的限制。下列方程式会从错误率和keys数量求出向量长度:
m = -kn / ( ln( 1 – c ^ 1/k ) )
请注意另1个自由变量:k,hash函数的数量。可以用微积分来得出k的最小值,但有个偷懒的方法来做它:
sub calculate_shortest_filter_length {
my ( $num_keys, $error_rate ) = @_;
my $lowest_m;
my $best_k = 1;
foreach my $k ( 1..100 ) {
my $m = (-1 * $k * $num_keys) /
( log( 1 - ($error_rate ** (1/$k))));
if ( !defined $lowest_m or ($m < $lowest_m) ) {
$lowest_m = $m;
$best_k = $k;
}
}
return ( $lowest_m, $best_k );
}
为了给你直观的感觉,关于错误率和keys数量如何影响bloom filters的存储size,表1列出了一些在不同的容量/错误率组合下的向量size。
ErrorRate Keys RequiredSize Bytes/Key
1% 1K 1.87 K 1.9
0.1% 1K 2.80 K 2.9
0.01% 1K 3.74 K 3.7
0.01% 10K 37.4 K 3.7
0.01% 100K 374 K 3.7
0.01% 1M 3.74 M 3.7
0.001% 1M 4.68 M 4.7
0.0001% 1M 5.61 M 5.7
在Perl里构建bloom filter
为了构建1个工作bloom filter,我们需要1套良好的hash函数。这些容易解决--在CPAN上有几个优秀的hash算法可用。对我们的目的来说,较好的选择是Digest::SHA1,它是强度加密的hash,用C实现速度很快。通过对不同值的输出列表进行排序,我们能使用该模块来创建任意数量的hash函数。如下是构建唯一hash函数列表的子函数:
use Digest::SHA1 qw/sha1/;
sub make_hashing_functions {
my ( $count ) = @_;
my @functions;
for my $salt (1..$count ) {
push @functions, sub { sha1( $salt, $_[0] ) };
}
return @functions;
}
为了能够使用这些hash函数,我们必须找到1个方法来控制其范围。Digest::SHA1返回令人为难的过长160位hash输出,这仅在向量长度为2的160次方时有用,而这种情况实在罕见。我们结合使用位chopping和division来将输出削减到可用大小。
如下子函数取某个key,运行它遍历hash函数列表,并返回1个长度($FILTER_LENGTH)的位掩码:
sub make_bitmask {
my ( $key ) = @_;
my $mask = pack( "b*", '0' x $FILTER_LENGTH);
foreach my $hash_function ( @functions ){
my $hash = $hash_function->($key);
my $chopped = unpack("N", $hash );
my $bit_offset = $result % $FILTER_LENGTH;
vec( $mask, $bit_offset, 1 ) = 1;
}
return $mask;
}
让我们逐行分析上述代码:
my $mask = pack( "b*", '0' x $FILTER_LENGTH);
我们以使用perl的pack操作来创建零位向量开始,它是$FILTER_LENGTH长。pack取2个参数,1个模型和1个值。b模型告诉 pack将值解释为bits,*指“重复任意多需要的次数”,跟正则表达式类似。perl实际上会补充位向量的长度为8的倍数,但我们将忽视这些多余位。
有1个空的位向量在手中,我们准备开始运行key遍历hash函数:
my $hash = $hash_function->($key);
my $chopped = unpack("N", $hash );
我们保存首个32位输出,并丢弃剩下的。这点可让我们不必要求BigInt支持。第2行做实际的位chopping。模型里的N告诉unpack以网络字节顺序来解包32位整数。因为未在模型里提供任何量词,unpack仅解包1个整数,然后终止。
假如你对位chopping过度狂热,你可以将hash分割成5个32位的片断,并对它们一起执行OR运算,将所有信息保存在原始hash里:
my $chopped = pack( "N", 0 );
my @pieces = map { pack( "N", $_ ) } unpack("N*", $hash );
$chopped = $_ ^ $chopped foreach @pieces;
但这样作可能杀伤力过度。
现在我们有了来自hash函数的32位整数输出的列表,下一步必须做的是,裁减它们的大小,以使其位于(1..$FILTER_LENGTH)范围内。
my $bit_offset = $chopped % $FILTER_LENGTH;
现在我们已转换key为位offsets列表,这正是我们所求的。
剩下唯一要做的事情是,使用vec来设置位,vec取3个参数:向量自身,开始位置,要设置的位数量。我们能象赋值给变量一样来分配值给vec:
vec( $mask, $bit_offset, 1 ) = 1;
在设置了所有位后,我们以1个位掩码来结束,位掩码和bloom filter长度一样。我们可以使用这个掩码来增加key到filter中:
sub add {
my ( $key, $filter ) = @_;
my $mask = make_bitmask( $key );
$filter = $filter | $mask;
}
或者我们使用它来检查是否key已存在:
sub check {
my ( $key, $filter ) = @_;
my $mask = make_bitmask( $key );
my $found = ( ( $filter & $mask ) eq $mask );
return $found;
}
注意这些是位逻辑运算符OR(|)和AND(&),而并非通用的逻辑OR(||)和AND(&&)运算符。将这两者混在一起,会导致数小时的有趣调试。第1个示例将掩码和位向量进行OR运算,打开任何未设置的位。第2个示例将掩码和filter里相应的位置进行比较--假如掩码里所有的打开位也在filter里打开,我们知道已找到一个匹配。
一旦你克服了使用vec,pack和位逻辑运算符的难度,bloom filters实际非常简单。http://www.perl.com/2004/04/08/examples/Filter.pm 这里给出了Bloom::Filter模块的完整信息。
分布式社会网络中的bloom filters
当前的社会网络机制的弊端之一是,它们要求参与者泄露其联系列表给中央服务器,或公布它到公共Internet,这2种情况下都牺牲了大量的用户隐私。通过交换bloom filters而不是暴露联系列表,用户能参与社会网络实践,而不用通知全世界他们的朋友是谁。编码了某人联系信息的 bloom filter能用来检查它是否包含了给定的用户名或email地址,但不能强迫要求它展示用于构建它的完整keys列表。甚至有可能将假命中率(虽然它听起来不像好特性),转换为有用工具。
假如我非常关注这些人,他们通过对bloom filter运行字典攻击,来试图对社会网络进行反工程。我可以构建filter,它具备较高的假命中率(例如50%),然后发送filter的多个拷贝给朋友,并变换用于构建每个filter的hash函数。我的朋友收集到的filters越多,他们见到的假命中率越低。例如,在5个filters情况下,假命中率是0.5的5次方,或3%--通过发送更多filters,还能进一步减少假命中率。
假如这些filters中的任何一个被中途截取,它会展示全部50%的假命中率。所以我能隔离隐私风险,并且一定程度上能控制其他人能多清楚的
了解我的网络。我的朋友能较高程度的确认是否某个人位于联系列表里,但那些仅截取了1个或2个filters的人,几乎不会获取到什么。如下是个perl函数,它对1组嘈杂的filters检查某个key:
use Bloom::Filter;
sub check_noisy_filters {
my ( $key, @filters ) = @_;
foreach my $filter ( @filters ) {
return 0 unless $filter->check( $key );
}
return 1;
}
假如你和你的朋友同意使用相同的filter长度和hash函数设置,你也能使用位掩码对比来估计在你们的社会网络之间的交迭程度。在2个bloom filters里的共享位数量会给出1个可用的距离度量。
sub shared_on_bits {
my ( $filter_1, $filter_2 ) = @_;
return unpack( "%32b*", $filter_1 & $filter_2 )
}
另外,你能使用OR运算,结合2个有相同长度和hash函数的bloom filters来创建1个复合filter。例如,假如你参与某个小型邮件列表,并希望基于组里每个人的地址本来创建白名单,你可以为每个参与者独立的创建1个bloom filter,然后将filters一起进行OR运算,将结果输入Voltron-like主列表。组里成员不会了解到其他成员的联系信息,并且filter仍能展示正确的行为。
肯定还有其他针对社会网络和分布式应用的bloom filter妙用。如下参考列出一些有用资源。
参考
· Bloom Filters — the math. A good place to start for an overview of the math behind Bloom filters.
· Some Motley Bloom Tricks. Handy filter tricks and theory page.
· Bloom Filter Survey. A handy survey article on Bloom filter network applications.
· LOAF. Our own system for incorporating social networks onto email using Bloom filters.
· Compressed Bloom Filters. If you are passing filters around a network, you will want to optimize them for minimum size; this paper gives a good overview of compressed Bloom filters.
· Bloom16. A CPAN module implementing a counting Bloom filter.
· Text::Bloom. CPAN module for using Bloom filters with text collections.
· Privacy-Enhanced Searches Using Encryted Bloom Filters. This paper discusses how to use encryption and Bloom filters to set up a query system that prevents the search engine from knowing the query you are running.
· Bloom Filters as Summaries. Some performance data on actually using Bloom filters as cache summaries.
· Using Bloom Filters for Authenticated Yes/No Answers in the DNS. Internet draft for using Bloom filters to implement Secure DNS
【2010-06-21】今天,我已经升级到了3.0了。over
———————————————————-
上次是RC,这次是RC2,看来正式版离我们很近了。
事实上我也明白,如果不想多用户版,2.9已经够用了。wp为了让插件更容易开发,忽略的是性能,因此,在不装插件的情况下,WP的性能其实也还是可以接受的。只是插件多了,每次都要add_actin,add_xxxxx,就慢上很多。虽然插件都有缓存,但IO的消耗不会少呀?
看原新闻怎么说吧,RC2只更新了一条:
Changes:
This release contains many bugfixes and improvements since Release Candidate 1. There have been improvements in the nav menus, multisite, the TwentyTen theme, and the upgrade functions, to name a few. There is also new contextual help available.
感觉好象没什么太大的意义,看来,稳定多了。stable版本即将出现了
If you want to give your pluging an options page,you must set a administration menu or options sub menu. Some manual can find it on wordpress.org.
OK,to add an administration menu, you must do three things:
1. Create a function that contains the menu-building code
2. Register the above function using the “admin_menu” action hook
3. Create the HTML output for the page (screen) displayed when the menu item is clicked
It is that second step that is often overlooked by new developers. You cannot simply call the menu code described; you must put it inside a function, and then register the function.
Here is a very simple example of the three steps just described. This plugin will add a sub-level menu item under the Settings top-level menu, and when selected, that menu item will cause a very basic screen to display. Note: this code should be added to a main plugin PHP file or a separate PHP include file.
< ?php
add_action('admin_menu', 'my_plugin_menu');
function my_plugin_menu() {
add_options_page('My Plugin Options', 'My Plugin', 'manage_options', 'my-unique-identifier', 'my_plugin_options');
}
function my_plugin_options() {
if (!current_user_can('manage_options')) {
wp_die( __('You do not have sufficient permissions to access this page.') );
}
echo '< div class="wrap" >';
echo '< p >Here is where the form would go if I actually had options.< / p >';
echo '< / div >';
}
?>
Now,you looked this example, the function, my_plugin_menu(), adds a new item to the Administration menu via the add_options_page function. Note: more complicated multiple menu items can be added, but that will be described later. Notice the add_action line–that invokes the hook which “registers” the function, my_plugin_menu(). Without that add_action, a PHP error for “undefined function” will be thrown when attempting to activate the plugin. Finely, the add_options_page code refers to the my_plugin_options() function which contains the actual page to be displayed (and PHP code to be processed) when someone clicks the menu item.
The actual detail of these processes is described in more detail in the sections below. Remember to enclose creation of the menu and the html page in functions, and invoke the admin_menu hook to get the whole process started!
—//some code and english manual copy from http://codex.wordpress.org/Adding_Administration_Menus—
if you want to set an administration menu,you can see it..
1、自定义字段,详见 http://codex.wordpress.org/Using_Custom_Fields ,几个常见的方法有:
add_post_meta($id,$key,$value,$unique),update_post_meta,delete_post_meta
get_post_meta,get_post_meta_keys,get_post_meta_values
用于模版中的有,the_meta,get_post_meta
2、图片存在哪里?图片其实也是一条post数据,只是 post_type = attachment而己
其它post_type有,draft(草稿),revision(历史数据)等。
当图片的post_parent没有值时,认为它是孤立附件。如果有值是认为是有关联的,仅关联第一次,如果有多个文章插入此图片,默认只关联第一次的。
3、wp_links是友情链接表
wp_comments是回复表
wp_commentmeta和postmeta类似,但一般都用不到。
wp_options是系统配置表,可以用get_options等获取。
wp_terms等三个表是关联表,wp_terms里面存放了category,tag等信息
wp_users等两个表是用户相关表。由于usermeta信息是key,value对应的,所以当要取所有的用户及全部配置信息时就很郁闷。如果用户不多,建议是把wp_usermeta全部取出来之后,再用foreach等做键值对应,否则,SQL查询就会死人。
这篇文章是我转自sexywp.com的文章,有PDF版的下载哦,不过仔细看了之后,还是觉得比较简单,当然如果是初学的话,了解一下也足够了。
作者:Charles 原文链接:插件开发全攻略(目 录)