Posts Tagged ‘WordPress’

• 为cos-html-cache插件增加页面（Page）、标签（Tag）和分类（Category）的静态化功能

  Date: 2010.01.16 | Category: In My Opinion, WordPress | Response: 0

  Wordpress的cos-html-cache插件为我们系统的静态化提供了非常好的解决方案，目前的版本是2.7.3。它可以将我们首页及文章（Post）进行静态化，使得访问速度大大提高，减少了服务器端的压力。不过对于页面、标签和分类，却似乎不太起作用，至少在我的服务器环境下（IIS7.0+FastCGI）是不行的。

  为了能够实现它们，我分析了一下源代码，发现功能没有开启，但是可以实现的。具体修改方法及目的如下：

  找到如下三行：

  1. if( substr_count($_SERVER[’REQUEST_URI’], ‘.htm’) || ( SCRIPT_URI == CosSiteHome) ){
  2. if(  substr_count($_SERVER[’REQUEST_URI’], ‘../’))  $is_buffer = false;
  3. if( !substr_count($buffer, ‘<!–cos-html-cache-safe-tag–>’) ) return  $buffer;

  将他们分别做如下处理：

  1. 修改为：
     if( strpos($_SERVER[’REQUEST_URI’], ‘page’)==1 || strpos($_SERVER[’REQUEST_URI’], ‘tag’)==1 || strpos($_SERVER[’REQUEST_URI’], ‘category’)==1 || substr_count($_SERVER[’REQUEST_URI’], ‘.htm’) || ( SCRIPT_URI == CosSiteHome) ){
  2. 在本行下增加：
     if(  substr_count($_SERVER[’REQUEST_URI’], ‘comment’))  $is_buffer = false;
  3. 前面加上“//”注释掉本行

  分别的原理及目的：

  1. 这个是在检测我们要静态化哪些文件，我为它增加了page、tag和category。当然，这个也和目录的模式有关，比如我的博客中，OpenSolaris的标签地址就是：http://www.priormind.com/tag/opensolaris。所以我就找到以tag开头的目录并静态化它们
  2. 防止评论内容被静态化
  3. 作者写了个函数，将singlepost（也就是单页页面）、首页都加上了一个安全标签（<!–cos-html-cache-safe-tag–>）。有这个标签的话将不被静态化。而我们需要它们静态化，所以就把这行注释掉好了

  本人仅仅是尝试性修改，不保证其完全正确性。有兴趣的话大家可以试试看，呵呵。也欢迎一起交流。

  • 

• 转载：IIS FastCGI PHP 环境下搭建 WordPress

  Date: 2010.01.12 | Category: Learn from Others, Web Back-end, WordPress | Response: 0

  看到 Jerry Tao 在其博客上发表了一篇如何配置IIS7+FastCGI的文章，特转载过来学习。

  Win­dows Server 2008 (SP2) + IIS 7
  添加 Web 服务器角色，需要安装 CGI 扩展支持。

  

  Read the rest of this entry »

  • 

• 使用WP-Super-Cache 帮你加速构建在IIS7上的WordPress博客

  Date: 2009.04.26 | Category: WordPress | Response: 0

  自从我将自己的博客搬家到海外的一个IIS7的服务器上，我发现速度比原来构建在Linux上的系统要严重慢很多。我也一直在尝试着寻找为什么WP在IIS上跑竟然如此之慢，也想改变这种状况。

  将所有的日志和页面转换成静态html格式不失为一种加速博客很好的办法，通常我们都为我们的WordPress博客加装“WP-Super-Cache”插件。但很不幸，我在自己的主机上一直没用配置这个插件成功，总是遇到一些问题。不过今天我解决了问题，也在此和朋友们分享解决的经验。

  如果你是一个blogger，并且你的博客系统是基于WordPress加上IIS7，那么我的这篇文章一定会对你有所帮助的。在解决了那些非常麻烦的问题后，我终于成功的在我的博客上加装了WP-Super-Cache插件。让我们用这个插件来加速我们的博客吧！

  具体怎么做呢？来看看我的步骤。

  安装和配置部分

  通过10步就可以完成配置：

  1. 下载这个插件（这里就不多废话了，后台有插件搜索的地方，直接下载即可）

  2. 将插件解压到 /wp-content/plugins/wp-super-cache/ 目录下

  3. 将 /wp-content/plugins/wp-super-cache/wp-cache-phase1.php 文件复制到
  /wp-content/advanced-cache.php

  4. 打开 /wp-content/plugins/wp-super-cache/wp-cache.php 文件，找到如下内容：
  [sou­r­ce­code language=“php”]function wp_cache_check_link() { glo­bal $wp_cache_link, $wp_cache_file;[/sourcecode]
  将它们替换成 [sou­r­ce­code language=“php”]function wp_cache_check_link() { glo­bal $wp_cache_link, $wp_cache_file; if ( file_exists($wp_cache_link) ) return true; else { echo “advanced-cache.php does not exist”; echo “Create it by copying $wp_cache_file to $wp_cache_link on your server”; return false; } [/sourcecode] Read the rest of this entry »

  • 

• Speed up your WordPress Blog on IIS 7 by using WP-Super-Cache

  Date: 2009.04.26 | Category: WordPress | Response: 1

  Since I moved my Blog to an IIS 7 server outside main­land China, I found it became ter­ri­bly slow than before on a LAMP (Linux+Apache+MySQL+PHP) Server. I tried to find out why my site was so slow run­ning on IIS and wan­ted to change this situation.

  Tur­ning all posts and pages into sta­tic html files is a good way to ext­re­mely speed up my blog. It is common to install a plu­gin named “WP-Super-Cahce” for the action. But unfo­r­tu­na­tely, there was always some­thing wrong in my WP and that plu­gin doesn’t work at all times. I fixed the pro­blem today and want to share my expe­rience with you all. Let’s start!

  If you are a blo­g­ger and your blog is based on an IIS 7 envi­ron­ment, I think this arti­cle maybe helpful for you. I succe­ssfu­lly insta­lled WP-Super-Cache plu­gin on my IIS 7 website after solving some ugly pro­blems. Let’s make our blog faster and faster runing on Win­dows Server!

  Install and Con­fi­gure WP-Super-Cache

  There are 10 easy steps to get cached con­tent on your IIS or Apa­che server under Windows:

  1. Down­load plugin.

  2. Ext­ract it so you have a /wp-content/plugins/wp-super-cache/ dire­ctory with all the files (like wp-cache.php) in there.

  3. Copy /wp-content/plugins/wp-super-cache/wp-cache-phase1.php to
      /wp-content/advanced-cache.php

  4. Open up /wp-content/plugins/wp-super-cache/wp-cache.php and locate this:
      [sou­r­ce­code language=“php”]function wp_cache_check_link() { glo­bal $wp_cache_link, $wp_cache_file;[/sourcecode]
      Replace that with [sou­r­ce­code language=“php”]function wp_cache_check_link() { glo­bal $wp_cache_link, $wp_cache_file; if ( file_exists($wp_cache_link) ) return true; else { echo “advanced-cache.php does not exist”; echo “Create it by copying $wp_cache_file to $wp_cache_link on your server”; return false; } [/sourcecode]

  6. Add the follo­wing rew­rite rule to the web.config file loca­ted at the root folder of Wor­dP­ress site. Make sure that the “WP Super Cache” rule is before the Wor­dP­ress rule for pre­tty per­ma­links. Typi­ca­lly the <rew­rite> section will look as below:

  <rew­rite>
  <rules>
    <rule name=“WP Super Cache” stopProcessing=“true”>
      <match url=”^(\d{4})/(\d{2})/(.+?)/?$” ignoreCase=“false” />
      <con­di­tions>
        <add input=”{REQUEST_METHOD}” negate=“true” pattern=“POST” ignoreCase=“false” />
        <add input=”{QUERY_STRING}” negate=“true” pattern=”.*=.*” ignoreCase=“false” />
        <add input=”{QUERY_STRING}” negate=“true”
                  pattern=”.*attachment_id=.*” ignoreCase=“false” />
        <add input=”{HTTP_COOKIE}” negate=“true”
                 pattern=”^.*(comment_author_|wordpress|wp-postpass_).*$” ignoreCase=“false” />
        <add
          input=”{DOCUMENT_ROOT}\wp-content\cache\supercache\{HTTP_HOST}\{R:1}\{R:2}\{R:3}\index.html”
          matchType=“IsFile” />
      </conditions>
      <action type=“Rewrite”
           url=“wp-content/cache/supercache/{HTTP_HOST}/{R:1}/{R:2}/{R:3}/index.html” />
    </rule>

    <rule name=“Wordpress Pre­tty Per­ma­links” patternSyntax=“Wildcard”>
      <match url=”*” />
      <con­di­tions>
        <add input=”{REQUEST_FILENAME}” matchType=“IsFile” negate=“true” />
        <add input=”{REQUEST_FILENAME}” matchType=“IsDirectory” negate=“true” />
      </conditions>
      <action type=“Rewrite” url=“index.php” />
    </rule>
  </rules>
  </rewrite>

  Note: this rule exa­mple is con­fi­gu­red to work with Wor­dP­ress per­ma­links that use “Month and name” for­mat, e.g. http://wordpress/index.php/2008/12/sample-post/. If you use any other per­ma­link for­mat then the rule will need to be adju­sted for that.

  If you are using per­ma­link style like “/%post_id%.html”, please use the follo­wing configuration:

  <rule name=“WP Super Cache” stopProcessing=“true”>
      <match url=”^([0–9]+).html$” ignoreCase=“false” />
      <con­di­tions>
          <add input=”{REQUEST_METHOD}” negate=“true” pattern=“POST” ignoreCase=“false” />
          <add input=”{QUERY_STRING}” negate=“true” pattern=”.*=.*” ignoreCase=“false” />
          <add input=”{QUERY_STRING}” negate=“true”
                    pattern=”.*attachment_id=.*” ignoreCase=“false” />
          <add input=”{HTTP_COOKIE}” negate=“true”
                   pattern=”^.*(comment_author_|wordpress|wp-postpass_).*$” ignoreCase=“false” />
          <add
            input=”{DOCUMENT_ROOT}\wp-content\cache\supercache\{HTTP_HOST}\{R:1}.html\index.html”
            matchType=“IsFile” />
      </conditions>
      <action type=“Rewrite” url=“wp-content/cache/supercache/{HTTP_HOST}/{R:1}.html/index.html” />
  </rule>

  In addi­tion, if you want to cache your front page like index.php, please add an rule in the front of “WP Super Cache” rule, just like this:

  <rule name=“WP Super Cache Index Page” stopProcessing=“true”>
      <match url=“index.php” ignoreCase=“false” />
      <con­di­tions>
          <add input=”{REQUEST_METHOD}” negate=“true” pattern=“POST” ignoreCase=“false” />
          <add input=”{QUERY_STRING}” negate=“true” pattern=”.*=.*” ignoreCase=“false” />
          <add input=”{QUERY_STRING}” negate=“true”
                    pattern=”.*attachment_id=.*” ignoreCase=“false” />
          <add input=”{HTTP_COOKIE}” negate=“true”
                   pattern=”^.*(comment_author_|wordpress|wp-postpass_).*$” ignoreCase=“false” />
          <add
            input=”{DOCUMENT_ROOT}\wp-content\cache\supercache\{HTTP_HOST}\index.html”
            matchType=“IsFile” />
      </conditions>
      <action type=“Rewrite” url=“wp-content/cache/supercache/{HTTP_HOST}/index.html” />
  </rule>

  7. Add the follo­wing line into the wp-config.php file above the “require_once(ABSPATH.’wp-settings.php’);” line:

  define( ‘WP_CACHE’, true );

  8. Log into your dashboard and ena­ble WP Super Cache in the Plu­gins page.

  9. Go to the WP Super Cache options page and ena­ble caching.

  10. If you have mod_gzip, mod_deflate, or IIS dyna­mic con­tent caching ena­bled, make sure you don’t ena­ble Super Cache gzip because it’s already being done on the server level (which is better, anyway! )

  After that 10 steps, you may find your blog become faster than before. Please open a post and see the sou­rce file code. If that plu­gin is suce­ssfu­lly run, you may find the follo­wing con­tents at the bottom of the sou­rce code:

  <!– Dyna­mic Page Served (once) in x.xxx seconds –>

  If you see that message, Congratulations!

  Make it rea­lly works for you if you meet extra problems

  But in some cir­cu­mstance, you will get fai­led. Because some of your plu­gin prevent WP-Super-Cache from working.

  You may see that message instead:

  <!– Page not cached by WP Super Cache. No clo­sing HTML tag. Check your theme. –>

  Don’t worry about your theme, it may not your theme’s fault. If you’ve seen “</html>” in that sou­rce code page, it should be some pro­blems cau­sed by one or more of your other plu­gins. They may have some conflicts!

  For my site, I found my ano­ther plu­gin named Sta­tP­re­ssCN is con­fli­cted with WP-Super-Cache. You may try to dea­ctive all your plu­gins and active them one by one while seeing the html sou­rce code to check which plu­gin is not fit for your WP-Super-Cache. After fin­ding out the con­fli­cts, you can decide which plu­gin you need more and give up another.

  Try to do that and enjoy your faster blog site and your blo­g­ger life!

  –Paul

   

  Some refer­rence for my article:

  • Getting Wor­dP­ress Super Cache to Run on a Win­dows (IIS or Apa­che) Server
  • Speed up Wor­dP­ress on IIS 7.0
  • WP-Super-Cache not Caching
  • 

• 博客搬家海外

  Date: 2009.03.19 | Category: In My Opinion | Response: 1

  “尊敬的用户[吕鹏飞]，很遗憾的通知您，您的ICP备案申请(xxxx)，经[北京市通信管理局0]审核，不符合备案要求，现退回修改，原因请登陆系统查询。”

  原因经过查看，竟然是因为通信地址里面出现了字符。而我家的门牌号确实含有字母，这点是无法避免的，这个退回的理由也让我感到非常意外。

  这是发生在几分钟之前的事情，我刚刚收到了“关于ICP备案信息不符合备案要求退回修正的通知”。这封信也确实说明，博客搬家是一个正确的选择。

  从头开始说起吧。一个月前，2月初的样子，由于维护自己的网站，我进入到了我的域名和主机提供商的后台服务系统中，但突然却进不去了。我看了看日子，才2月，而我们的主机要到5月才满一个周期。我马上和主机服务商联系。不久后，被告之我某某、某某、某某域名以及主机都未备案，后台已经被停止。当时自己十分气氛。虽然我知道要备案，但是对于消费者，怎么着也得有个知情权吧，您要让我备案，倒是给我发个邮件或者打个电话告诉我一下啊。这倒好，直接把后台毙了，让我备案。

  本来对我的主机提供商的服务还是很满意的，但是就这么一件事情，让我决定慢慢放弃这家。

  随后我就开始了繁琐的备案过程。备案要填的东西很多，要你知道的也很多。比如，你的主机在哪个省、接入商是谁、接入方式是什么、IP是什么；你的域名从哪儿注册的、注册商是谁、是否以盈利为目的；你的身份证号、手机号、通信地址、办公电话、真实姓名……

   
  烦人的填写过程

  我备个案填写个信息，比我配置一个wordpress、搭建一个小型网站的时间都长。然后还联系了我的服务提供商，才终于搞定了所有内容。时间定格在2月19日17:02。

  时隔一个整月后的今天，3月19日，备案终于下来了。催着你填写，封你后台，但人家官方就能用整整一个月去审批。然后结果还来个通信地址不能包含字符为名退回。。您说说，这件事情，从始至终，能不让人气愤吗？

  我爱我的祖国，爱我们广阔富饶的土地，更爱我们的家园。但我却不希望我的国家这样子做事情，繁琐、复杂、苛刻，这也太不以人为本了。登记备案的同时，我们消费者的利益被放在了哪里？我们的权益得到保证了吗？

  所以自从开始备案，我就把我的空间从原来的那个提供商搬了出来。搬到了另外一个国内的，是Unix主机，支持rewrite，承载wordpress非常好。但是这个破服务商却没法从后台连接wordpress.com，插件没法升级，我的spam系统也没法生效，活生生地看着自己的博客被垃圾留言所充斥，三天时间后台竟然堆积了600多条spam。更客气的是，还没去两天，也让备案了。不备案就封。不过这边还好点，还知道给我先发封邮件。所以我很客气的告诉他，我的网站正在备案，不能再继续处理的。至此备案问题才终于缓和了一点。

  前两天，在网上搜索。没抱什么太大的希望，选择了关键词asp.net 3.5 host，结果找到了现在的服务器提供商。我和Jerry商量后，把服务器移居海外的大主意就此敲定了。虽然是美金支付，但实际价格比国内的还是便宜，而且限制要少的多。我们一拍即合，购下了这个海外服务，也开始了我们的海外之旅。

  最开始还是遇到很多问题的。比如我们的白天是他们的晚上，所以我们的问题他们一般都要隔夜才能回复。然后服务器后台也出现很多503错误。不过他们告诉我们这是由于后台系统最新版本不够稳定，发现一些bug造成的。所以我们虽然比较反感这个问题，但是也还是可以接受的。

  后台确实无比强大。ASP.net 1.1/2/3/3.5，都支持；php、python、cgi，全都支持。并且还是IIS 7.0，在原来服务器上无法实现的IIS中php无法rewrite的问题，也在IIS 7.0 + CGI Appli­ca­tion or FastCGI Application中解决了！而且速度很快！非常不错。

  所以到目前为止，备案还要继续，我不想放弃我们应有的那份权益。博客移居海外，彻彻底底地成为了身在他乡心系祖国的一份子。我想，如果有一天我的海外博客被封了，我就准备将博客服务外国人了。那样的话，其实损失的不仅仅是我自己，而是我们的国家，因为和我一样的人会有很多很多。但我真不希望这样，我是一个中国人，我应该为自己的国家做出自己的贡献。

  为了保险起见，我申请了新的域名。原来的iamlv.com还是给我的个人邮箱使用吧，如果这个域名封了，很多邮件就没法收到了，会耽误事情的。PriorMind.com高调一些，IamLV.com低调一些吧。何况iamlv.com还是在国内注册的，非常危险。过两天考虑一下是否transfer到国外。不过据说godaddy那边park的域名，也有随时被封的危险。太可怕了，我们仿佛置身于一个无形的地雷阵中，不知道啥时候会踩到被雷到。

  希望我们的政府不要抹杀和我一样的青年人的梦想，做事情再透明些，以人为本些，开放些，为我们营造一个更好的言论环境和网络环境吧！

  • 

• Wordpress数据库转移网址变换的方法

  Date: 2009.03.19 | Category: WordPress | Response: 2

  在将数据从旧的数据库转移到新的数据库的过程中，发现一点问题，那就是所有图片还是链接到过去的域名上，而且是绝对路径。这个怎么办呢？通过简单分析wor­dp­ress数据存储结构，得出如下结论：

  1、存储日志文件的table是：prefix_posts。其中，prefix是在安装wordpress选择的数据库前缀名；

  2、在prefix_posts这个表中，有两个列与原先的域名有关，一个是：post_content，这个用来存储文本内容，也就是日志的html代码；另一列是guid，存储唯一识别码（跟网址绝对路径有关）。

  3、我们要执行在mysql数据库中替换字符串的过程。其sql语句如下：

  update TABLE set COLUMN=replace(COLUMN,‘STRING1’,‘STRING2’)
  其中，TABLE代表要操作的表格，COLUMN是要替换的列名，执行将STRING1替换成为STRING2

  对于本例我们应该如下做：

  update prefix_posts set prefix_content=replace(post_content,‘original_url_address’,‘present_url_address’)

  update prefix_posts set guid=replace(guid,‘original_url_address’,‘present_url_address’)

  这样，就会发现存储在/uploads里面的内容可以被新的地址所调用了。转移网站成功！

  • 

• 界面改版

  Date: 2008.07.14 | Category: WordPress | Response: 0

  今天将我的WordPress所使用的主题：Utom 进行了一个小小的改造，将宽度由原来的780px变成了1000px，符合了大多数现在电脑和笔记本的浏览习惯。Sohu和Sina都改版了，我也改。。。

  嗯，改动不大，style.css文件改了几个参数，几个图片调整了宽度。看起来好多了

  其实还是很喜欢这款主题的，简洁清晰。另外，我喜欢绿色，大自然的颜色。

  • 

• WordPress在IIS下对自定义链接及标签tag中文显示完美支持 终极解决方案

  Date: 2008.06.24 | Category: WordPress | Response: 0

  WordPress在2.3版本以后，支持了标签（Tags）。同时，为了能够更友好地显示链接地址，在WP中我们经常将Permalinks改作更好一点的标签：

  

  但是在IIS下，不能隐藏index.php，php不能完全发挥它的效能。只有在Apache中，才会可以产生形如：http://www.techwork.cn/2008/11/12/thisone/ 这样的地址链接。IIS有一定的缺陷，这不可避免，出现index.php也能忍。但是不支持中文的postname，不支持中文tags，则是一个很大的问题。

  一直以来受这个问题的困扰，直到今天解决了这个问题，我的tags才终于派上了用场。

  在修改这个问题的时候，我参考了两篇文章：
  http://www.lovemojo.cn/index.php/others/wordpress-rewrite-1/
  http://www.bolarn.com/index.php/2008/01/26/52/

  建议大家先阅读这两篇文章。第一篇文章，从一个角度解决问题，即将所有地址rewrite成/?tags=xxx 这样的样子，即取消了自定义链接这个功能。但是这样我们就不能使用这种显式的链接方式了，治标不治本，不可取。

  第二种情况，较为完美地解决了问题。在IIS中，querystring中的中文不会被转换，而处于URL地址中的部分则会被转换成GB2312或是GBK编码。第二种方法的原理就是将这部分被转化了的地址再转换回去。但是，在我部署的时候，发现他提到的函数mb_convert_encoding()我的主机并不支持。搜索网络上的文章，发现iconv()这个函数也可以使用，但非常不幸，我的主机依然不支持。What a pity! 虽然官方上说，php4.0.3以后就可以支持这两个函数了；虽然我的主机的php版本是4.4.7，但是依然没用，没有这个函数，就无法转换。

  既然知道了问题所在，我们能不能自己完成这个转换过程呢？php4.0.3以前，是如何做的呢？我继续搜索，寻找问题的答案。最后，我发现了一些自己写的将gb2312的文字转化成utf-8编码的方法。选取了其中最好的一个，加入到我的WP中。新建了一个gb2312utf8.php文件，里面存放了gb2312utf8这个类。在class.php中调用这个类的方法就可以了，可以实现上述提到的功能。

  最终将问题解决了，还是很不容易的。但是最值得高兴的，是发现了问题的所在。希望对和我一样，php的主机不支持mb_convert_encoding()和iconv()两个函数的朋友们提供一些帮助。

  文件下载地址：http://www.PriorMind.com_file/php中文tags完美解决方案.rar

  • 

• Hello World

  Date: 2008.04.23 | Category: In My Opinion, WordPress | Response: 0

  WordPress推出2.5版了，这版一下子改变了很多，特别是界面方面。后台的Dashboard漂亮了许多，非常喜欢。也赶了时髦，将自己的博客系统升级到了WP2.5。不过升级完了以后，更新数据库都一切OK，但就是无法再进入后台了。SIGH.…..

  遂一狠心，将原来的博客系统删除了，反正倒是也没怎么建好。重新开始吧，以前的就当作是回忆了！

  Hello World!

  Wor­dP­ress has relea­sed the ver­sion of 2.5, which has chan­ged a lot, espe­cia­lly User Inter­face. Dashboard behind the website looks like more pre­tty than ever, and I like it very much. To be a swin­ger, I upg­ra­ded my blog system to WP2.5. Upda­ted data­base works well, but unfo­r­tu­na­tely I could not log into the backstage. SIGH.…..

  To be ruthless, I dele­ted my for­mer blog system. It doesn’t per­form well yet. Let’s restart, from now. The previous blog would be my part of recollection.

  Hello World!

  • 

2008.11.Trip-of-GuangXi ASP.net C++ China Chrome css dotNet FCGuoAn Firefox Football gmail IBM IE IIS IT Association Joke Microsoft music mysql NLP Nokia ntfs NumPy OpenSolaris open source Open Team php pidgin PKUSS Python Python Challenge qq Samba SciPy Learning shell solaris SQL SUN Thunderbird Travel web host Win 7 WordPress X11 zfs

WP Cumulus Flash tag cloud by Roy Tanck and Luke Morton requires Flash Player 9 or better.