热度:
这个问题像梦魇一样一直挥之不去。随着数据记录数量的增长数据表越来越大是无法避免的，而博客服务器资源有限也是现实的，再说了还有数据记录超过5万之后对速度的影响也是非常明显的（记录数量过了10万“朋友来访”就无法正常显示，删到5万就正常了）。
一般共享服务器对数据库大小都是有限制的，否则可能因为个别用户使用超大数据库查询时占用太多系统资源影响其他用户，这个限制是多少目前没谱。不过我的统计数据表曾经达到了40M之巨，那一般的服务器提供给博主使用的应该也差不多在50M左右。数据库大小限定既然是存在的，那StatPressCN必须提供解决方案，不能任由数据库增长超限时出现异常或被服务器提供方警告从而引起博主对插件的不满。限制大小其实是通过限制数据记录数量来实现的，初步计算每条数据记录的大小是231个字节，那10M的大小就是45392条数据记录。给数据表设定大小限制，通过判断数据记录数量进行，超过了就删除时间最早的记录，然后更新归档数据。出于效率考虑，删一条增一条效率太低，因为每次都要归档数据，合适的做法是判断超限了，那就一次性删除一定数量的记录，更新归档数据，优化数据表（实际执行数据记录的操作），等下次又超限的时候在删除一定数量的记录，更新归档数据，优化数据表，如此循环。这个数量定为多少合适呢？不能太小，因为会影响效率，又不能太大，删除多了对博主对来访统计全貌的了解是个损失。那就在两天的数据记录和1024（反应在数据表上大小上则是231K）之间进行比较找个小的做标准，这样可以保障最高也不会删除超过两天的数据记录。那删除那些数据记录呢？因为是要解决数据表占用空间问题，所以操作对象是所有数据记录，包括404的和正常访问的。对删除的记录数量需要做记录吗？为了反映StatPressCN运行的整体情况，还是记录已删除记录数量的好。在什么时候执行这个操作？在加载插件的时候执行有点浪费，因为不是每次访问都会被统计，比如那些对爬虫的来访（设定不统计爬虫来访的前提下）。最好的挂接点是已经确认要记录该次访问了，那就是append新记录之前。
综合以上分析，拟用以下方案解决数据记录太多超过服务器限定大小或影响插件以及博客运行速度的问题：
1、在选项页中增加“数据表大小”设定选项，默认是5M，其它可选项是10M、15M和20M。默认5M是个超安全的设定，能容纳22696条访问记录，对一般的博客流量来讲够用了，且不会影响访问速度和后台高级功能（如朋友来访）的使用。对于那些服务器资源足够且网络水平较高（起码要能理解数据表大小会随着数据记录的增加而增大的）的朋友，可以吧数据表大小设定的更大点以便得到更多的来访信息。另外，此数据表大小限定的优先级别明显高于存储时限限定，且存储时限限定因为不直观对一般用户不容易理解，所以存储时限限定这个选项就可以退休了。
2、在确实要添加新访问记录 [...]
热度:
为了降低StatPressCN对服务器资源的消耗，我想可以把一些数据每天归档一次，使用的时候调出来就行了，免得每次对整个数据表进行查询。可以这样处理的有昨日来访数、上月来访数、去年来访数等。设定today、thismonth、thisyear参数并赋值，然后在调用插件的时候拿当天日期和上面的参数比较，日期、月份和年份不同了就更新上面的参数值，然后再相应的更新昨日访问、上月访问和去年访问总数。逻辑上没什么问题，但实现后很偶然的情况下发现统计页面中显示的昨日数据其实是前天的数据，而柱形图中却是正确的。这个问题纠结了很久，昨天才完全搞定。主要原因在于服务器时间、访问者所在时区、php的时间函数、mysql的时间函数以及wordpress的时间函数的配合问题。
php的时间函数分两类，一种是直接显示本地（当然是服务器的本地）时间，如time、date等函数，而另外一种是显示格林威治标准时间的，不带时区的，比如gmdate函数。strtotime默认是使用time函数结果的，已经考虑的服务器所在地的时区，但没有考虑你设定的blog的时区。时间问题其实特别麻烦，牵扯到历法不同、时区等复杂因素，wordpress考虑这个问题，提供了一个current_time()函数，同时考虑了服务器所在时区以及你设定的blog的时区，来提供一个统一标准的时间，这个极大简化了时间问题的综合考虑。mysql的时间默认也是考虑时区的，同时在存储格式上和php的时间有所不同，互相调用的时候需要考虑格式的统一。
昨日数据确实显示成前天数据的原因在于strtotime(‘-1 day’)默认调用的是time函数的结果，考虑了时区差别，但没有考虑blog设定时区的差别，从而导致了昨日参数的值错误（在时差范围内总是显示前天的日期），调出的数据当然也是错的了。解决的办法是用strtotime(‘-1 [...]
热度:
上月初笔记本的硬盘噼里啪啦的乱了，貌似是硬件问题，听着里面咯吱咯吱的叫，感觉心惊肉跳的。换了同型号的硬盘重装系统，幸亏有网络和移动硬盘备份重要文件，让工作可以继续，但手机程序、照片以及自己业余开发程序的环境就不复存在了。近段忙的不行，前天终于有时间有心情把这一切恢复起来。把相关步骤做个记录，聊以备忘。以后如果硬盘再坏了，照这个重新来一道就可以了（希望不会再次发生）。
整体的部署如下：
安装netbeans for php的集成开发环境；
在本机架构apache服务器和mysql服务器环境；
从http://heart5.com 的服务器空间把整站down下来，然后把mysql数据库压缩备份下来；
在本机架构wordpress博客站点并把down下来的网站数据和数据库数据恢复并做相应修改，注入；
在netbeans中新建project，源码就是本地服务器安装的wordpress程序代码；
安装svn工具，checkout出来wordpress.org插件目录中的源码，设定到netbeans开发环境中；
okay。
一、netbeans已经是6.9版本了，php专用版只有35M，安装之，和以前版本的差别不是很大，release中说是多了对某些服务的支持，使用过程中再慢慢体验吧。netbeans本来是java开发平台，原来使用体验不错，就沿用了for php的专用版本，也不期待对php的支持能好到哪里去，能用就好。
二、在本地架构主机和数据库服务自然使用xampp套件，到主网站看了下，已经升级到1.7.3版本了。下了个lite版本，zip压缩，有60.9M大，支持apache和mysql够了。解开使用前，需要运行setup_xampp.bat进行系统设定，基本一路y就可以了。平常使用的话就运行xampp-control.exe，手动启动apache和mysql服务就可以了。可以在浏览器中键入http://localhost/xampp 进行测试，安装并设定成功的话浏览器会显示xampp的欢迎信息。
三、考虑到博客上曾经上传了图片存放，再加上一些其他个人文件，因此找胡戈戈回复了ftp密码后对全站进行下载，结果花了我五个小时时间，大呼上当。究其原因，首先是原来设定的每周数据库备份占了100多M，其次是wordpress的目录太深，ftp时非常好时间。其实正确的方案是在本机重新安装wordpress3.0版本就可，至于个性化的图片和文件顶多半个小时就恢复完了。进入cpanel对数据库进行了备份下载。后来发现的诡异事件是自从我用cpanel对数据库进行了操作后，网站居然不可访问了，提示error establishing database connection，后来Google之，根据别人经验对config文件进行了相应修改才恢复正常。难道原来的配置文件是错误的，那为什么原来可以正常访问呢？猜测可能是服务器端缓存的原因。
四、wordpress程序文件和个人个性化文件很好搞，直接拷贝到xampp下的htdocs目录下就行了。有点技术含量的是对本机的mysql进行相应的设定。登录http://localhost/xampp ，进入phpadmin图形化数据库管理界面，构建一个数据库用于存储博客数据，然后再用mysql命令行工具新增一个用户并赋予它访问新构建数据库的权限。方便起见，建议无论是数据库名称还是用户名称和密码都和外购服务器空间上的保持一致，避免更改config文件。同样是在phpadmin图形化数据库管理界面中选择新建的数据库，把从外购服务器备份下来的数据库文件导入，然后修改option子表的home和siteurl的值为http://localhost 。一切okay了，你可以在浏览器中登录http://localhost 访问，应该会正常显示博客页面，和外购服务器上的一模一样。注，为避免混淆，建议在管理后台修改博客中文名称，加上“本地”二字，避免调试中可能产生的混淆。
五、启动netbeans，新建项目，命名为wordpress，设定服务器地址为localhost，并选中源码改动时自动拷贝至服务器，源码目录一般在我的文档下的netbeansproject下。从xampp的htdocs目录下把文件全部拷贝过来。以后启动netbeans进行程序开发就行了，所做调整都会自动反应在本地服务器上，可以通过浏览器访问localhost查看效果。
六、原来用的是官方的svn命令行工具，这次尝新，安装了图形化界面的tortoisesvn使用。进入netbeansproject下的wordpress的statpresscn插件目录下，把内容全部删除，退回上一级目录，用鼠标选中statpresscn目录，右键弹出菜单中选择checkout，在弹出的窗口中输入http://svn.wp-plugins.org/statpresscn/trunk [...]
热度:
想借助jQuery提升StatPressCN的表现性能，阅读文档过程中突然想到一个问题。jQuery以及自己拟写的js文件需要在<head/>中载入，但wordpress封闭了页面的生成过程，这就意味着用户访问时产生的页面都是通过wp自动生成的，那我怎么有机会引入自己写的css或js文件呢？
后来想应该有hook可以挂接的。查询研读codex并通过研究其他插件的做法（比如wp-stats），果不其然，万能的wp果然提供了这些接口。
先看下wp-stats的做法。
### Function: Enqueue Stats Stylesheets
add_action(‘wp_print_styles’, ‘stats_stylesheets’);
function stats_stylesheets() {
if(!function_exists(‘pagenavi_stylesheets’)) {
if(@file_exists(TEMPLATEPATH.’/stats-css.css’)) {
wp_enqueue_style(‘wp-stats’, plugins_url(get_stylesheet_directory_uri().’/stats-css.css’), false, ’2.50′, ‘all’);
} else {
wp_enqueue_style(‘wp-stats’, plugins_url(‘wp-stats/stats-css.css’), false, ’2.50′, ‘all’);
}
}
}
给wp_print_styles添加了一个动作，这个动作通过wp_enqueue_style把自定义的css给链入了html的head部分。稍作修改在StatPressCN中测试，查看源码显示如下：《link rel=’stylesheet‘ id=’statpresscn-css‘ href=’http://localhost/wp-content/plugins/statpresscn/statpresscn.css?ver=1.7.3.0′ type=’text/css‘ media=’all‘ /》。引入成功。
wp_enqueue_style的功能是“把一个css样式文件纳入队列（显示）”，语法wp_enqueue_style( $handle, $src, $deps, $ver, $media )，handle指的是样式表的名称（必填）；src是相对根目录的路径，取值可以是字符串也可以是布林值；deps是指该样式表需要依赖的其他样式表列表，取值应该是数组；ver是指样式表的版本号，意在通知客户端浏览器采用新的样式表；media指该样式表的媒体类型。
样式表加载的相关函数有四个：显示，注册，注销和队列。WP_Styles – CSS stylesheet loading (and functions wp_print_styles, wp_register_style, wp_deregister_style, wp_enqueue_style )
js脚本的载入方法和css类似，仅仅是名称随之换成了scripts而已。WP_Scripts – JavaScript loading (and functions wp_print_scripts, wp_register_script, wp_deregister_script wp_enqueue_script)。
但脚本的加载因为兼容性等原因，要比样式表复杂一些。挂接点一般在init而不是wp_head（可能也行，但我测试没有成功），另外就是对jQuery的调用。因为wordpress系统自身是支持jQuery的，需要使用的时候声明一下就行了，如果想用自己想要的其他版本，那就先注销wp系统的那个，再注册自己的那个。测试成功的代码如下：
// Function: Enqueue StatPressCN [...]
热度:
功能开发：
在主功能页面中添加年度统计数据，应http://bizknowledgewatch.iese.us/的要求。
代码改进：
修正了选项中的一个显示错误。
规则定义：
添加了五个spider定义，其中一个是wukong，移动类的；
又找到了一条微软msn的恶意机器人ip规则。
下载升级：
请到wordpress官方插件网址下载最新版本，ftp到服务器上去；
或者，如果您的wordpress是2.7版本以上的，那就耐心等段时间（大约几个小时吧），管理后台会自动提示升级的。
升级需做：
无。
开发笔记
有朋友需要年度的统计显示，现在加进来了。刚好再熟悉训练下对时间函数的运用。
wukong搜索的爬虫真勤劳，侧面说明现在的移动搜索确实要兴旺发达起来了。
近期评论