Timothy's Space » plugin

WP-Reader-Wall 插件兼容 WordPress 3.0的修改

Timothy — Wed, 21 Jul 2010 17:02:00 +0000

wp-reader-wall是个有意思的插件，能在页面列出最近评论过的同学的头像。采用照片墙的方式，展示给用户，并且，头像的排序是根据评论的条数来排序的。
自从上次升级WordPress到3.0后，发现者插件没有正常工作了，索性禁用了此插件，也没时间仔细研究。今天特闲，所以决定拿这插件来研究研究。发现导致插件工作不正常的地方，是在插件的代码中定义select的sql语句，取读者数据的时候出了问题。把这句sql从插件中挖出来，在线上环境的mysql中执行了一下，果然取不到数据。刚开始，怀疑是sql语句的where条件的问题，后来逐个排除，没发现异常。最后，把重点放在了表名上，插件里面是用的一个全局变量：$tablecomments 来表示评论的表，索性直接替换成wp_comments试试，果然能取到数据了。看来$tablecomments在WordPress 3.0中失效了。去wordpress搜了一下，官方提到$tablecomments变量是不推崇的方式，可能已经被弃用。官方还建议了一些其他的全局变量的替代办法，如下：

这样，我们可以遵循官方的建议，在WP-Reader-Wall插件的select语句中，用$wpdb->comments替代原来的$tablecomments，这样，插件就能正常在WordPress 3.0下使用了。总结了一下，关于WordPress升级遇到的一些问题，可以直接查阅官方文档，还有就是参考每个版本之间的变化，包括变量定义，以及数据库改动。这才是最好，最直接的办法。

具体修改方法，在WP-Reader-Wall.php中，找到如下的代码:

^?View Code PHP

	$request = "SELECT count(comment_ID) comment_nums,comment_author, comment_author_email,comment_author_url FROM $tablecomments  where comment_date》'".$cur_time_span."' AND comment_type='' AND comment_approved=1 group by comment_author_email order by count(comment_ID) DESC ";

修改为：

^?View Code PHP

1
2
3

$request = "SELECT count(comment_ID) comment_nums,comment_author, comment_author_email,comment_author_url FROM ".$wpdb->comments.
" where comment_date>'".$cur_time_span."' AND comment_type='' AND comment_approved=1 group by comment_author_email order by count(comment
_ID) DESC ";

声明: 此Blog中的文章和随笔仅代表作者在某一特定时间内的观点和结论，对其完全的正确不做任何担保或假设
本站文章均采用知识共享署名-相同方式共享3.0 协议进行授权，除非注明，本站文章均为原创，转载请注明转自 Timothy's Space 并应以链接形式标明本文地址!

启用Lazy Load插件

Timothy — Sat, 19 Jun 2010 10:21:00 +0000

Lazy Load是基于jQuery的插件，能让页面的加载更加有序。在遇到图片比较多的页面的时候，就更能派上用场了。由于Blog加载了jQuery，正好也可以用上这个。

具体的设置，可以参考A-Shun同学的相关文章。启用后试用了一下，效果还不错。推荐有兴趣的同学也试试。

Blog插件更新

Timothy — Fri, 11 Jun 2010 17:03:00 +0000

很久没整理下Blog了，这次对Blog的一些插件做了一些调整和更新。
为了优化一下Blog访问速度和用户体验，正式启用了WP Super Cache插件。Nginx下需要单独在配置文件中设置一下，生效后，随便访问几个页面，看到Blog的wp-content/cache目录下生成文件了，表示成功启用了。设置的方式，可以参考久酷同学的一篇文章。
另外，貌似WP Super Cache插件和WP-PostViews插件有一些冲突，启用了WP Super Cache后，发现文章计数停住不动了，估计是因为生成了静态页面的关系。想了一下，俺的文章其实访问量并不是很大，显示一下文章访问量意义也不太明显，所以为了性能的缘故，暂时停用了WP-PostViews插件。网上貌似有关于这两个插件冲突的解决方法，不过今天暂时没时间细细研究了，空了再试试。
最后，替换掉一个评论者信息的插件Comment Info Detector,感觉WP-UserAgent能检测的浏览器和操作系统的版本更多一些，所以用了它。
其实俺比较喜欢的是WP Super Cache这个插件，希望它对Blog的访问速度有一定的提升。嗯，观察几天Blog访问情况就知道结果了。

WordPress插件介绍:WP-CodeBox

Timothy — Fri, 21 May 2010 15:06:00 +0000

WP-CodeBox 是我的WordPress一直使用的，一个可以方便的在文章中嵌入代码的插件。它使用起来非常便捷，而且支持众多的编程语言，对于咱开发人员来说，真的是一大福音。当初从wordpress.org的官网比较了几款代码插入的插件，最终我还是选择了它。CodeBox除了支持众多编程语言外，而且在展示代码的时候，有漂亮的外观(如下图)，并且代码框使用脚本实现了动态的代码折叠效果。在浏览的时候，用户可以通过单击按钮随时折叠代码，也节约了屏幕空间。

CodeBox的使用也非常简单，举个最简单的例子，只要在文章中写入下列代码，插入你的程序代码即可：

insert your code here…

其中的language code，是编程语言的代码，让插件知道，你插入的代码是属于哪种语言。
当然还可以插入文件，供别人下载，也可以通过设置让其是否显示折叠和代码行，等等，相关功能都可以在wordpress官网中该插件的页面找到。
对于CodeBox支持的众多编程语言，俺在OneNote中整理了一份language code和具体编程语言的对照表，这样可以一目了然的知道你的编程语言，对应的language code是啥了。我把对照表导出成一了份PDF，放在俺的Sky Drive，供大家下载。

新增博客插件–Mail To Commenter

Timothy — Tue, 05 Jan 2010 16:20:00 +0000

新增了一个轻量级的邮件通知回复的插件:Mail To Commenter。从现在开始，博友可以通过邮件收到偶回复留言的通知了。开始本来打算使用Thread Comment的，最后还是放弃了，选择了Mail To Commenter。该插件的使用和配置也很方便，由咱国人开发。

插件主页：http://www.thinkagain.cn/archives/989.html
插件下载地址：http://wordpress.org/extend/plugins/mailtocommenter/

新增博客插件–Comment Info Detector

Timothy — Tue, 29 Dec 2009 14:24:00 +0000

一个很有趣的插件，能显示博客评论者的相关信息，并以图标的方式显示出来，包括评论者IP所在的国家、浏览器、操作系统，这种统计还是比较有意思，也相当直观，看图吧：

安装过程也很方便，后台直接启用，然后小小设置一下，就OK了。

插件官方地址：http://hieudt.info/wp-plugins/comment-info-detector/

手机版博客更新了插件

Timothy — Fri, 25 Dec 2009 15:38:00 +0000

一直以来，我的blog用的wp-t-wap插件实现博客的手机浏览，感觉还不错，插件启用时，会自动生成手机浏览所需的页面文件。无意中发现博客好友久酷同学在使用MobilePress，自己去down了一个，试用了一下，果然不错，比起wp-t-wap更轻量级，插件支持多种主题以及自定义主题。而且插件启用后，能够自动识别访问的客户端，如果发现是手机等移动设备，就自动启用MobilePress的主题，相当方便。推荐还没有安装的同学使用。插件的安装和设置也很简单，就不在此累述了……

MobilePress 插件
下载地址： http://wordpress.org/extend/plugins/mobilepress/

Dynamic Plugins Manager (五) Plugins Manager 源码下载

Timothy — Tue, 01 Apr 2008 15:17:44 +0000

今天和同事一起把Plugins Manager放在了google code上面。大家可以从下面的地址获取所有的源码了。

http://code.google.com/p/dynamic-plugins-manager/

Dynamic Plugins Manager (四) 插件及Demo源码下载

Timothy — Sat, 29 Mar 2008 08:12:16 +0000

这里提供了插件的Demo程序，和编译好的Plugin Manager下载。
Plugin Manager的代码待整理后放上来。[cool]

开发运行环境：
Windows Vista Ultimate
.NET Framework 3.5
Microsoft Visual Studio 2008

点击下载此文件

Dynamic Plugins Manager (三) Demo

Timothy — Sat, 29 Mar 2008 07:58:23 +0000

下面来演示一下Plugins Manager，先看看我们事先做好的Interface和两个具体实现的插件.

Interface，接口定义：
[code]
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Component
{
public interface IComponent
{
string Invoke();
}
}
[/code]

整个接口，只声明了一个Invoke方法，这也是具体的插件必须实现的一个方法。

第一个插件类 class1.cs
[code]
namespace Component
{

public class Class1 : MarshalByRefObject,IComponent
{
string message = string.Empty;
int number;
float number2;

public Class1(string input, int num)
{
message = input;
number = num;
number2 = 0;
}

public Class1(int num1, float num2)
{
message = "none";
number = num1;
number2 = num2;
}

public string Invoke()
{
return "This is TestLibrary. member---message:" + message + "number:" + number.ToString() + "number2:" +number2.ToString();
}
}
}

[/code]

第二个插件类 class2.cs
[code]
namespace Component
{
public class Class2 : MarshalByRefObject,IComponent
{
public Class2()
{
}

public string Invoke()
{
return "This is TestLibrary2 without construct param";
}
}
}

[/code]

这里我们看到区别，第一个插件，需要构造函数，第二个插件不需要构造函数，所以在配置文件中，第二个插件可以关闭掉ConstructParam这个节点。

下面我们将Class1.cs编译好，放到插件目录中，改名为TestLibrary.dll，将Class2.cs直接改名为TestLibrary2.cs，放到插件目录中。
演示的目的：插件1需要在加载时，构造初始化函数，而插件2不需要。
插件1，是已经编译好的dll，不需要实时编译，但是插件2需要。

下面是测试的截图

1.插件目录，一个放入编译好的dll，一个放入.cs源码

2.启动测试程序，看到2个插件都已经被加载

3.此时，再查看插件的目录，我们会看到Plugin Manager为我们编译，并生成的插件2的dll

4.查看插件的日志记录

5.插件的调用
选中TestLibrary,点击Invoke按钮：

选中TestLibrary2,点击Invoke按钮：

6.插件的动态卸载和发布
a.动态卸载，可以直接使用Plugins Manager的UnloadPluginByName直接通过程序调用卸载。也可以手动打开插件的配置文件，将EnablePlugin设置为False
b.动态发布，直接在插件目录中，建立一个新的子目录，然后将插件的dll和xml配置文件直接拷入即可
关于第6点，这些功能的演示，截图比较麻烦，大家可以直接使用测试程序测试即可。

Dynamic Plugins Manager (二) 配置及实现分析

Timothy — Sat, 29 Mar 2008 07:24:58 +0000

整个Plugins Manager是一个基于dll的程序集，开发平台，基于VS2008和.NET 3.5 Framework。为何要用.NET 3.5呢？没别的原因，只要是为了尝试一下Linq to XML [cool]

使用改组件，需要在应用程序中，添加引用。另外，还需要在应用程序中，建立相关的配置项：
[code]

[/code]

PluginsPath是插件的主目录，里面通过子目录的方式，存放不同的插件。Plugins Manager在启动的时候，会遍历插件主目录，并搜寻可加载的插件。
LogPath是插件的日志目录，里面的日志文件，会详细记载插件管理器当前的运行情况。

另外，在Plugins Manager中，区别不同的插件，是根据不同的插件名称来决定的，这取决于插件dll的命名。
对于不同的插件，Plugins Manager也提供不同的特性配置文件。配置文件是.xml文件，命名需要和插件dll相一致。
下面是一个配置文件的示例：
[code]

Component.Class1
True

D:\MyCode\C# Projects\DynamicPlugInsApp\ITestInterface\bin\Debug\ITestInterface.dll
[/code]

TypeName:插件的类名，和具体的插件命名空间和类名有关，Plugins Manager根据配置文件提供此相关信息，通过.NET的反射技术，生成具体的插件Instance
EnablePlugin:插件开关，True表示当前插件可用，False表示阻止Plugins Manager加载此插件。该开关可以在Plugins Manager运行前设定，也可以在Plugins Manager运行时动态更改。Plugins Manager会检测配置文件变化，并留意EnablePlugin开关，以决定是否动态加载或者卸载该插件。
ConstructParams:此节点，及其子节点，用以读取插件是否需要在运行时初始化构造函数。子节点用以描述构造函数中的参数，以及类型，和初始化的值。构造初始化函数，也是在.NET的反射中实现。这里要注意，节点顺序和构造函数参数顺序有关。如果插件不需要构造函数，可以关闭此节点。
ReferenceList:此节点用以需要动态编译的插件，如果插件代码中还引用了其他的程序集，需要在此进行描述。

此外，插件还提供了事件通知功能，供应用程序进行响应和处理，实现的事件类型有以下几种：

[code]
public enum PluginEventType
{
PluginLoadOver, //所有插件加载完毕
PluginAdded, //插件新增完毕
PluginRemoved, //插件卸载完毕
PluginStopped, //插件管理器已停止
PluginStarted //插件管理器已启动
}
[/code]

插件的事件参数定义如下，只包含简单的事件类型和文本描述：

[code]
public class PluginEventArgs : EventArgs
{
#region Private Members
public PluginEventType EventType { get; set; }
public string EventMessage { get; set; }
#endregion

public PluginEventArgs(PluginEventType eventtype, string message)
{
EventType = eventtype;
EventMessage = message;
}

}
[/code]

以上是使用该插件，需要配置的地方，下一篇日志，将演示该插件的Demo.

Dynamic Plugins Manager (一) 介绍

Timothy — Sat, 29 Mar 2008 06:55:32 +0000

Dynamic Plugins Manager是一个基于.NET的动态插件管理组件，也是我在业余时间做的一个小东东，代码在07年底就开始动工，因为一直没充裕时间完成，趁这个周末休息，加班加点的Coding，出来了一个原型，估计里面还有很多的显而易见的以及隐而未现的bug。
设计这个组件的初衷，是为了能方便的应用于今后的项目中。先进的企业级项目中，变化最为突出的，还是业务，业务的变化，直接导致编码中业务逻辑代码的变化。如果将这些业务逻辑混杂在一起，业务的变化，最终会导致代码的混乱，甚至难以维护。这对于一个长期迭代的项目来说，是相当痛苦的事。就像直接拿一个成千上万行的代码给开发人员，估计开发人员不是晕厥，就是吐血。而一个难以维护的业务逻辑代码，对于每一次迭代，都是一次冒险。很可能在某次的迭代中，会对以前的业务逻辑，产生影响或者风险。
对于复杂的业务逻辑，需要进行重构，并且将不断变化的业务逻辑，抽离出来。比较折中的方法，就是将这些变化的逻辑，做成独立的插件形式。这样一来，独立的业务，在物理上进行了分离。开发人员也不用担心修改某处业务逻辑，会影响其他的业务模块。而动态的插件管理形式，对后期维护也带来益处，独立的业务逻辑插件之间，不会相互影响。开发人员还可以在程序运行而又不影响业务的情况下，动态的发布、替换原有的业务逻辑模块。
Dynamic Plugins Manager(以下简称Plugins Manager)，也就是按照这样的思路和需求来设计的，其实现的功能，具体有一下几个特点：
1.所有的插件，都以DLL程序集的方式发布,Plugins Manager在启动的时候，搜索加载所有可加载的插件并进行加载
2.Plugins Manager，支持插件的动态卸载功能。借助于AppDomain的特性，所有的组件，在动态加载后，可以动态从内存中卸载。插件的实现，需要继承自MarshalByRefObject。
3.与接口无依赖性，Plugins Manager负责插件的管理、动态加载、动态卸载、调用。但是和具体的插件接口无关，这样一来，开发人员可以定义自己的插件接口，并开发不同的插件实现接口。
4.插件可以动态发布和卸载,Plugins Manager会监视当前目录中，插件的变化，对于以xcopy方式，拷贝入插件目录的插件，可以进行动态加载。对于插件的卸载，可以Plugins Manager提供的接口进行动态卸载，也可以实时更改插件配置文件中的具体开关进行卸载。
5.动态编译功能：Plugins Manager允许直接发布插件代码。通过读取插件配置文件中的引用信息，可以直接从代码生成dll插件，并加载。
6.允许插件实现不同的构造函数重载，并将构造函数参数以及值信息，定义在插件配置文件中。Plugins Manager在加载插件的时候，采用配置文件中的值，调用相应的构造函数，并加载插件。
7.事件通知：Plugins Manager在不同的插件操作完成后，会触发相应的事件机制，通知客户端程序进行相应的处理

插件的结构一览：

PluginsManager:插件管理类，实现插件功能的主要代码逻辑，以及对插件容器的维护
AssemblyLoader:插件加载类，实现从AppDomain加载插件的逻辑
PluginEntity:插件实体类，包含插件的信息(插件实例、插件名称……)
AssemblyFactory:插件生成类，实现从插件代码生成dll的功能

下一篇日志中，将会介绍这个插件的具体配置，及简单分析其实现。

Dynamic Plugins Manager

Timothy — Sat, 29 Mar 2008 06:47:15 +0000

Dynamic Plugins Manager (一) 介绍

http://www.xiaozhou.net/article.asp?id=187

Dynamic Plugins Manager (二) 配置及实现分析

http://www.xiaozhou.net/article.asp?id=188

Dynamic Plugins Manager (三) Demo

http://www.xiaozhou.net/article.asp?id=189

Dynamic Plugins Manager (四) 插件及Demo源码下载

http://www.xiaozhou.net/article.asp?id=190

Dynamic Plugins Manager (五) Plugins Manager 源码下载

http://www.xiaozhou.net/article.asp?id=191