Nginx的rewrite语法其实很简单.用到的指令无非是这几个

set
if
return
break
rewrite

麻雀虽小,可御可萝五脏俱全.只是简单的几个指令却可以做出绝对不输apache的简单灵活的配置.
1.set

set主要是用来设置变量用的,没什么特别的

2.if

if主要用来判断一些在rewrite语句中无法直接匹配的条件,比如检测文件存在与否,http header,cookie等,

用法: if(条件) {…}

- 当if表达式中的条件为true,则执行if块中的语句

- 当表达式只是一个变量时,如果值为空或者任何以0开头的字符串都会当作false

- 直接比较内容时,使用 = 和 !=

- 使用正则表达式匹配时,使用

~ 大小写敏感匹配
~* 大小写不敏感匹配
!~ 大小写敏感不匹配
!~* 大小写不敏感不匹配

这几句话看起来有点绕,总之记住: ~为正则匹配, 后置*为大小写不敏感, 前置!为”非”操作

随便一提,因为nginx使用花括号{}判断区块,所以当正则中包含花括号时,则必须用双引号将正则包起来.对下面讲到的rewrite语句中的正则亦是如此.
比如 “\d{4}\d{2}\.+”

- 使用-f,-d,-e,-x检测文件和目录

-f 检测文件存在
-d 检测目录存在
-e 检测文件,目录或者符号链接存在
-x 检测文件可执行

跟~类似,前置!则为”非”操作

举例

if ($http_user_agent ~ MSIE) {
rewrite  ^(.*)$  /msie/$1  break;
}

//如果UA包含”MSIE”,rewrite 请求到/msie目录下

if ($http_cookie ~* “id=([^;] +)(?:;|$)” ) {
set  $id  $1;
}

//如果cookie匹配正则,设置变量$id等于正则引用部分

if ($request_method = POST ) {
return 405;
}

//如果提交方法为POST,则返回状态405 (Method not allowed)

if (!-f $request_filename) {
break;
proxy_pass  http://127.0.0.1;
}

//如果请求文件名不存在,则反向代理localhost

if ($args ~ post=140){
rewrite ^ http://example.com/ permanent;
}

//如果query string中包含”post=140″,永久重定向到example.com

3.return

return可用来直接设置HTTP返回状态,比如403,404等(301,302不可用return返回,这个下面会在rewrite提到)

4.break

立即停止rewrite检测,跟下面讲到的rewrite的break flag功能是一样的,区别在于前者是一个语句,后者是rewrite语句的flag

5.rewrite

最核心的功能(废话)

用法: rewrite 正则 替换 标志位

其中标志位有四种

break – 停止rewrite检测,也就是说当含有break flag的rewrite语句被执行时,该语句就是rewrite的最终结果
last – 停止rewrite检测,但是跟break有本质的不同,last的语句不一定是最终结果,这点后面会跟nginx的location匹配一起提到
redirect – 返回302临时重定向,一般用于重定向到完整的URL(包含http:部分)
permanent – 返回301永久重定向,一般用于重定向到完整的URL(包含http:部分)

因为301和302不能简单的只单纯返回状态码,还必须有重定向的URL,这就是return指令无法返回301,302的原因了. 作为替换,rewrite可以更灵活的使用redirect和permanent标志实现301和302. 比如上一篇日志中提到的Blog搬家要做的域名重定向,在nginx中就会这么写

rewrite ^(.*)$ http://newdomain.com/ permanent;

举例来说一下rewrite的实际应用

rewrite  ^(/download/.*)/media/(.*)\..*$  $1/mp3/$2.mp3  last;

如果请求为 /download/eva/media/op1.mp3 则请求被rewrite到 /download/eva/mp3/op1.mp3

使用起来就是这样,很简单不是么? 不过要注意的是rewrite有很多潜规则需要注意

- rewrite的生效区块为sever, location, if

- rewrite只对相对路径进行匹配,不包含hostname 比如说以上面301重定向的例子说明

rewrite ~* cafeneko\.info http://newdomain.com/ permanent;

这句是永远无法执行的,以这个URL为例

http://blog.cafeneko.info/2010/10/neokoseseiki_in_new_home/?utm_source=rss&utm_medium=rss&utm_campaign=neokoseseiki_in_new_home

其中cafeneko.info叫做hostname,再往后到?为止叫做相对路径,?后面的一串叫做query string

对于rewrite来说,其正则表达式仅对”/2010/10/neokoseseiki_in_new_home”这一部分进行匹配,即不包含hostname,也不包含query string .所以除非相对路径中包含跟域名一样的string,否则是不会匹配的. 如果非要做域名匹配的话就要使用if语句了,比如进行去www跳转

if ($host ~* ^www\.(cafeneko\.info)) {
set $host_without_www $1;
rewrite ^(.*)$ http://$host_without_www$1 permanent;
}

- 使用相对路径rewrite时,会根据HTTP header中的HOST跟nginx的server_name匹配后进行rewrite,如果HOST不匹配或者没有HOST信息的话则rewrite到server_name设置的第一个域名,如果没有设置server_name的话,会使用本机的localhost进行rewrite

- 前面提到过,rewrite的正则是不匹配query string的,所以默认情况下,query string是自动追加到rewrite后的地址上的,如果不想自动追加query string,则在rewrite地址的末尾添加?

rewrite  ^/users/(.*)$  /show?user=$1?  last;

rewrite的基本知识就是这么多..但还没有完..还有最头疼的部分没有说…

二、Nginx location 和 rewrite retry

nginx的rewrite有个很奇特的特性 — rewrite后的url会再次进行rewrite检查,最多重试10次,10次后还没有终止的话就会返回HTTP 500

用过nginx的朋友都知道location区块,location区块有点像Apache中的RewriteBase,但对于nginx来说location是控制的级别而已,里面的内容不仅仅是rewrite.

这里必须稍微先讲一点location的知识.location是nginx用来处理对同一个server不同的请求地址使用独立的配置的方式

举例:

location  = / {
….配置A
}

location  / {
….配置B
}

location ^~ /images/ {
….配置C
}

location ~* \.(gif|jpg|jpeg)$ {
….配置D
}

访问 / 会使用配置A
访问 /documents/document.html 会使用配置B
访问 /images/1.gif 会使用配置C
访问 /documents/1.jpg 会使用配置D

如何判断命中哪个location暂且按下不婊, 我们在实战篇再回头来看这个问题.

现在我们只需要明白一个情况: nginx可以有多个location并使用不同的配.

sever区块中如果有包含rewrite规则,则会最先执行,而且只会执行一次, 然后再判断命中哪个location的配置,再去执行该location中的rewrite, 当该location中的rewrite执行完毕时,rewrite并不会停止,而是根据rewrite过的URL再次判断location并执行其中的配置. 那么,这里就存在一个问题,如果rewrite写的不正确的话,是会在location区块间造成无限循环的.所以nginx才会加一个最多重试10次的上限. 比如这个例子

location /download/ {
rewrite  ^(/download/.*)/media/(.*)\..*$  $1/mp3/$2.mp3  last;
}

如果请求为 /download/eva/media/op1.mp3 则请求被rewrite到 /download/eva/mp3/op1.mp3

结果rewrite的结果重新命中了location /download/ 虽然这次并没有命中rewrite规则的正则表达式,但因为缺少终止rewrite的标志,其仍会不停重试download中rewrite规则直到达到10次上限返回HTTP 500

认真的朋友这时就会问了,上面的rewrite规则不是有标志位last么? last不是终止rewrite的意思么?

说到这里我就要抱怨下了,网上能找到关于nginx rewrite的文章中80%对last标志的解释都是

last – 基本上都用这个Flag

……这他妈坑爹呢!!! 什么叫基本上都用? 什么是不基本的情况?  =皿=

有兴趣的可以放狗”基本上都用这个Flag”…

我最终还是在stack overflow找到了答案:

last和break最大的不同在于

- break是终止当前location的rewrite检测,而且不再进行location匹配
– last是终止当前location的rewrite检测,但会继续重试location匹配并处理区块中的rewrite规则

还是这个该死的例子

location /download/ {
rewrite  ^(/download/.*)/media/(.*)\..*$  $1/mp3/$2.mp3  ;
rewrite  ^(/download/.*)/movie/(.*)\..*$  $1/avi/$2.mp3  ;
rewrite  ^(/download/.*)/avvvv/(.*)\..*$  $1/rmvb/$2.mp3 ;
}

上面没有写标志位,请各位自行脑补…

如果请求为 /download/acg/moive/UBW.avi

last的情况是: 在第2行rewrite处终止,并重试location /download..死循环
break的情况是: 在第2行rewrite处终止,其结果为最终的rewrite地址.

也就是说,上面的某位试图下载eva op不但没下到反而被HTTP 500射了一脸的例子正是因为用了last标志所以才会造成死循环,如果用break就没事了.

location /download/ {
rewrite  ^(/download/.*)/media/(.*)\..*$  $1/mp3/$2.mp3  break;
}

对于这个问题,我个人的建议是,如果是全局性质的rewrite,最好放在server区块中并减少不必要的location区块.location区块中的rewrite要想清楚是用last还是break.

有人可能会问,用break不就万无一失了么?

不对.有些情况是要用last的. 典型的例子就是wordpress的permalink rewrite

常见的情况下, wordpress的rewrite是放在location /下面,并将请求rewrite到/index.php

这时如果这里使用break乃就挂了,不信试试. ｂ（￣▽￣）ｄ…因为nginx返回的是没有解释的index.php的源码…

这里一定要使用last才可以在结束location / 的rewrite, 并再次命中location ~ \.php$,将其交给fastcgi进行解释.其后返回给浏览器的才是解释过的html代码.

关于nginx rewrite的简介到这里就全部讲完了,水平及其有限,请大家指出错漏…

三、实战! WordPress的Permalink+Supercache rewrite实现

这个rewrite写法其实是来自supercache作者本家的某个评论中,网上很容易查到,做了一些修改. 先给出该配置文件的全部内容..部分内容码掉了..绝对路径什么的你知道也没啥用对吧?

server {
listen   80;
server_name  cafeneko.info www.cafeneko.info;

access_log  ***;
error_log   *** ;

root   ***;
index  index.php;

gzip_static on;

if (-f $request_filename) {
break;
}

set $supercache_file ”;
set $supercache_uri $request_uri;

if ($request_method = POST) {
set $supercache_uri ”;
}

if ($query_string) {
set $supercache_uri ”;
}

if ($http_cookie ~* “comment_author_|wordpress_logged_|wp-postpass_” ) {
set $supercache_uri ”;
}

if ($supercache_uri ~ ^(.+)$) {
set $supercache_file /wp-content/cache/supercache/$http_host/$1index.html;
}

if (-f $document_root$supercache_file) {
rewrite ^(.*)$ $supercache_file break;
}

if (!-e $request_filename) {
rewrite . /index.php last;
}

location ~ \.php$ {

fastcgi_pass   127.0.0.1:9000;
fastcgi_index  index.php;
fastcgi_param  SCRIPT_FILENAME  ***$fastcgi_script_name;
include        fastcgi_params;
}

location ~ /\.ht {
deny  all;
}
}

下面是解释:

gzip_static on;

如果浏览器支持gzip,则在压缩前先寻找是否存在压缩好的同名gz文件避免再次压缩浪费资源,配合supercache的压缩功能一起使用效果最好,相比supercache原生的Apache mod_rewrite实现,nginx的实现简单的多. Apache mod_rewrite足足用了两套看起来一模一样的条件判断来分别rewrite支持gzip压缩和不支持的情况.

if (-f $request_filename) {
break;
}

//如果是直接请求某个真实存在的文件,则用break语句停止rewrite检查

set $supercache_file ”;
set $supercache_uri $request_uri;

//用$request_uri初始化变量 $supercache_uri.

if ($request_method = POST) {
set $supercache_uri ”;
}

//如果请求方式为POST,则不使用supercache.这里用清空$supercache_uri的方法来跳过检测,下面会看到

if ($query_string) {
set $supercache_uri ”;
}

//因为使用了rewrite的原因,正常情况下不应该有query_string(一般只有后台才会出现query string),有的话则不使用supercache

if ($http_cookie ~* “comment_author_|wordpress_logged_|wp-postpass_” ) {
set $supercache_uri ”;
}

//默认情况下,supercache是仅对unknown user使用的.其他诸如登录用户或者评论过的用户则不使用.

comment_author是测试评论用户的cookie, wordpress_logged是测试登录用户的cookie. wp-postpass不大清楚,字面上来看可能是曾经发表过文章的?只要cookie中含有这些字符串则条件成立.

原来的写法中检测登录用户cookie用的是wordpress_,但是我在测试中发现登入/登出以后还会有一个叫wordpress_test_cookie存在,不知道是什么作用,我也不清楚一般用户是否会产生这个cookie.由于考虑到登出以后这个cookie依然存在可能会影响到cache的判断,于是把这里改成了匹配wordpress_logged_

if ($supercache_uri ~ ^(.+)$) {
set $supercache_file /wp-content/cache/supercache/$http_host$1index.html;
}

//如果变量$supercache_uri不为空,则设置cache file的路径

这里稍微留意下$http_host$1index.html这串东西,其实写成 $http_host/$1/index.html 就好懂很多

以这个rewrite形式的url为例

cafeneko.info/2010/09/tsukihime-doujin_part01/

其中
$http_host = ‘cafeneko.info’ , $1 = $request_uri = ‘/2010/09/tsukihime-doujin_part01/’

则 $http_host$1index.html = ‘cafeneko.info/2010/09/tsukihime-doujin_part01/index.html’

而 $http_host/$1/index.html = ‘cafeneko.info//2010/09/tsukihime-doujin_part01//index.html’

虽然在调试过程中两者并没有不同,不过为了保持正确的路径,还是省略了中间的/符号.

最后上例rewrite后的url = ‘cafeneko.info/wp-content/cache/supercache/cafeneko.info/2010/09/tsukihime-doujin_part01/index.html’

if (-f $document_root$supercache_file) {
rewrite ^(.*)$ $supercache_file break;
}

//检查cache文件是否存在,存在的话则执行rewrite,留意这里因为是rewrite到html静态文件,所以可以直接用break终止掉.

if (!-e $request_filename) {
rewrite . /index.php last;
}

//执行到此则说明不使用suercache,进行wordpress的permalink rewrite

检查请求的文件/目录是否存在,如果不存在则条件成立, rewrite到index.php

顺便说一句,当时这里这句rewrite看的我百思不得其解. .

只能匹配一个字符啊?这是什么意思?

一般情况下,想调试nginx rewrite最简单的方法就是把flag写成redirect,这样就能在浏览器地址栏里看到真实的rewrite地址.

然而对于permalink rewrite却不能用这种方法,因为一旦写成redirect以后,不管点什么链接,只要没有supercache,都是跳转回首页了.

后来看了一些文章才明白了rewrite的本质,其实是在保持请求地址不变的情况下,在服务器端将请求转到特定的页面.

乍一看supercache的性质有点像302到静态文件,所以可以用redirect调试.

但是permalink却是性质完全不同的rewrite,这跟wordpress的处理方式有关. 我研究不深就不多说了,简单说就是保持URL不变将请求rewrite到index.php,WP将分析其URL结构再对其并进行匹配(文章,页面,tag等),然后再构建页面. 所以其实这条rewrite

rewrite . /index.php last;

说的是,任何请求都会被rewrite到index.php.因为”.”匹配任意字符,所以这条rewrite其实可以写成任何形式的能任意命中的正则.比如说

rewrite . /index.php last;
rewrite ^ /index.php last;
rewrite .* /index.php last;

效果都是一样的,都能做到permalink rewrite.

最后要提的就是有人可能注意到我的rewrite规则是放在server块中的.网上能找到的大多数关于wordpress的nginx rewrite规则都是放在location /下面的,但是上面我却放在了server块中,为何?

原因是WP或某个插件会在当前页面做一个POST的XHR请求,本来没什么特别,但问题就出在其XHR请求的URL结构上.

正常的permalink一般为: domain.com/year/month/postname/ 或者 domain.com/tags/tagname/ 之类.

但这个XHR请求的URL却是 domain.com/year/month/postname/index.php 或者 domain.com/tags/tagname/index.php

这样一来就命中了location ~ \.php$而交给fastcgi,但因为根本没有做过rewrite其页面不可能存在,结果就是这个XHR返回一个404

鉴于location之间匹配优先级的原因,我将主要的rewrite功能全部放进了server区块中,这样就得以保证在进行location匹配之前是一定做过rewrite的.

这时有朋友又要问了,为什么命中的是location ~ \.php$而不是location / ?

…望天…长叹…这就要扯到天杀的location匹配问题了….

locatoin并非像rewrite那样逐条执行,而是有着匹配优先级的,当一条请求同时满足几个location的匹配时,其只会选择其一的配置执行.

其寻找的方法为:

1. 首先寻找所有的常量匹配,如location /, location /av/, 以相对路径自左向右匹配,匹配长度最高的会被使用,
2. 然后按照配置文件中出现的顺序依次测试正则表达式,如 location ~ download\/$, location ~* \.wtf, 第一个匹配会被使用
3. 如果没有匹配的正则,则使用之前的常量匹配

而下面几种方法当匹配时会立即终止其他location的尝试

1. = 完全匹配,location = /download/
2. ^~ 终止正则测试,如location ^~ /download/ 如果这条是最长匹配,则终止正则测试,这个符号只能匹配常量
3. 在没有=或者^~的情况下,如果常量完全匹配,也会立即终止测试,比如请求为 /download/ 会完全命中location /download/而不继续其他的正则测试

总结:

1. 如果完全匹配(不管有没有=),尝试会立即终止
2. 以最长匹配测试各个常量,如果常量匹配并有 ^~, 尝试会终止
3. 按在配置文件中出现的顺序测试各个正则表达式
4. 如果第3步有命中,则使用其匹配location,否则使用第2步的location

另外还可以定义一种特殊的named location,以@开头,如location @thisissparta 不过这种location定义不用于一般的处理,而是专门用于try_file, error_page的处理,这里不再深入.

晕了没? 用前文的例子来看看

location  = / {
….配置A
}

location  / {
….配置B
}

location ^~ /images/ {
….配置C
}

location ~* \.(gif|jpg|jpeg)$ {
….配置D
}

访问 / 会使用配置A -> 完全命中
访问 /documents/document.html 会使用配置B -> 匹配常量B,不匹配正则C和D,所以用B
访问 /images/1.gif 会使用配置C -> 匹配常量B,匹配正则C,使用首个命中的正则,所以用C
访问 /documents/1.jpg 会使用配置D -> 匹配常量B,不匹配正则C,匹配正则D,使用首个命中的正则,所以用D

那么再回头看我们刚才说的问题.为什么那个URL结果奇怪的XHR请求会命中location ~ \.php$而不是location / ? 我相信你应该已经知道答案了.

所以要解决这个问题最简单的方法就是把rewrite规则放在比location先执行的server块里面就可以了哟.

这次的研究笔记就到此为止了.

最后留一个思考题,如果不将rewrite规则放入server块,还有什么方法可以解决这个XHR 404的问题?

原来的location /块包含从location ~ \.php$到root为止的部分.

答案是存在的.在用使用目前的方法前我死脑筋的在保留location /的前提下尝试了很多种方法…请不要尝试为各种permalink构建独立的location.因为wp的permalink种类很多,包括单篇文章,页面,分类,tag,作者,存档等等..欢迎在回复中讨论 /

参考: Nginx wiki

更新  @2010.10.23

之前的supercache rewrite规则适用于大部分的WP.但是并不适用于mobile press插件的移动设备支持.

因为其中并没有检测移动设备的user agent,从而导致移动设备也会被rewrite到cache上.这样的结果是在移动设备上也是看到的跟PC一样的完全版blog. 对于性能比较好的手机比如iphone安卓什么的大概没什么问题,但比较一般的比如nokia上用opera mini等看就会比较辛苦了,这次把supercache原本在htaccess中的移动设备检测的代码块也移植了过来.

在前文的配置文件中cookie检测后面加入以下代码段

# Bypass special user agent
if ($http_user_agent ~* “2.0 MMP|240×320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo Wii|Nitro|Nokia|Opera Mini|Palm|PlayStation Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915 Obigo|LGE VX|webOS|Nokia5800″) {
set $supercache_uri ”;
}

if ($http_user_agent ~* “w3c |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda\ |xda-”) {
set $supercache_uri ”;
}

这样就可以对移动设备绕开cache规则,而直接使用mobile press产生的移动版的效果了.

前阵子换了服务器后发现流量飞增，自己当时也没想到是没有开启gzip的原因，因为上个服务器默认开启了，当自己想到的时候从后台登录cpanel 一看，晕，竟然没有那个优化网站的选项，google之，发现网上介绍的方法也很多，有改php.ini的，有改.htaccess的，呃，方法很多，奶 牛也测试了一些，最后，种种原因，木有成功，不是主页不正常显示就是内部错误，这个方法毕竟都是有适应环境的，所以嘛，嘻嘻，不解释。

今天放一个奶牛测试成功了的方法，这个方法针对wordpress博客哦，操作很简单，只要在博客根目录下的index.php文件中加入一行代码就可以了。

找到根目录下的index.php文件中的

define('WP_USE_THEMES', true);

注意，这里的index.php文件是根目录下的，不是主题目录下的哦~

将上面代码的后面添加一行

ob_start('ob_gzhandler');

就可以了，保存退出，上传文件。然后从http://tool.chinaz.com/Gzips/等类似网站就可以查询自己的网站是否开启了gzip，嘻嘻，去试试吧~~~开启gzip可以压缩网页传输的文件，加快网站的载入速度，挺不错滴~

Just Shot Store

2、进入后为自动登陆，申请账户，快速获取证书！我们点击Express Lane，进入快速申请！

3、进入新注册页面，注意：所有信息都必须填写，而且地址要写详细，您可以提供真实的信息，或者编写的，但必须按照他的要求填写，以英文地址填写方法填写（示例只是为了演示）！注册后需要等待审核通过。

4、如果审核通过，你会在你注册的时候的邮箱内收到一封内容类似于下面的邮件，你按链接点过去，照提示一步一步就可以在你浏览器上安装一个证书了，这个证 书用于登录startssl网站，Startssl官网不是通过邮箱和密码登陆的， 只提供证书登陆，所以如果你丢了证书，那只能重新注册用户了。

5、当认证通过后，就可以看到下面的界面了，我们先做验证向导，点击Validations Wizard 选择Domain name validation 然后继续，选择您的域名，注意：不要输入WWW，后缀需要选择！

6、输入完网址后，需要验证网站所有者，主要向邮箱发送验证信息，验证邮箱前缀为postmaster@您的域名，hostmaster@您的域名，webmaster@您的域名，以及您注册域名时填写的邮箱




7、验证添加完域名后，开始申请SSL证书！点击左上角的CertificatesWizard选择WEB Server SSL/TSL Certifites！

8、接着您需要输入个人密钥，最少需要10位数，最大为32位数，必须为数字以及字母，不允许有符号，最好数字和字母混合！keysize最好为 2048，因为一般Cpanel控制面板支持2048，不支持4096大小！点击Continue后系统开始生成密钥，这个过程可能有点长，生成完毕后， 记得一定要按提示保存好那个私钥文件，否则到后面证书文件得到了，私钥文件丢了，就没法在做认证了。


9、生成完个人密钥后，您需要选择域名以及子域名，我们在里面填写WWW即可，您也可以选择其他子域名！然后开始生成公钥，这个过程也有点长，生成后的公钥您需要将其保存！

10、下面就等待几个小时，去邮箱看看刚申请的域名https证书是否成功得到了，如果得到了，就去下载证书文件就是了，相应步骤如下。

11、Startssl SSL证书就算申请好了

1、推荐先备份一下数据库，以防万一；

2、从后台停用一切插件；

3、将wp-admin和wp-includes上传至 wordpress 安装目录，可以完全覆盖，也可以删除这两个文件夹再上传；

4、将解压包根目录下除wp-config.php外的所有文件覆盖到服务器上wordpress根目录。切记别覆盖wp-config.php，这个里边是你的数据库等信息。否则会没有办法升级。

完成后直接在浏览器输入http://你的域名/wp-admin/upgrade.php进行升级吧，如果没有意外会很顺利的完成。

其实wordpress3.0最引人注目的是多站点功能，这样可以解决爱好者无需在服务器上安装多个wp以实现多博客的问题。

第一步：编辑配置文件

编辑根目录的 wp-config.php 文件，找到以下代码：

define ('WPLANG', 'zh_CN');

在其之后添加以下代码：

define('WP_ALLOW_MULTISITE', true);

这个时候刷新后台页面，工具菜单中已经有网络 (Network) 选项。

第二步：停用插件

为了顺利设置多站点功能，需要暂停所有已安装旧插件，可以在操作完成后重新开启。

第三步：创建文件夹

通过 FTP 或者其他方式在 wp-content 目录下创建 blogs.dir 目录，属性为 777 模式。这个目录用于存储子站点上传的媒体文件。

第四步：追加配置代码

刷新管理页面，点击工具菜单中的网络 (Network) 选项卡，系统会自动生成需要追加的代码片段。其中和 wp-config.php 相关的有两段代码。首先在后添加以下代码：

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
$base = '/'; //基准 URL
define( 'DOMAIN_CURRENT_SITE', 'www.yourname.com' ); //请将 www.yourname.com 替换为主站域名
define( 'PATH_CURRENT_SITE', '/' ); //当前博客路径
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

为了保证站点安全，需要接着添加以下代码尾随其后：

define( 'AUTH_SALT', '...' );
define( 'SECURE_AUTH_SALT', '...' );
define( 'LOGGED_IN_SALT', '...' );
define( 'NONCE_SALT', '...' );

这两段代码每个博客都不一样，请直接从后台提示页面拷贝。

第五步：修改Rewrite 规则，加入以下代码：

server_name_in_redirect off;

port_in_redirect off;

rewrite ^.*/files/(.*) /wp-content/blogs.php?file=$1;

if (!-e $request_filename) {

rewrite ^.+?(/wp-.*) $1 last;

rewrite ^.+?(/.*\.php)$ $1 last;

rewrite ^ /index.php last;

}

OK,完工。

chown -R www /home/wwwroot

把目录下wwwroot所有文件和文件夹的所有者改成叫做www的用户。经测试，wordpress可以顺利的自动升级了。

Firefox 6 新特性：

1. 支持progress元素；
2. 增加window.machMedia()方法以匹配CSS3的媒体查询；
3. 二进制数据API增强，包括XHR2和FileReader等；
4. WebSockets回归；
5. CSS text-decoration支持 -moz-text-decoration-color,-moz-text-decoration-line和-moz-text-decoration-style子属性；
6. 在交互的tab中，setTimeout和setInterval会延迟更多；
7. onhashchange时间新增newURL和oldURL属性；
8. 实现了beforeprint和afterprint事件；
9. 事件新增defaultPrevented属性，以判断event.preventDefault()方法是否被调用；
10. element.dataset属性可以用来获取或者修改HTML元素的”data-”前缀属性；
11. DOM3 CustomEvent规范实现；
12. 清除浏览器cookie的时候也会清掉Flash的cookie。

当然，Firefox6最终可能会有变数，这里仅供参考。更多内容可以查

据国外媒体报道，在我们享受Firefox 4新功能的时候，Mozilla已经准备在6月21日发布Firefox 5。

根据Mozilla的计划，Firefox浏览器的开发速度将提速。此举与Google对Chrome浏览器的做法相似，以此可在数月内推出一个新版Firefox浏览器，而Mozilla以前只能每两年推出一版Firefox。

下面，让我们来看下Firefox 5将添加的新功能：

任务栏网站固定

IE9最好的功能之一是任务栏网站固定，Firefox 5似乎也将添加类似的功能。新功能意味着用户可以把喜爱网站添加到任务栏，需要时可以从任务栏直接打开网站。

固定图标功能选项

除了网站固定功能，Firefox任务栏固定图标还可以显示一些功能选项。例如，Facebook固定图标可以显示信息提示和朋友状态更新等。

多彩搜索栏

搜索引擎配色方案可以让用户迅速区分不同的搜索工具，用户可以根据自己的需要方便地选择搜索引擎。

新的同步功能

Mozilla已经意识到同步功能的重要性，Firefox 5的同步功能将进一步得以改进。对于用户而言，出色的同步功能可以极大地方便跨平台使用浏览器。

插件更新

插件是Firefox浏览器的一大特色，但新版Firefox在插件更新和兼容方面还存在困难。从上图可以看出，Mozilla将允许Firefox用户统一升级浏览器插件。

1.到Prestashop 的 “modules” 文件夹，进入 “blockvariouslinks”,然后开始修改文件

prestashop 1.3 修改：

prestashop/yourtheme/modules/blockvariouslinks/blockvariouslinks.tpl

如果是 prestashop 1.4 修改：

prestashop/yourtheme/modules/blockcms/blockcms.tpl

2. 如果你的模板文件夹里没有 “modules” 文件夹，那么你可以修改这个文件：

prestashop/modules/blockvariouslinks/blockvariouslinks.tpl

3. 你可以修改或去除 ” Powered by Prestashop” 标记。

转自：http://www.jssharp.com/product.php?id_product=12

1.2以前的版本是不支持这个功能的，我很惊奇的发现1.2.5的category类里面的getProduct增加了读取随机产品的选项，所以我们不需要自己写sql语句了。

这算是1.2版本一个不小的改动吧，prestashop从07年末开始被广泛使用以来，进步还是很大的。

把homefeatured.php的69行改成这样，就支持随机商品了。

$products = $category->getProducts(intval($params['cookie']->id_lang), 1, ($nb ? $nb : 10), NULL, NULL, false, true, true, ($nb ? $nb : 10));