<?xml version="1.0" encoding="UTF-8"?> <rss
version="2.0"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:wfw="http://wellformedweb.org/CommentAPI/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
><channel><title>群英汇博客 &#187; 博客软件</title> <atom:link href="http://blog.ossxp.com/category/blog/feed/" rel="self" type="application/rss+xml" /><link>http://blog.ossxp.com</link> <description></description> <lastBuildDate>Wed, 14 Sep 2011 03:52:03 +0000</lastBuildDate> <generator>http://wordpress.org/?v=2.9.2</generator> <language>en</language> <sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>1</sy:updateFrequency> <item><title>将博客整合到维基</title><link>http://blog.ossxp.com/2010/02/514/</link> <comments>http://blog.ossxp.com/2010/02/514/#comments</comments> <pubDate>Tue, 09 Feb 2010 08:19:44 +0000</pubDate> <dc:creator>蒋 鑫</dc:creator> <category><![CDATA[博客软件]]></category> <category><![CDATA[新闻]]></category> <category><![CDATA[维基]]></category> <category><![CDATA[wordpress]]></category><guid
isPermaLink="false">http://blog.ossxp.com/?p=514</guid> <description><![CDATA[通过 AJAX 技术，我们实现了将博客整合到维基当中。在群英汇的网站首页，你会发现新闻中的头几条来自于博客，你也会发现在首页的右侧的面板中显示6条最新的博客，点击标题即可查看相关博文。
显示三条新闻类别的博客条目的Wiki语法为：
&#60;&#60;jQuery(wordpress,query,http://blog.ossxp.com/rpc/,3,id=.blog-news,cat=12,showdate=prefix)&#62;&#62;
{{{#!wiki blog-news
[[http://blog.ossxp.com/&#124;博客加载中]]...
}}}在右侧面板中显示6条非新闻类别的博客条目的Wiki语法为：
&#60;&#60;jQuery(wp,query,http://blog.ossxp.com/rpc/,6,id=.blog-latest,cat=-12)&#62;&#62;{{{#!wiki blog-latest
[[http://blog.ossxp.com/&#124;博客加载中]]...
}}}关于针对 wordpress 的 jQuery  宏的参数说明：第一个参数是 wp 或者 wordpress，即启用 wordpress 相关的 AJAX 调用
第二个参数是 wordpress AJAX 的函数名称，如 query。可选的函数有 query, latest 等
第三个参数是 wordpress base URL。例如： http://blog.bj.ossxp.com/rpc/
第四个参数是 返回的条目个数
参数: cat=12 ，是选择分类12 (即 news)的相关博客。如果数字是负数，则取反
参数 showdate，含义是在标题中显示博客日期。showdata=prefix，在标题前添加日期，showdata=suffix，则在标题后添加日期]]></description> <wfw:commentRss>http://blog.ossxp.com/2010/02/514/feed/</wfw:commentRss> <slash:comments>6</slash:comments> </item> <item><title>wordpress日志评论时间错误问题</title><link>http://blog.ossxp.com/2010/01/238/</link> <comments>http://blog.ossxp.com/2010/01/238/#comments</comments> <pubDate>Thu, 14 Jan 2010 13:49:19 +0000</pubDate> <dc:creator>雷 魏魏</dc:creator> <category><![CDATA[博客软件]]></category> <category><![CDATA[沟通系统]]></category> <category><![CDATA[wordpress]]></category> <category><![CDATA[日志留言]]></category> <category><![CDATA[时间问题]]></category><guid
isPermaLink="false">http://blog.ossxp.com/?p=238</guid> <description><![CDATA[也许这个问题在你的服务器中不是常见的，但是偶然间还是会碰到的，它就像定时炸弹一样，说不定
下一秒钟在你的服务器上爆发了。
关于这个问题的解决过程真的不敢妄自菲薄，我先把问题叙述一下。这个是我们错误显示的截图：当你看到那个醒目的&#8221;大约－1年&#8221;时，不知道你作何敢想。原来鼎鼎大名的Wordpress也有这样的
错误，其实细查下来才会发现这是当前主题和Wordpress内部函数共同酿成的苦果。
有了以往查找错误的经验，先查找“大约-1年前”出现的变量的地址，然后就可以按图索骥了，根
据变量你很快就能定位到“主题名/functions.php“文件中，在functions.php下的timeSince函数中
有这样一个变量：$since,
$since = current_time('timestamp',$wp_time_offset ? get_option('gmt_offset') : 0) - $startTimestamp;
它的值为当前时间－发表评论的时间，你可以打一下这个
current_time('timestamp',$wp_time_offset ? get_option('gmt_offset') : 0)
,结果显示那条错误的评论和那些正确的评论取出的当前时间都是正确的，说明问题还不在于此。
继续往下找，在真正输出时间的地方，该主题又对发表评论的时间进行了处理，如下：
comment_date));?&#62;
，
用echo命令输出的信息表明$comment-&#62;comment_date所取出的时间并没有错误，错误就发生
在strtotime,这个PHP内部函数上，PHP内部函数也会出问题？我的第一个反应就是这样。
我们看一下PHP的这个函数，下面是对该函数的说明：
The function expects to be given a string containing a US English date format
and will try to parse that format into a Unix timestamp (the number of seconds
since January 1 1970 00:00:00 UTC), relative to the timestamp given in now ,
or the current <a
href="http://blog.ossxp.com/2010/01/238/" class="more-link">阅读全部内容 &#187;</a>]]></description> <wfw:commentRss>http://blog.ossxp.com/2010/01/238/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item><title>Wordpress中文昵称问题解决方法小结</title><link>http://blog.ossxp.com/2010/01/180/</link> <comments>http://blog.ossxp.com/2010/01/180/#comments</comments> <pubDate>Tue, 12 Jan 2010 13:59:30 +0000</pubDate> <dc:creator>雷 魏魏</dc:creator> <category><![CDATA[博客软件]]></category> <category><![CDATA[wordpress]]></category> <category><![CDATA[中文昵称]]></category><guid
isPermaLink="false">http://blog.ossxp.com/?p=180</guid> <description><![CDATA[我的上一篇博客中大致介绍了Wordpress的基本工作原理，但是了解原理以后还有个问题一直困
扰着我，我们的日志上面凡是使用了中文昵称的地方都不能被查询到。真的令人挺苦恼，Wordpress
不是不支持中文链接，象&#60;yourlink&#62;/category/中文链接就能很好地跳转，但&#60;yourlink&#62;/author/
中文链接为什么就是404的错误。
最好的文档还是代码，前提是你对Wordpress的工作原理有了一定的了解之后。
还得从Wordpress的调用说起。Wordpress中对页面请求，简言之就是对浏览器输入框中地址的处理
是由wp-include/classes.php来做的。classes.php中有一个main方法，我们都应该知道main方法对
整个程序的重要程度。我们再来看一遍main方法，
function main($query_args = '') {
$this-&#62;init();  --初始化环境
$this-&#62;parse_request($query_args);   --解析请求
$this-&#62;send_headers();  --发送头信息
$this-&#62;query_posts();  --查询日志
$this-&#62;handle_404();   --操作404(URL地址不存在)
$this-&#62;register_globals();  --注册全局变量
do_action_ref_array('wp', array(&#38;$this));
}
现在我阐述一下我的大概的思路，也为以后寻找类似问题提供一些参考。
(1)我主观上判断应该是parse_request对请求地址进行解析错误，导致解析后的地址链接与.htaccess
中的规则匹配不上，但是后来我使用了中文昵称和英文昵称两个不同的用户在parse_request中插入echo信息
和die(php中用来对当前程序进行终止)进行实验，得到的信息没有什么异样，我发现我错了。
(2)还是主观臆断的错误，我还是误以为错误的原因应该归咎于.htaccess中没有匹配的规则，只能匹配到
英文的地址链接，我找到用来显示昵称的代码，位于&#60;主题名&#62;/post.php中，它调用了get_author_posts_url
(get_the_author_ID())，你可以根据方法名查找到该方法的地址，它位于wp-includes/author-template.php
中，我发现原来用来显示的是昵称，因为我们资料中的昵称都是中文，所以显示的也是中文，我就把凡是涉及到
nicename的参数全部改成login,我想这次该行了，希望再次破灭。还是那个404错误。
这两次接连的打击让我逐渐清醒了方向，还是看代码吧，一点一点来。
既然解析请求的地方没有什么错误，下一步$this-&#62;send_headers()(发送头信息),查看函数后你就会发现该函数
只不过发送了文件头部的一些信息，与你要查找的post信息关联不大。
下一个，$this-&#62;query_posts()(查询日志),这个函数中调用的第一个$this-&#62;build_query_string()，建立
查询数据，继续echo、die,你会发现英文昵称和中文昵称在此处也没什么异常。继续寻找，也许就在下一个，
$wp_the_query-&#62;query($this-&#62;query_vars)，$wp_the_query是已经初始化好的全局变量，在WP_Query
类中进行初始化的，WP_Query位于wp-include/query.php中，查找WP_Query函数中的function &#38;query()
方法，我再次异想天开地认为这回应该近了，但是现实就是现实，我一点点地读，然后把echo、die放到不同的
位置用两种昵称的用户进行实验，结果依旧是看不出什么问题。
继续，function &#38;query($query)中的第二个调用，$this-&#62;get_posts()，查找author_name你会发现，原来
根据页面上的用户名调用日志的那一段就在此，
$q['author'] = $wpdb-&#62;get_var("SELECT ID FROM $wpdb-&#62;users WHERE user_nicename='".$q['author_name']."'");
我终于找到了寻觅了好久的那个nicename,当你用echo、die放到这一句上面进行实验时，你会发现，这次中文昵称
和英文昵称有区别了，使用中文昵称时查找到的$q['author'] ，也就是Wordpress调用数据库中数据的用户ID
是空的。OK，锁定目标：$q['author_name'] = sanitize_title($q['author_name'])，
原来它把自己搞糊涂了，赋给$q['author_name']的参数竟然是用urlencode转换过的内部规则，在此处加上urldecode就行了。
从这次超级费时的找bug过程中，我发现什么事也不能主观臆断，一定要拿出实实在在的数据。还有，代码是最好的
文档，当你了解了最基本的原理后，慢慢看，慢慢就会看懂的。
]]></description> <wfw:commentRss>http://blog.ossxp.com/2010/01/180/feed/</wfw:commentRss> <slash:comments>2</slash:comments> </item> <item><title>wordpress工作原理</title><link>http://blog.ossxp.com/2010/01/166/</link> <comments>http://blog.ossxp.com/2010/01/166/#comments</comments> <pubDate>Tue, 12 Jan 2010 02:27:41 +0000</pubDate> <dc:creator>雷 魏魏</dc:creator> <category><![CDATA[博客软件]]></category> <category><![CDATA[wordpress]]></category><guid
isPermaLink="false">http://blog.ossxp.com/?p=166</guid> <description><![CDATA[WP初始化的过程：当你输入&#60;yourlink&#62;/wordpress对wordpress进行初始化时，wordpress默认会找
根目录下的index.php页面，看一下index.php页面。
&#60;?php
define('WP_USE_THEMES', true);
/** Loads the WordPress Environment and Template */
require('./wp-blog-header.php'); ---把/wp-blog-header.php包含进来
?&#62;
你会发现，它会去调用根目录下的wp-blog-header.php，我们继续看wp-blog-header.php。
&#60;?php
if ( !isset($wp_did_header) ) {
$wp_did_header = true;
require_once( dirname(__FILE__) . '/wp-load.php' );  ---加载wp-load.php
wp();  ---加载function WP();
require_once( ABSPATH . WPINC . '/template-loader.php' );   ---加载模板文件
}
?&#62;
通过wp-load.php，wordpress先后把wp-config.php, wp-setting.php,classes.php,fucntions.php，
query.php等文件加载进来,并建立了三个全局变量,$wp_the_query,$wp_rewrite和$wp ,分别为WP_Query,
WP_Rewrite和WP类的实例。然后,wp-blog-header执行wp()函数,并通过其调用$wp所属WP类的main方法,
这个方法又调用一系列方法,但最重要的是parse_request方法, WP从这里开始解析URL并建立主循环。
我们看一下wordpress的主方法：
function main($query_args = '') {
$this-&#62;init();  --初始化环境
$this-&#62;parse_request($query_args);   --解析请求
$this-&#62;send_headers();  --发送头信息
$this-&#62;query_posts();  --查询日志
$this-&#62;handle_404();   --操作404(URL地址不存在)
$this-&#62;register_globals();  --注册全局变量
do_action_ref_array('wp', array(&#38;$this));
}
这基本上就是wordpress初始化时的信息。
下面就讨论一下当我们设置自定义的永久链接时，wordpress的运作过程。
当我们使用了自定义的永久链接的时候，wordpress会自动生成.htaccess文件，并且在这个文件中生成相
对应于永久链接的匹配规则，在wordpress/wp-includes/rewrite.php中有针对.htaccess文件的重写规则，其
中$use_verbose_rules参数规定了输出信息的详尽和简约，默认的情况下为false。输出的信息比较简单，
如下
# BEGIN WordPress
&#60;IfModule mod_rewrite.c&#62;
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php <a
href="http://blog.ossxp.com/2010/01/166/" class="more-link">阅读全部内容 &#187;</a>]]></description> <wfw:commentRss>http://blog.ossxp.com/2010/01/166/feed/</wfw:commentRss> <slash:comments>4</slash:comments> </item> <item><title>TSE 表情插件的改进：错误表情替换的解决方案</title><link>http://blog.ossxp.com/2010/01/125/</link> <comments>http://blog.ossxp.com/2010/01/125/#comments</comments> <pubDate>Sat, 09 Jan 2010 10:53:46 +0000</pubDate> <dc:creator>蒋 鑫</dc:creator> <category><![CDATA[博客软件]]></category> <category><![CDATA[php]]></category> <category><![CDATA[regex]]></category> <category><![CDATA[wordpress]]></category> <category><![CDATA[正则表达式]]></category><guid
isPermaLink="false">http://blog.ossxp.com/?p=125</guid> <description><![CDATA[TSE 插件全称：Tango Smileys Extended，是为 WordPress 提供表情扩展的一个插件。可以提供在博客编辑／评论编辑时通过点击插入表情（CTI）功能，并且将可用表情由内置的18个增加到202个。
错误的TSE表情扩展
这个插件在表情扩展时，会引起副作用，例如在王胜刚刚创建的Rails多语言支持的博文中，就遇到问题。
将
:onchange =&#62; 'this.form.submit()' %&#62;
扩展为
:o nchange =&#62; 'this.form.submit()' %&#62;
难道要因此禁用这个好用的插件？如果是商业软件可能只能如此，但是WP是开源软件，TSE插件也是开源的，为什么不自己解决呢？开源软件，让我们有机会完善它
最终定位在TSE代码 “tse-magic.php&#8221; 中，相关代码
10 // Function to swap smiley shorthand with the actual smiley images
11 function tse_switcher( $tse_content ) {
13   $tse_smileys = get_tse_smileys();
17     $tse_smiley_match[] = "#{$tse_smileys[$i][0]}#i";
25       $tse_content_split = preg_replace( $tse_smiley_match, $tse_img_full, $tse_content_split );
问题就处在上面代码的第17行。$tse_smiley_match[] 数组中保存的就是各个表情符号的匹配正则表达式，如果能够正确修改这个表达式，就能够避免错误的表情替换。
一开始直接在正则表达式的两边加上 \b 以匹配单词边界，但是居然没有起到作用！！！
修改如下：
17     $tse_smiley_match[] = "#\b{$tse_smileys[$i][0]}\b#i";
难道是 PHP 的正则表达式不支持 \b 作为单词边界判断？要是PHP有像是Python或者Ruby的调试SHELL就好了，还是用老土的办法，在脚本中用 var_dump来看看情况。
最终的解决方案
最终发现，要在不同的情况选择\b（单词边界）或者\B（非单词边界）。如果匹配的字串本身是字母或者数字，则使用\b来匹配单词边界，但是如果匹配字串本身就是符号则用\b就错了，而应该使用\B。
下面是群英汇对 <a
href="http://blog.ossxp.com/2010/01/125/" class="more-link">阅读全部内容 &#187;</a>]]></description> <wfw:commentRss>http://blog.ossxp.com/2010/01/125/feed/</wfw:commentRss> <slash:comments>2</slash:comments> </item> <item><title>CoSign-SSO插件已提交到Subversion版本库及github</title><link>http://blog.ossxp.com/2010/01/15/</link> <comments>http://blog.ossxp.com/2010/01/15/#comments</comments> <pubDate>Wed, 06 Jan 2010 11:56:40 +0000</pubDate> <dc:creator>蒋 鑫</dc:creator> <category><![CDATA[Git]]></category> <category><![CDATA[Subversion]]></category> <category><![CDATA[博客软件]]></category> <category><![CDATA[版本控制]]></category> <category><![CDATA[wordpress]]></category><guid
isPermaLink="false">http://blog.ossxp.com/?p=15</guid> <description><![CDATA[群英汇开发了 CoSign-SSO 插件，以便将博客整合到群英汇的统一认证架构中。群英汇的员工，直接拥有博客帐号，并能够撰写博客；
任何在群英汇注册的用户 ，同时拥有博客相应帐号，默认权限为subscriber。CoSign SSO 插件功能是：为 WordPress 增加了两个新的认证方式：单点登录认证及LDAP认证。其中单点登录认证是此插件开发的主要目的，LDAP认证只不过是副产品。
我们已经将该插件提交到 WordPress，有需要集中认证的用户，可以试用本插件插件首页：http://wordpress.org/extend/plugins/cosign-sso/
WordPress官方代码库:  tsvn:http://plugins.svn.wordpress.org/cosign-sso/trunk/
群英汇在 github 上的代码库： http://github.com/ossxp-com/&#8230;截屏图：单点登录的管理员配置界面重要提示：当插件配置错误，导致无法登录时，提供一个简单的回退方法：在 cosign-sso 插件目录下，创建一个空文件名为 FALLBACK，即可完全禁用单点登录，使用缺省的登录方式；
在 cosign-sso 插件目录下，在文件 FALLBACK 中写入内容 LDAP，回退到LDAP认证方式。这在单点登录URL改变时非常有用；]]></description> <wfw:commentRss>http://blog.ossxp.com/2010/01/15/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item><title>WordPress插件编程资源列表</title><link>http://blog.ossxp.com/2010/01/12/</link> <comments>http://blog.ossxp.com/2010/01/12/#comments</comments> <pubDate>Wed, 06 Jan 2010 11:23:42 +0000</pubDate> <dc:creator>蒋 鑫</dc:creator> <category><![CDATA[博客软件]]></category> <category><![CDATA[wordpress]]></category><guid
isPermaLink="false">http://blog.ossxp.com/?p=12</guid> <description><![CDATA[插件开发参考资料：如何写一个插件
如何为插件增加管理员面板
新皮肤/主题开发
API参考手册 （花几分钟，大概浏览一下即可，切勿深究！因为最好的文档就是代码本身）
PHP代码规范我看到的最有启发的一个相关博文：10种最常见插件编程错误这10个错误涵盖了代码规范、插件卸载、插件本地化、以及安全性等诸多方面，言简意赅，非常实惠。
汉化可以参考：WordPress本地化
Theme 和插件的本地化]]></description> <wfw:commentRss>http://blog.ossxp.com/2010/01/12/feed/</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item><title>博客软件的选型：typo 还是 wordpress</title><link>http://blog.ossxp.com/2010/01/6/</link> <comments>http://blog.ossxp.com/2010/01/6/#comments</comments> <pubDate>Wed, 06 Jan 2010 10:54:35 +0000</pubDate> <dc:creator>蒋 鑫</dc:creator> <category><![CDATA[博客软件]]></category> <category><![CDATA[typo]]></category> <category><![CDATA[wordpress]]></category><guid
isPermaLink="false">http://blog.ossxp.com/?p=6</guid> <description><![CDATA[群英汇很多同事都有写博客的习惯，对于我来说则是新鲜事。虽然我也在 05 年玩过一阵子的 WordPress，当时的感觉：就是玩具么，无法实现给每个人开一个独立的管理员帐号，只能是一个人管理（或少数人），其他人有编辑权限
当时的 WordPress 而且存在一个很明显的 bug，就是不能运行在我的64位的 Linux 中。虽然很容易找到问题所在：64位OS的字长和32位系统的字长不同导致的兼容性问题。所以，这次公司博客选型，一开始完全没有听从几位同事的意见，要选择一个MVC架构的博客。Typo是我们第一个选择：Typo是一个基于ROR（Ruby on Rails）架构的博客软件
代码库在：http://wiki.github.com/fdv/typo/ 。Smart choice, I love git very much!经过了几天的研究，完成了汉化，以及修改了几个bug 后，最终放弃了typo。除了功能少之外，typo 的博客编辑器非常不稳定，图片插入时灵时不灵。
选择了WordPress后，虽然有同事抱怨PHP写的代码太难维护了，逻辑和页面混杂在一起。为什么不用MVC？这让80后的程序员一头雾水，哈哈，这一点，我70后的有发言权，这是上个世纪的遗产。
PHP代码的历史问题，并没有阻碍 WordPress 成为博客软件的南坡腕(No.1)，主要因为插件设计的太灵活了，用户太广大了，皮肤太丰富了，定制太灵活了。
就是这样，世界上又一个WordPress博客诞生了。
]]></description> <wfw:commentRss>http://blog.ossxp.com/2010/01/6/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> </channel> </rss>
<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Minified using disk
Page Caching using disk (user agent is rejected)
Database Caching using disk

Served from: blog.ossxp.com @ 2012-02-09 17:24:52 -->
