分类目录归档:Code

关于编程的技术,包括JavaScript、CSS、PHP、Python 等。

WordPress网站从服务器转移到本地调试

很多wordpress爱好者可能都遇到过这样的情况:刚接触wp的时候,直接在虚拟主机(或者云服务器)上安装并运行了wordpress。并且,在很长一段时间内,都在网路上直接进行维护,甚至是编辑主题。但是,当你的网站需要进行大范围的改版,或者你想根据自己的内容重新进行设计工作的时候,麻烦就来了。要在本地重新建设一个环境,并把网路上的网站和数据原封不动的搬运过来,这并不是一件简单的“复制/粘贴”工作,还是有一些需要注意的问题的。非学派在这里详细列出几个步骤和注意事项,希望对正在计划进行类似操作的coder和设计师们有所帮助。

1. 建立本地调试环境

我自己在很多年的时间里,都在用一个叫做PHPnow的“环境包”(故且这么叫),这是一个很方便的东西,每当要更换电脑的时候,只要把整个文件夹拷贝/粘贴到新设备上,然后激活一下就可以了。正常情况下只要80端口没有被占用,一切都可以正常使用。但是,这个东西貌似2012年以后就没有更新了,考虑到php环境的版本等原因,我还是建议换一个先进一些的。记得以前在Linux环境下用过一个超级好用的环境包叫做LAMP——一个开源的Aphache,Mysql,Php开发环境,这么好用的东西当然要适配到windows上咯。于是,就有了这个东西WAMP

在网站上下载安装以后,持续“下一步”安装即可。安装完了以后就可以访问http://localhost访问本地页面了。

2. 官网下载WordPress安装包,并安装到本地环境

这一步其实是可以省掉的,但是我还是建议这样做,这样可以尽可能的搭建一个全新的wp环境,避免干扰和一些奇怪的问题。

在这里还是罗嗦一下,在安装wp之前,需要在phpmyadmin下新建设数据库和用户,这一步很重要。用惯了虚拟主机的站长习惯于主机商提供商数据库、用户名、密码等数据,但是在本地环境下需要自己完成这件事情。

具体步骤是:进入http://localhost/phpmyadmin页面>>右侧“数据库”选项卡>>填写新建数据库名称>>点“创建”,创建完成后,左侧点击新建的数据库>>点击右侧“权限”选项卡>>点击“添加用户”>>由上至下分别输入用户名,“localhost”,密码>>页面下方,点击“创建”,就完成了。

把你填写的这些内容,按要求再填写到由wordpress的wp_config.php文件中,就可以了。

安装WORDPRESS其他具体过程就不赘述了。

3.复制必要的文件

这一步完成以后,就开始搬运了。从你目前的主机上,下载./wp_content/themes/、./wp_content/plugins/这两个文件夹,粘贴并覆盖到本地文件相应位置。另外,还要拷贝跟你自己有关的上传文件夹。例如,我的是./upload,这个文件夹的位置与每个站长的使用设置有关。最后检查自己私人定制的文件夹,看看还有没有遗漏的。

4. 备份/恢复数据库

备份数据库比较简单的有两种方法,第一种是进入你的虚拟主机管理系统,备份整个网站或者仅备份数据库,用得到的sql文件从本地phpmyadmin中导入到相应数据库。

另一种是在虚拟主机的phpmyadmin中导出sql文件,再通过本地phpmyadmin导入到本地相应数据库中。

两种方法效果一样,且只要会操作phpmyadmin就行了。

至于其他的wordpress备份插件,我没有用过,也不想用,觉得是多此一举。

5. 修改数据库的两个关键值

倒入数据库以后,还有一项必须要做的工作,就是在数据库里改掉网站的域名和home网址,不改掉这个,网站在本地是无法正常访问的。

第一步,在你之前创建的数据库中,找到并点击wp_options表>>siteurl项>>在option_value输入框中,将域名改为http://localhost/XX。(“/XX”是你的wp项目文件夹名,如果wp安装在“/www”根目录,就不用写这部分)>>点击“执行”。

第二部,在你之前创建的数据库中,找到并点击wp_options表>>home项>>在option_value输入框中,将域名改为http://localhost/XX。(“/XX”是你的wp项目文件夹名,如果wp安装在“/www”根目录,就不用写这部分)>>点击“执行”。

改完上面这两项,浏览器输入http://localhost/XX,(“/XX”是你的wp项目文件夹名,如果wp安装在“/www”根目录,就不用写这部分)就可以正常访问网站了。当然,点击文章页面是不能访问的,因为没有启用服务器rewrite功能,启用方法请继续往下看。

6.启用本地Aphache服务器的rewrite功能

WAMP的Aphache默认是不开启rewrite功能的,这会导致WP的固定链接功能无法使用。开启的方法很简单:

修改C:\wamp\bin\apache\apache2.4.9\conf目录下httpd.conf文件,第154行行首的“#”去掉,保存。

就是下面这一行:

#LoadModule rewrite_module modules/mod_rewrite.so

重启服务器以后,进入WP的后台>>固定链接选项页面>>点击一次确定,就可以正常使用固定链接功能了。

总结

我这里没有放图片,单纯就是因为我懒。当然,文字写的也不是非常详细,只是一个原则性的过程。每个人在操作过程中多多少少都会遇到些问题。尤其是用了很长时间的网站,转移起来就更加麻烦了。不过为了更加方便的编辑和改版,这些辛苦都是值得的。


update 2016-07-25:第5项更改两个关键值实现本地访问并不是最好的方法。比较完美的方法是:使用apache的虚拟主机功能,绑定域名后,在本地hosts文件中解析域名至127.0.0.1来实现本地带域名调试。具体请点击我的另一篇介绍

WordPress加载速度缓慢的两个原因及解决办法

前阵子恢复博客的更新,但是,不论前台还是后台,打开都很缓慢。一开始以为是换了海外主机的原因,然而检查发现并不是。度娘上搜了一下发现没有比较完整的文章。于是责任心爆棚的我就想到在这里汇总一下,让遇到这个问题的人有更加清晰的解决方案。

辣么,究竟是什么问题呢?其实主要原因就是“伟大的墙”。在这堵“伟大的墙”的强力“保护”下,Wordpress产生了两大问题——字体问题和头像问题,这两项内容无法加载,造成了网站访问缓慢,让人心烦。

字体问题

wordpress使用了非常流行的google fonts,什么是google fonts?可以点击下面页面GoogleFonts,当然,不翻墙是看不到的。简单来说,就是google准备了很多开放字体(Open Fonts),用户可以在网站页面免费使用这些字体,还不用下载到本地。好处当然是很多了,例如不用担心客户端缺字体影响显示效果,也不用担心网页加载字体有速度和流量的问题(墙内除外)等。缺点当然也很明显,如果你所在的区域无法访问google,那就悲剧了。是的,我没说别人,就说你呐?看这篇文章的人,别东张西望了,仔细看下面。

wordpress主题是怎么使用google字体的呢?基本上从官方主题的twenty twelve(2012)开始,就有类似这样的一个函数function twentytwelve_get_font_url() {},函数代码我就不贴了,太占地方,它的主要作用就是根据自己主题需要获取一段google fonts代码,其中这一句很重要

$font_url = add_query_arg( $query_args, 'https://fonts.googleapis.com/css' );

是的,问题很明了了,就是这里面的url国内访问不了。怎么办?换掉它就行了!360公司学雷锋做好事一样的做了一个公共库,作用和google那个类似,只要把url换成

http://fonts.useso.com/css

就行了。注意,这更换过的传输协议是http,可不是https,后者是无法加载字体的,会导致页面加载更加缓慢。

后台访问缓慢,与页面访问缓慢基本是一个道理,但是修改起来有点麻烦。怎么办?用插件呗!太机智了,已经有小盆友@苏阳写好了插件等你安:open fonts替换插件。可惜的是,经过测试,这个插件也有点问题,就是行代码:

return str_replace('//fonts.googleapis.com/','//fonts.useso.com/',$text);

应该改为:

return str_replace('https://fonts.googleapis.com/','http://fonts.useso.com/',$text);

原因上面已经说了。

当然,还有更加决绝的办法,如果你根本不需要Theme、后台使用开放字体(并不推荐),那么你也可以使用另一个插件:Disable Google Fonts。安装启用以后,就跟开放字体说拜拜了,访问速度当然也上去了。

头像问题

与字体类似,wordpress默认使用的头像服务是Gravatar,当然,不翻墙也是访问不了的,这导致需要加载头像的页面显示缓慢。当然,解决这个问题的第一个方法就是后台“设置>讨论”页面里把“显示头像”的选项勾掉就行了,不显示头像,就没有这个烦恼了。但是,我就是矫情得要用这个头像怎么办?除了可以选择第三方的各种插件之外,我更推荐在主题的functions.php里加代码的方法,利用国内的留言服务“多说”的系统头像替换掉Gravatar的头像:

function mytheme_get_avatar($avatar) {
    $avatar = str_replace(array("www.gravatar.com","0.gravatar.com","1.gravatar.com","2.gravatar.com"),"gravatar.duoshuo.com",$avatar);
    return $avatar;
}
add_filter( 'get_avatar', 'mytheme_get_avatar', 10, 3 );

这样,就解决了头像无法加载进而拖慢页面显示速度的问题了。

经过以上简单的折腾,wordpress的网站速度可以说有了飞跃性的提升。当然这里要说的是,如果你的主题本身就不支持google fonts,那就根本不存在第一个问题,不过还是建议安装Disable Google Fonts插件或者open fonts替换插件,把后台速度优化一下,毕竟写文章的时候还是需要重视工作效率的。

关于青岛“11·22”输油管道爆炸事件的思考

2013年11月22日,青岛发生了“中石化东黄输油管道泄漏爆炸特别重大事故”,举世震惊。截至11月25日,死亡人数已达到55人,另有9人失踪、136人受伤。事故发生后,官方发布了事故认定结果,总结了三点,我简略摘抄如下:第一,输油管道与城市排水管网规划布置不合理;第二,安全生产责任不落实,对输油管道疏于管理,造成原油泄漏;第三,泄漏后的应急处置不当,未按规定采取设置警戒区、封闭道路、通知疏散人员等预防性措施。对此,我想谈谈自己的看法。

从事故调查的角度上来说,有如下几点建议。首先,应调查设计图纸是否有审查程序,查看图纸审查记录。设计是工程的灵魂,所有施工都要根据设计图纸完成。从事故发生的地点来看,管道处于城市主干路或次干路的道路下方,沿路敷设是否符合石化行业标准?与市政管线有无安全冲突?管道周边安全距离是否达标?这些问题都需要确定。并且,此类问题属常规问题,有大量的国内外规范和做法可以参考。

第二,要调取备案资料,检查当时施工企业的施工资质,是否有能力施工输油管线,调查项目是否按照国家规定,经过了正规的资格审查及招投标程序。施工环节是最容易出问题的部分,且中石化是中国最大的企业之一,它有着遍布于全国的工厂、管网,其项目实施水平也参差不齐,加之有中国特色的施工腐败深入骨髓,难保不出事。

第三,调查施工过程的组织计划,在关系到管线安全的方面,有没有控制点。施工作业人员专业资质是否齐全,是否持证上岗,施工人员中有无缺漏专业,是否有专职安全员,是否聘请专业的工程监理,是否在当地政府部门进行了施工备案。事故发生时,参与维修人员是否满足以上要求。

第四,根据相关技术资料,检查输油管线穿越道路部分是否实施相应防护措施。与市政其他管线是否有安全距离要求,如不满足要求,是否有防护措施。检修、维修现场施工人员是否发现危险,并采取防护措施。

第五,管道基础处理是否满足要求,管道施工后回填是否满足要求。诸如此类的施工过程细节问题,往往是导致事故发生的重大隐患。地下管道属隐蔽工程,此类问题解决不好,将给安全留下重大隐患。维修或检修时,是否对开挖进行安全评估,是否采取防止破坏的措施。

其实,上面的建议适合于各种施工事故的调查。当然,输油管道有着他的特殊性,它隶属于化工行业,这个行业里面有很多成文或者不成文的规定,是外人难于知晓的,必须根据行业的自身特点对事故进行客观、冷静的分析,切勿盲目判断。

从网上发布的施工现场图片来看,可以看出的主要问题有很多。首先可以看到维修现场机械开挖深度过大,接近管道位置必须进行人工开挖。图中甚至可以看出挖机是从路边随便找来的,并非专业施工队伍。此外,回填土土质中明显含有大量的石块等建筑垃圾。现场隔离措施过于简单,隔离距离过小,无关人员甚至可以随意出入。图中人员仅有一人佩戴安全护具。所有人员都没有设计图纸和维修方案等文件,组织计划性极差。人员态度散漫,没有认识到任务的危险性和重要性,等等。

从事故调查的难度上来讲,如此重大的责任事故与其他类型事故并不相同,例如,地铁施工现场垮塌,立交桥垮塌(立交桥被超重车辆压塌已经成了一个笑话),建筑结构垮塌等,这些事故由于事故发生原因明显,现场取证较为容易,在事故发生一个月内基本可以得出结论。但诸如此类的重大事故,由于现场破坏严重、各方势力博弈等问题,其调查程序没有半年至一年的时间是很难调查清楚地,其调查取证过程会面临各种阻挠和挑战,有些问题甚至可能几年的时间都无法得出完整的结论,远不是看看照片,查查资料就可以解决的。

但是,事故已经发生了,政府在积极抢救伤员,安抚死难者家属的同时,需要迅速启动事故彻查程序,从现场取证到深入调查。同时做好与媒体和民众的沟通工作,我建议有以下原则:很明显的问题要直白易懂地说、迅速的说;根源问题要谨慎的说,有根据的说;普遍关心的问题要全面的说,统一的说;敏感的问题要勇敢的说,毫不忌讳的说。这样,才能避免媒体过度猜忌,引发社会的不满。

之前,总有网友会对各种事故进行福尔摩斯式的分析和判断,我并不反对民间力量参与这种事情的调查和判断。但是这种调查和判断,必须建立在专业、准确、负责任的基础之上。不能借机哗众取宠,甚至借此娱乐大众,导致大众对当代化工产业的无谓误解,激化企业与社会的矛盾。“科学”这个词在这个时候可不是“民间科学家”所能摆布的东西,这可能关系着整个产业的健康发展和几十条鲜活生命的尊严。我们在诸如转基因食品、P*X*项目等等问题上,已经出现了这种苗头。当然,反例也有,例如,所谓的绿色能源——太阳能产业,反而造成更加巨大污染的问题,皮草衣服的加工和普通衣服的加工到底哪个污染更小等问题,至今在大部分公民的脑子里都还是一片空白。我们大多数时候都是更容易相信概念这个东西,而忽视了科学和审慎。

写到这,我拿起了手边的那本《设计,人类的本性》(亨利·波卓斯基),作者说:“无论技术多么过时或者创伤有多新,无论它在书中还是明天新闻上,每个案例研究都是认为失误和错误推理挫败最佳既定计划的潜在理解范例。”

我以此作为文章的结尾,并深以为然。(P.S. 不过这句话也翻译的也太烂了)

WordPress 3.6默认主题IE下相册图片宽度问题

今天抽时间在本地服务器上升级到了wordpress3.6。切换到默认主题Twenty Thirteen测试了一下,发现相册图片在IE10的标准模式下有个很明显的问题,如下图。另测试了9、8、7各版本IE浏览器,均存在这个问题。Chrome浏览器显示正常,预计FF显示正常。

twentythirteen默认主题图片宽度问题

可以看出,一篇文章中gallery里的图片宽度大于一定值的时候,并没有自适应宽度。如何解决呢?改进方法如下:
1.在style.css文件中找到如下代码:(style文件第659到665行)

 .entry-content img,
 .entry-summary img,
 .comment-content img,
 .widget img,
 .wp-caption {
  max-width: 100%;
 }

加入一行代码后如下:

 .entry-content img,
 .entry-summary img,
 .comment-content img,
 .widget img,
 .wp-caption {
 max-width: 100%;
 width:100%; /*ie10 bug fix*/
 }

即可解决问题。twentythirteen图片宽度问题解决结果

如图,相册图片IE下已经自适应到了合适宽度。

但是,这只解决了一部分,继续测试发现在IE8、7模式下仍然存在问题。这与TwentyThirteen主题兼容性设置有关,打开/CSS/ie.css文件,第68到70行改为如下代码:

.gallery img {
 width: auto;
 width:100%;/*lt IE 9 fix*/
}

问题即可解决。

问题分析:gallery中的img也属于entry-content块,但是并不直接包含,根据max-width的解释:

max-width使用百分数时,定义的是基于包含它的块级对象的百分比最大宽度。

可知,IE对max-width的继承性解释和标准浏览器有所不同。故需要对IE中的gallery图片宽度做width限定。

这篇文章叙述的情况,仅存在于相册中图片宽度大于604px,且使用【gallery】shortcode加入相册时的情况,大概很少人会在相册里加入这么大的图片吧,我想。

有言、多说、灯鹭三个社会化评论服务的简单评测

近两年wordpress用户受社交网站的影响加深,很多站长率先使用社会化登录插件来充实评论的社交功能。这样的做法规范了用户评论形式,聚拢了访客资源,增加用户粘性,同时便于站长分析和沟通。很多原有的社会化应用也不限于登陆注册那么简单,甚至已经没人愿意进行繁琐的登录操作。因此,更加快捷的社会化评论应用迅速得到推广。wordpress系统插件中也有不乏优秀作品,现在我来简单梳理一下几个主要产品的使用感受。

产品:有言多说灯鹭

在安装方面,基本没有什么可比性,都是从wordpress后台直接搜索安装。

后台易用性对比

在后台管理的易用程度方面我认为:多说 好于 灯鹭 好于 有言

多说后台界面友好,选项设置内容丰富,可定制性较强。wordpress插件设计用心,后台功能和布局都让人用起来神清气爽。

灯鹭的后台界面中规中矩,用起来比较舒服。更重要的是灯鹭功能异常全面,能把复杂的功能整理为现在这样,已经很不容易了。

有言界面简洁,但让人比较崩溃的是,wordpress插件后台界面,基本是原封不动的嵌入了有言网站页面,后台加载龟速,网页套网页看起来很低级,很不爽,易用性不佳。

实现功能对比

三个插件的功能性在我心目中的排序为:灯鹭 好于 多说 好于 有言

灯鹭的功能已经全面得让我头晕眼花(我是用的是wordpress连接微博插件),当然,这是在夸奖。在技术上我基本崇尚自由、全面、可定制。灯鹭不但考虑到了各种需求,还兼顾了普通用户的易用性。安装灯鹭的wordpress连接微博插件,基本上就是一站解决方案,从登陆管理到微博评论无所不含,甚至很多功能选项我都搞不明白是做什么用的。另外,灯鹭具备本地评论和网络评论双向导入,便于接入旧数据。

多说的功能我认为恰当好处,如果是一般用户的话,我还是推荐多说。轻量级,功能全面,使用轻松。本地评论和社会化评论互相导入功能也在其中,便于接入网站旧的评论数据。这一点灯鹭和多说都非常好。评论数据,基本是网站的第二生命,如果更换社会化评论就要丢掉原来的数据,太不值得了。

有言,是没有本地评论数据互倒功能的,所以,用有言就意味着评论都要推到重来,太不怀旧了。但是有言也并不是一无是处,在龟速的管理界面中,有一个自定义CSS模块,可以在线diy显示样式,这一点可能会受到css热情玩家们的喜爱。多说也有这个功能,不过没有有言那个大气。css这东西反正我是编腻了,默认的模板都很不错。

前台访问速度

这一项是致命的,前台评论框的显示速度,对于用户互动积极性甚至到毫秒级的差别。我写这篇文章的时候在西安出差,网络是电信8兆adsl,实测得出的速度对比为:多说 好于 有言 好于 灯鹭

多说和有言的加载速度基本一致,整个页面加载后1~2秒内都可以加载完毕,并且多说在加载时有显示加载中的小动画,虽然做的很粗糙很小,但是好歹是有。灯鹭就比较崩溃了,页面加载完后,至少要5、6秒才能显示,多的时候甚至干脆不显示。而且,空白部分没有任何加载提示,完全虚无状态啊,灯鹭你逗我玩呢吧,这坑爹速度是要闹求甚啊!

不过,我的网络环境并不具有代表性,这一项存疑。但是后面的静态化分析就能很明确的看出问题来了。

静态化分析

这一项很简单了,源代码一打开便见分晓。多说为html静态化,有言和灯鹭均为JS输出。静态化输出的好处,这里就不用我多说了吧,搜索引擎、网页锚点(就是你点击的那个“XX条评论”、“留下评论”等等连接会自动定位评论或评论框的位置)、加载速度(上文已经比较过了,多说最快这个说法是很科学的)。其中加载速度的差异是很明显的,尤其在网络差或人品不好的时候。

好了,总结一下吧。

多说功能恰当好处,符合用户使用需求,后台界面简洁好用速度快,前台加载较快且有加载提示,具备本地数据和社会化数据互导入,静态html输出。综合评定后,本人推荐使用。

灯鹭功能强大,综合了社会化登录和社会化评论,后台设置极其全面且专业,前后台界面设计尚可。具备本地数据和社会化数据互导入。最崩溃的是前台的显示速度太垃圾了,等不了的那种。目前不太推荐使用,如果有朝一日能解决加载速度问题,马上转投。

静态化算是个小问题吧,我对页面功能追求完美,无静态化,就意味着评论的锚点无法使用,就意味着“XX条评论”和“留下评论”连接点击后没有作用,直接跳转文章开头,很不爽。

有言,后台有现成的css编辑功能,可以自己定制样式,这是唯一的亮点。wordpress插件功能单一,仅仅是避免了繁琐的代码操作,插件并没有在功能上进行拓展,仅属于便民型服务。而且后台没有二次设计,且加载龟速。不具备本地数据和社会化数据互导入,没有静态化,不推荐使用。

非专业评测,不保证准确性,吐槽而已。

后续:昨天刚写完这文章,多说的评论就显示不出来了,上多说官网的博客,发现也是一样,估计是数据库什么的挂掉了,一直到今早上才恢复,晚上联系客服也没人理,减分。多说服务稳定性值得商榷。

参与1shan.cn随机聊天平台开发

最近帮何二同学搞一个轻量级网页随机聊天项目——“一闪”网,我主要进行了前端代码重写和美化工作,优化了下用户体验。项目虽小,工作量还是不少哦。

一闪网主打随机聊天功能,类似于国外的omegle和国内的陌路人,但是功能上增加了关键字匹配和供求模式,提高了随机聊天的目的性。既保持了一定的神秘感,又兼顾了聊天的目标人群。创意有可圈可点之处,团队也比较靠谱。有机会就来搭个讪,或者找同道中人畅聊一下吧!

后台功能通过node.js实现,具有大并发数承受能力的优势。但是node属于新兴编程语言,维护起来不那么方便。感谢杭州的刘春龙编写的后台程序。

网址:一闪:http://1shan.cn

由于系统上线不久,如果发现什么bug,希望大家及时反馈哦,谢谢了先!

和讯部落、天涯社区不完全评测

网络社区是网民们相互交流的重要场所,如今的社区已经不仅仅是建立个人主页、发几张照片那么简单,它已经变成了一个网民们用来争夺话语权的多媒体交互平台。我认为多数网民进入社区都有一个主导需求,那就是通过一种简便可行的选拔方式让自己得到其他人的认可。所以现在的网络社区实际上是一个具备“投稿-筛选-发表”这三个步骤的简单选稿系统,大型社区的优势也就在于能够让发表在社区页面上的稿件获得更多和更广泛的评论。

现如今很多的社区系统都是由论坛、博客、相册等服务拼凑起来的,网民们只要使用了其中任意一项服务就已经进入了社区系统。所以社区是所有网民资源的整合方式,是一种普适手段。在这其中,我并不认为博客的出现是一种观念上的进步,无论从技术上还是形式上都称不上先进。从技术上说它就是最原始的新闻发布系统的简单衍生物;从形式上来讲,从网络留言本到记事本再到论坛,博客只是夹杂在其中的一个四不像。更强调个人独立性的良好定位才使博客登得大雅之堂。至于论坛和相册等等,也都是选稿系统中的一环,是对网民所发布信息的一种规整方式罢了。

号称中国第一大的中文社区的搜狐社区是这其中的代表,由于巨大的访问量造就了搜狐第一门户的印象。所以,这种社区谈不上什么客户服务,能够享受到选稿发表特权的,只是网民中的九牛一毛,大量的垃圾信息也使整个社区包罗万象、莫名其妙。一个成功的社区一定要有它固定的使用人群,相对集中的主题探讨和勤奋不息的编辑与选稿人。有了这些特点,社区才能够拥有自己的文化和风格,才能够留住更多的优秀网民作为网站的信息发布和共享者。

近期经过同事推荐,有选择性的试用了两个社区的服务——和讯部落、天涯社区。现就一些感受略加表述,送给正准备投身网络社区的草根们。

1.网速和界面

我本人使用的是北京长宽和北京网通的虚拟宽带,两个社区的速度都较为一般,和讯稍快。但在上网高峰期,天涯的速度就有点让人难以忍受了,不知道与页面结构有没有关系。和讯打着国内最快速的个人门户服务的旗号,但就实际使用过程来看,并没有达到宣传中那样的效果,尤其在进入个人门户编辑页面时,速度明显减慢,甚至会暂时性的出现浏览器假死。

从界面设计角度来评价,个人更倾向于和讯简洁多样的风格设计。天涯的设计更趋向于稳重和保守,缺乏现代感和简洁美,创意就更别提了。

2.技术和服务

仅就服务的全面性上来讲,两个社区都无可厚非。然而天涯的服务显得慵懒很多,给某部打电话,连续三次都有人嬉皮笑脸的告诉我要找的人不在,如有需要请在早上几点到几点之间再次拨打,这简直是放屁一样的话,一个网络媒体,下午都没人值班,那还搞个屌啊!和讯的服务比较注重客户感受,无论是从界面设置和贴心的客户服务都让人感受到了一个财经门户的严谨风范。

3.内容和用户

内容大体上喜欢天涯的风格,注重生活品质和具有忧患意识的一群人聚集在一起,真正形成了自己的思想风格。少量资讯的内容也比较精致。而和讯则与经济密切相关,显得与生活格格不入,大量的专业性分析类的资讯估计搞这个专业的人也有看烦的时候。社区不能够成为拽文和炫耀的场所,和讯的个人门户主页也显得粗制滥造,少了一些大社区的风范。

4.细节

最终对天涯产生了厌恶的感觉,仅仅因为天涯不提供cookie功能,每次登录都要从那个打着大广告的界面输入用户名和密码,感觉它就像一个个人网站一样缺乏用户至上的服务精神。而和讯的缺陷则是对于喜欢自定义的个性化网民不够开放,css的自定义已经不是什么稀奇事,如果能够开放html自定义,那整个社区的功能的档次就会提升不少。

总体上来说,作为中文社区的两大代表性的网站,他们各自都有着不同凡响的地方。相信会有更多的人逐渐认识到社区的真正意义所在,不再制造那些无病呻吟的垃圾信息,而是充分利用交流的机会,拓展我们的视野,丰富我们的生活,助推我们的事业,认识到更多志同道合的好朋友。

由于存在访问速度和评论注册的问题,大名鼎鼎的MSN Spaces社区并没有给人留下很好的印象。据Sunlied介绍说和讯社区是国内比较出色的社区服务商之一,于是投身其中准备体验一番!网络社区存在的意义,就是除了能给无聊的人打发大把时间之外,还可以给游手好闲的网络民工们作为消遣工具来使用。

转战ASP博客程序——Pj,Lbs,Z-blog

转战ASP博客程序——Pj,Lbs,Z-blog
自从喜欢上博客和网页设计之后,我先后转战了几个博客程序。其中包括以ASP和PHP的两种技术基础的程序,主要是:Pjlog Lbs2 Z-blog,Wordpress。它们共同的特点是:结构简单,使用便捷,源码开放,适合初学者使用。

但是经过长时间的使用和测试也积累了一些经验和认识,虽然不及专业人士分析的那么透彻,但相信像我一样在苦苦寻找和学习的人也不在少数,这些话也许值得大家借鉴。

(一)Lbs2——结构简单,用户集中

我使用的第一个程序是Lbs2,这也许和很多人的经历不太一样。据我所知,现今国内ASP博客程序使用人数最多,团队人气最旺的要属Pj了。可是就是因为这个原因,我放弃了最先使用pj的想法,而是选择了一个较少被人提及的Lbs2博客程序开始了自己的建站之旅。

首先,其实对于刚刚建站的菜菜鸟来说,追求个性是学习知识之外最主要的因素,因为厌恶很多博客服务商的低俗品位和满身的铜臭味,所以自己搭建平台。Lbs2的低调让我很是欣赏。

其次,Lbs2拥有良好的论坛技术支持和使用群体。这款程序应该是几款程序中历史比较悠久的了,用户群虽然不是那么多,但是使用者多数集中在经验丰富,技术上也比较成熟的人当中。尽管程序已经诞生了很长时间,且新版本却遥遥无期,但是仍然有很多热心的铁杆用户经常出现在论坛前沿为大家答疑解惑,营造了很好的学习交流氛围。这对初学者是至关重要的!

再次,从程序本身分析,lbs2的主体文件是Js语言构建的,整体看来结构一目了然,让人很是舒爽。想要个性化也不难,修改程序和css样式都可以很快上手。

虽然Lbs2的更新已经是很渺茫的事情了,但令人欣慰的是,作者已经出面肯定,lbs2不会就此结束!

(二)PjBlog——功能齐全,使用者鱼龙混杂!
说起Pj,用过的人都会有一个感觉:简单!我记得当时开始使用时,Pj是第一个提供自动安装包的免费程序,作者还是相当用心的。

程序源码的编制者,是一个还算牛B的人。虽然经常出现在自己的博客上,但新版本的开发还没有什么眉目。Z-blog的新版本已经在公测了,但他居然还是无动于衷,也许他太忙了,免费的东西已经对他没什么吸引力了。

我真正向别人发布皮肤也是使用Pj之后的事情,由于pj用的人比较多,所以交流的机会也就比较多。但是Pj编皮肤的弊端也是很明显的,那就是如果要在不改动员程序的基础上实现三栏先是方式,就必须使用模块的绝对定位,这使得皮肤转移使用带来了不便。当然,并不是所有人都能够接受三栏皮肤,但是抱着学习的态度来使用,谁不希望能够够用比较正统的方式来实践一下呢!

Pj的程序对于初学者来说是比较复杂的,轻易上手改程序简直是痴心妄想。况且,Pj的功能真的已经比较齐全,各种插件的数量和质量一定是同类程序中最高的!没什么必要改了,论坛上已经有的东西就够用上一段时间的。

说起pj的论坛很用户群,我就真的不敢恭维了。只要看看论坛上的那些注册博主就知道了,Pj的用户群不但初学者多,而且“不懂事”的人也比较多,口无遮拦的自不必说,那些真正是用自己的皮肤,或情愿使用别人的皮肤儿属上作者姓名的人又有几个?大多数人只知道在论坛里无聊的打趣嘻笑,真正能为别人解答问题的人有几个?那些斑竹其实也是不称职的,他们没有建立起一个良好的讨论环境,而且大多数斑竹自己也是一知半解!对新手还指手划脚,嗤之以鼻。真是无奈,Pj是个好程序,可是被哪个垃圾论坛给毁了。

(三)Z-blog——自强不息,逆境而上!
Z-blog,也就是我现在使用的程序,它也可以说是开源博客的元老级程序了。虽然有人指出Z-blog只适合短期少量日志使用,长时间使用会导致种种问题而无法解决,后来的使用人数也没有大量的增长。但是面对这些问题,程序的开发团队积极应对,终于在近期放出了公测版本。新的版本采用了Ajex留言模块,减少了页面载入量,加快了运行速度,后台运行更加人性化,基本解决了长时间使用的重建缓慢的问题。

Z-blog是我使用过的,集简洁与实用于一身的最好的博客程序,它摒弃了很多无用的附加功能,加快了反应速度,简化了管理方式。可以看得出,Z-blog是为那些追求个性和简洁的人量身订制的程序。这一点最集中的体现在样式与主体的明确定义,一目了然的模版文件可以轻松的实现三栏甚至是更多更复杂的网页结构,只要是稍微懂一点DIV+CSS知识的人就可以轻松的用Zblog做出自己想要的效果。这一点有点像是wp的风格,做界面就像是堆积木一样简单!也许是因为Zblog的作者是同我一样的在校大学生,它更加了解我们需要的是什么!

虽然现在的Zblog已经失去了很大一部分用户群,但也正是因为这样,才保持了它独有的风格和气质,没有Lbs2那样的不入流,也没有Pj那样的乌七八糟。它就是一款简单实用而富有个性的Asp程序吧!

至于wp那样的Php程序已经成为世界通用的博客程序了,我也试着用过一段时间的Php+sql,但是始终感觉没有Asp那样的方便简单。有人说Asp必将被Php取代,我觉得那才是无聊的言论,想象Asp标准是谁定出来的?除了发展,它没有其他的路可以走!