Loading...

livewriter无法发表日志的两个原因

Filed under: Wordpress,网站技术 — 江东 @ 2009-05-14 12:03:22 只有1条评论

很多朋友都问,为什么我的blog无法用livewriter来发表,总会提示这样那样的错误。一般来说,你应该注意以下两点,看是不是出在这两个问题上:

1.wordpress后台是否已经允许远程发布

进入wordpress后台,点击setting->writing,如下图所示:

livewriter无法发表

把这两个

Atom Publishing Protocol    
XML-RPC

给enable了就可以了,如下图所示:

livewriter无法发表

2.服务器是否有内存限制过小

因为你在livewriter中嵌入了大图片,livewriter发布到服务器的时候需要占用很大的内存,当内存不够的时候,就会提示出错,这个时候,你除了将图片外连接外,一点办法都没有

wordpress无法打开日志页面解决办法

Filed under: Wordpress,网站技术 — 江东 @ 2009-05-11 16:30:17 才(3)条评论

最近没啥可写的,与其在gtalk中反复回答同样的问题:“我转移了wordpress之后,为什么首页可以打开,日志页面无法显示”,不如我自己写几句话来吧这个问题的解决办法保存在搜索引擎上。

好多朋友在转移了wordpress的时候,发现一切都正常,但就是访问子页面或者日志页面的时候,显示页面找不到,出现搬家后的404错误,其实出现无法打开日志页面的原因90%在于.htaccess不正确,若是你的wordpress永久链接又不是默认的格式,那么可以肯定99%是这个原因导致了。

修改起来很简单,进入wordpress后台,然后进入永久链接修改区域,如本blog对应区域的链接地址是http://www.storyday.com/wp-admin/options-permalink.php,点击更新永久链接地址即可。

其实,导致这个的原因在于htaccess没有更新,上面的操作就是更新这个东西。

wordpress 500 错误处理

Filed under: Wordpress,网站技术 — 江东 @ 2009-05-04 19:59:14 才(24)条评论

到目前为止,我遇到了不少于10次关于wordpress 500 错误的问题。提问者那个焦急啊:“东哥,怎么办,我的网站下所有页面访问都500错误了”,“糟糕,wordpress全部500错误了,我啥都没有动啊”。

说自己啥都没有动,那是假的,难道wordpress会凭空500错误,要么自己安装了urlrewrite相关的插件,要么就是自己修改了.htaccess。在perl CGI流行的年代,500错误是非常普遍的,但是wordpress 500错误多半是由于.htaccess描述错误引起,所以解决办法也就从.htaccess入手。

备份原来的.htaccess(名字就是.htaccess,你可能会在某些ftp软件下看不到此文件,可以通过cpanel文件管理器查看),新建一个.htaccess,修改属性为0666,然后登录wordpress,在后台的永久链接管理中(如 http://www.storyday.com/wp-admin/options-permalink.php),更新永久链接即可。

基于wordpress的cdrzl.com

Filed under: Wordpress,网站技术 — 江东 @ 2009-04-19 17:54:13 才(21)条评论

这几天在珠三角推广本公司,所以网站还要做得象样才行,于是就借用了http://dickeydong.cn/朋友的一个模板,拿来进行修改。

cosbeta自己没有美术功底,说严重点就是没有任何美术细胞,因此,要做一个像样的风格出来,就只能通过修改别人的模板来实现了(本blog的模板也是靠一个朋友帮忙画图,自己用css实现的)。

经过一天的修改,总算是可以面世了。

cdrzl.com是cosbeta所在公司的站点,cd便是成都的缩写,rzl是蓉之旅的缩写。

由于是公司的站点,所以就不再底部写上powered by wordpress了,同时,借此机会感谢cdrzl.com模板雏形来源的作者dickeydong

wp-ext-cache

Filed under: Wordpress,网站技术 — 江东 @ 2009-04-06 10:31:49 才(24)条评论

那些梦想全站缓存的朋友,现在cosbeta将这个beta版本的wp-ext-cache外挂(不叫插件,看看后面的用法介绍就知道了)推出来给你们试用了。

插播废话:实话实说,需要全站缓存的个人blog很少,除非你的日IP达到5000以上你才有必要正二八经的考虑用这个工具(改造起来有一点麻烦,特别提醒浮躁人士,请一定按部就班的操作)。

wp-ext-cache介绍

wp-ext-cache,从命名上可以看出,该缓存属于外部缓存,配合插件,达到最大的缓存作用,若您网站的访问量不是很大,可以单独安装cos-html-cache.不建议单独使用wp-ext-cache,单独使用只能定时更新缓存。

将wp-ext-cache和cos-html-cache(从本文下载改造后的cos-html-cache)一起配合使用,配合之后的特点如下:

  1. 可以缓存非html结尾的的post;
  2. 发布日志、编辑日志、删除日志、评论产生、评论删除这些事件将触发首页和single post缓存的更新,因此可以说此插件更新内容接近实时状态;
  3. 若post页面的url非html结尾,那么在上述条件下触发缓存更新的同时,post页面也支持自动定时缓存更新;
  4. 可以缓存全站,缓存定期更新,默认定期更新时间为5分钟(所以对于访问量不大的blog,blog的每个页面的绝对达不到5分钟就被访问一次,假设你的blog有100个常用页面,若是5分钟就平均有一个页面被访问,那么日访问量将会是100/5*60*24=28000);
  5. 可以设定缓存更新时间,时间紧张,未做到wp的后台,只能在php文件中直接修改;
  6. 不缓存feed页面,不缓存404页面,防止蜘蛛疯狂抓取404(请保证wordpress模板文件中存在文件404.php,并且内容有Error 404字符),导致服务器上过多的垃圾缓存文件;

wp-ext-cache安装方法

使用方法(由于是外挂而不是插件,所以请做好心理准备):

  1. 下载这三个文件cos-html-cache.zip  index.zip  wp-ext-cache.zip
  2. 像安装普通插件一样安装cos-html-cache,若不想缓存首页,请打开cos-html-cache.php 修改define(‘IS_INDEX’,false); false表示不缓存首页,反之则缓存;
  3. cos-html-cache修改的参数有2行:

    define(‘IS_INDEX’,false);// fasle表示首页不生成html缓存(意味着可以php缓存) true则反之(优先级最高)

    define(‘IS_HTML_CACHE’,true);// false表示不创建html文件(不创建的原因在于你的html路径冲突,或者服务器就不支持建立html文件)

  4. 将wp-ext-cache文件夹放置在wordpress根目录下
  5. 将wp-ext-cache的cache文件夹属性设置成0777;
  6. 备份好原来wordpress的index.php用下载下来的index.php覆盖之;
  7. 非html缓存的失效时间在wp-ext-cache/ext_cache_cfg.php中 ,修改define(‘WP_EXT_CACHE_TIME’,600); 600表示600秒之后,其他非html文件缓存自动被更新。

其他注意事项

搞定,任意打开一个页面,看html源代码便可确认是否缓存。

注意:若不想缓存404页面,请一定在当前theme目录下创建一个404.php文件,并且文件内容中包含Error 404。

全站缓存,高于任何一款基于文件缓存的插件,只有绕过插件机制,才能如此,所以,才会有得如此多的步骤。

对于那些需要手动更新缓存的建议,可以在留言中提出来。某些缓存更新的请仔细再仔细思考一下,因为它可能是不必须的。

补充:缓存肯定会导致及时更新的问题,若是开启了html缓存,评论框的处理会更加理想

新的wordpress缓存思想

Filed under: Wordpress,网站技术 — 江东 @ 2009-04-04 22:17:05 才(15)条评论

以前的一篇日志中,cosbeta认为,凡是插件级(cos-html-cache除外)的缓存都不会有多大的效果,毕竟他们都无法绕过wordpress的预处理。不相信的话,可以做一个实验,在一个页面已经缓存的情况下,修改wp-config.php文件,故意将数据路的信息修改成错误的信息,然后刷新缓存的页面,若该页面依然正常,那么此缓存则效率很高,否则,缓存效果并不明显。

所以,今天晚上cosbeta想到一种新的思路,那就是对wordpress做外部缓存。

配合cos-html-cache使用,此外部缓存仅仅缓存非post页面,缓存的方式如下(仅仅针对非single post页面):

  1. 检查页面html中是否有cos-html-cache的缓存flag”<!–cos-html-cache-safe-tag—>”,有则将缓冲区文件写入缓存,否则利用cos-html-cache缓存;
  2. 访问wordpress的时候,检查缓存是否存在或者过期(不会通过插件机制检查,因此若缓存被引用,即使数据库关闭,页面依然正常),若过期则写入新的缓存,否则,直接调用缓存文件;

这样便可实现wordpress的全站缓存,这样的缓存有什么作用,下面我做一个计算:

假设blog的访问量是1w+,非静态化文件访问是1000;

未缓存:按照wordpress的数据库使用情况看来,一天数据库查询绝不少于30000次;

使用缓存:(假设缓存时间为5分钟):一天数据库查询的次数则为 24*60/5 = 288次;

由于single post依然采用cos-html-cache,因此对于评论之类的实时显示毫无影响。

今晚找可能吧和我自己的blog做小白鼠,测试一下。

本站html之外的文件也都缓存,欢迎大家查看(不是.html结尾的页面)源代码,代码最后一行会显示缓存生成的时间。

补充说明:这个插件其实没有那么高深,要不是CPH出错报告关闭了的话,10分钟便可搞定(多亏PEAR)。关键是测试,看看有没有想想不周到的地方。

cosbeta的图片host在哪里的?

Filed under: Wordpress,网站技术 — 江东 @ 2009-03-29 23:06:17 才(31)条评论

这几天一直很矛盾:要不要做一个host图片的服务?原因很多:1.哪里能找到海量的服务器(别相信那些不限c磁盘和流量的虚拟主机);2.即使采用自己的购买的虚拟主机做了这个服务,流量依然来自购买的虚拟主机,无法节约带宽(过段时间研究一下amazon s3 和ec2,看利用他们的服务器是不是要带宽要便宜一点);3.有现成的live和google picasa图片存储(他们都支持外链)我做这个还能有多大意义;4.我做的host图片服务也未必能保证不会撞墙。

今天和一个朋友聊天,这位写了多年blog的朋友还不知道picasa是google的服务,所以我觉得有必要介绍一些比较靠谱的图片存储服务,他们是livespace,google picasa和flickr。为什么不考虑国内的服务呢?、他们速度快,使用方便,又不会被和谐?但是他们改变策略和随时停止服务的几率会比国外同样服务的站点撞墙的几率要大,特别是google的服务一般只是定点撞墙(万一撞墙了,cosbeta也有解决办法让你host在国外的wordpress正常显示图片)。

cosbeta所用的图片服务:

  1. FlickrYahoo旗下的站点,稳定性不错,虽然曾经一度因为敏感图片被和谐过,但是现在已经解放了么,比较靠谱,cosbeta在2007年的时候用过它抛弃过它,但是现在觉得还是可以继续使用,因为正如那篇日志下的某个评论说的那样:俺对广大人民群众有信心…还是先留着吧
  2. google picasa.cosbeta 99%的图片都host在这个服务上面,一年建立一个文件夹,速度快、上传文件方便,cosbeta主力推荐。
  3. Live space.最近cosbeta图片都存储在这个上面了。不是别的原因,是因为cosbeta采用了livewriter发布blog,livewrite编辑图片的功能很强大,特别是截屏图片。所以对于图片多的日志,cosbeta一般先发布在live space上,然后直接copy过来再次发布在本blog上,具体方法参见此日志

基本上,cosbeta相关blog的图片处理就是这样的,不知本blog的访客们,你们都是如何host博客图片的呢?

cos-html-cache升级到2.7.3

Filed under: Wordpress,网站技术 — 江东 @ 2009-03-24 13:43:36 才(169)条评论

上一次的升级解决了两个问题:留言框中会自动记录创建静态的访客信息(这样会将访客不愿意公开的信息如email地址公开给每一个访问缓存页面的访客,具体问题描述如下引用部分)和加密日志的问题。

当博主注销登陆之后,再次查看post页面,页面上的留言框里面居然还保留着最后一个创建缓存的访问者的信息。当然,这个问题在cosbeta自己的 blog不存在,因为cosbeta自己改动了一下留言框,不用php的方式读取留言者的cookie信息,所以缓存的内容中就没有任何记录留言者的 html代码存在了。

上次用js重置评论发表表单的方法解决了第一个问题,然而由于源代码中依然有记录信息,所以一旦用户浏览器无法执行js重置部分,那么访客依然可以看到上一次创建静态页面的访客信息(描述起来咋这么拗口!)。

不管怎样,意思就是cache记录了本不应该记录的东西,上一次的改版用js脚本重置了,而本次的改版是直接在源代码中抹掉这个不该记录的信息,这样就彻底解决了这个问题。

鸣谢(排名不分先后):

  1. 可能吧提出问题和坚持在他龟速的网络下为我刷新测试;
  2. 堂全程提供正则表达式技术支持(不会正则表达式居然还敢说自己会php?汗!);

下载地址:cos-html-cache 2.7.3