路途志

wordpress换域名后，博客无法访问了，改了所有的能改的配置文件，错误依然。

看来问题只能在数据库里找了，研究发现在数据库中的w_options表，保存了老域名相关的信息。把

w_options表中option_value所有老域名的信息，更新成新域名后，问题解决。

晚上访问出差交友网，吓一大跳，首页上好几张露点的图片，还有很多赤裸裸的挑逗性广告。按照现行扫黄打非规定，完全可以定性为黄色网站了。

赶紧到后台把那些穿衣服太少的图片删除，并禁用对应的账号。尽管这些ID并不一定会再次上传这些流氓图片。

删除完后稍稍放松了一下，突然想起如果那些扫黄打非工作者，亲自到网站上来发裸照怎么办？

难道我可以相信他们肯定不会这么干？NO WAY！

于是细细研究起uchome的后台，希望它能够提供这个本来就应该提供的功能-发布前审核，遗憾的是没有任何一个功能可以让管理人员在文章、图片、动态、活动等等被在公布之前审核一下。

在这点上，康盛表现的完全不像一个国内的企业，它表现的更像是外企或者火星来的企业一样令人不解。难道你可以像一个外国人一样装作不懂中国国情吗？难道你假装不懂就可以逍遥“法”外吗？

在此需要提醒康盛和广大的UCHOME使用者：没有这个功能是很危险的，轻者被警告、重者被喝咖啡、严重者则违反了刑法 第三百六十四条第一款、第四款。

 

什么是404页面

如果碰巧网站出了问题，或者用户试图访问一个并不存在的页面时，此时服务器会返回代码为404的错误信息，此时对应页面就是404页面。404页面的默认内容和具体的服务器有关。如果后台用的是NGINX服务器，那么404页面的内容则为：

404 Not Found

---

nginx/0.8.6

 

为什么要自定义404页面

在访问时遇到上面这样的404错误页面，我想99%（未经调查，估计数据）的用户会把页面关掉，用户就这样悄悄的流失了。如果此时能有一个漂亮的页面能够引导用户去他想去的地方必然可以留住用户。因此，每一个网站都应该自定义自己的404页面。

NGINX下如何自定义404页面

IIS和APACHE下自定义404页面的经验介绍文章已经非常多了，NGINX的目前还比较少，凑巧我的几台服务器都是NGINX的，为了解决自家的问题特地对此作了深入的研究。研究结果表明，NGINX下配置自定义的404页面是可行的，而且很简单，只需如下几步：

1.创建自己的404.html页面

2.更改nginx.conf在http定义区域加入：

fastcgi_intercept_errors on;

3.更改nginx.conf在server 区域加入：

error_page 404 = /404.html

4.测试nginx.conf正确性：

/opt/nginx/sbin/nginx –t

如果正确应该显示如下信息：

the configuration file /opt/nginx/conf/nginx.conf syntax is ok
configuration file /opt/nginx/conf/nginx.conf test is successful

5.重启nginx

1. kill -HUP  `cat /opt/nginx/nginx.pid `

 

配置文件实例：

……

http
{
include       mime.types;
default_type  application/octet-stream;

charset  gb2312;
server_names_hash_bucket_size 128;
client_header_buffer_size 32k;
large_client_header_buffers 4 32k;
client_max_body_size 8m;
sendfile on;
tcp_nopush     on;

keepalive_timeout 60;

tcp_nodelay on;

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;
fastcgi_intercept_errors on;

gzip on;
gzip_min_length  1k;
gzip_buffers     4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types       text/plain application/x-javascript text/css application/xml;
gzip_vary on;

#limit_zone  crawler  $binary_remote_addr  10m;

  #65的配置信息
      server
{
   listen       80;
   server_name  www.65.la 65.la *.65.la;
   index index.html index.htm index.php;
   root  /opt/www/65;
   location ~ .*\.(php|php5)?$
   {     
     #fastcgi_pass  unix:/tmp/php-cgi.sock;
     fastcgi_pass  127.0.0.1:9000;
     fastcgi_index index.php;
     include fcgi.conf;
   }
   error_page  404 = /404.html;

#502 等错误可以用同样的方法来配置。
   error_page   500 502 503 504 = /50x.html;
   ocation = /50x.html {
            root   html;
        }
   log_format  65  ‘$remote_addr – $remote_user [$time_local] "$request" ‘
              ‘$status $body_bytes_sent "$http_referer" ‘
              ‘"$http_user_agent" $http_x_forwarded_for’;
   access_log  /opt/nginx/logs/65.log  65;
}

……

 

 

注意事项：

1.必须要添加：fastcgi_intercept_errors on; 如果这个选项没有设置，即使创建了404.html和配置了error_page也没有效果。

fastcgi_intercept_errors

语法: fastcgi_intercept_errors on|off

默认: fastcgi_intercept_errors off

添加位置: http, server, location

默认情况下，nginx不支持自定义404错误页面，只有这个指令被设置为on，nginx才支持将404错误重定向。这里需要注意的是，并不是说设置了fastcgi_intercept_errors on，nginx就会将404错误重定向。在nginx中404错误重定向生效的前提是设置了fastcgi_intercept_errors on,并且正确的设置了error_page这个选项（包括语法和对应的404页面)

2.不要出于省事或者提高首页权重的目的将首页指定为404错误页面，也不要用其它方法跳转到首页。

3.自定义的404页面必须大于512字节，否则可能会出现IE默认的404页面。例如，假设自定义了404.html,大小只有11个字节（内容为：404错误）。用如下两个不存在的地址去访问：

http://www.65.la/no 将会调用自定义的404.html

http://www.65.la/notfound：将会调用IE默认的404页面

Q12.将标题中指定的字符串删除：

UPDATE phpcms_content SET title=REPLACE(title, ‘落伍投资’, ”);

Q13.查询内容中包含指定字符串的文章：
select contentid, content from phpcms_c_news where content like ‘%文章来源：落伍投资 %’

Q14.将文章内容中指定的版权信息替换。

UPDATE phpcms_c_news SET content=REPLACE(content, ‘(文章来源：路遇交友网‘, ‘(文章来源：落伍投资 http://www.65.la’);

Q15.虽然文章已经被删除，但是在搜索结果中依然出现该文章，怎么办？
因为phpcms_search表中依然保存了该文章的关键字，所以搜索关键字时会有该文章出现，但是点击链接会出现404错误。

delete phpcms_search from phpcms_search where data like ‘%mj%’

Q16.查询指定栏目的对应的内容列
select * from phpcms_c_news where content like ‘%落伍投资%’ && contentid in (select contentid from phpcms_content where catid =37)

Q17.查询所有栏目编号

select distinct from phpcms_content;

Q18.删除指定字符串中间的内容

select  CONCAT(LEFT(content,INSTR(content,’删除开始位置’)),RIGHT(content,LENGTH(content)-INSTR(content,’删除结束位置’)))

昨天路遇交友正式升级到UCHOME2.0。升级好后发现邮件邀请功能失效了，发送邮件后迟迟收不到。查看日志/uch/data/200907_smtp.php，有如下提示：

 

<?PHP exit;?>    2009-07-22 09:30:19        222.66.162.147    166    /do.php?ac=sendmail&rand=1248312618    (smtp.gmail.com:465) PASSWORD – 535-5.7.1 Username and Password not accepted. Learn more at…..

 

不知道为何升级会导致邮箱密码错误。

解决方案很简单：后台更新下用户名和密码，保存，更新缓存，邮件功能正常。

Q1:PHPCMS默认后台地址？
http://www.65.la/admin.php

Q2:如何更改PHPCMS后台地址为zhaozhishi.php ？

修改的方法为：进入到网站的根目录，找到admin.php，将名称修改为zhaozhishi.php

完成上一步还不行，还需要打开fckeditorfckconfig.js 文件，找到下面的内容FCKConfig.Adminpath = ‘admin.php’;  修改为 zhaozhishi.php 。两个地方的名称必须保持一致。

不过phpcms的安全性相当好，如果用LINUX系统的话完全没必要改后台地址。

Q3：PHPCMS默认管理员是？
phpcms

Q4:登录失败超过5次，ip被锁定，如何解锁？

连续登陆失败5此后，ip会被锁定，并提示：

“您的IP已经被系统锁定，1小时后将自动解除锁定”。

解决方法是，找到phpcms_times表，删除你的Ip对应的记录。

 

Q5:远程联接mysql服务器报错：

"D:\wamp\bin\mysql\mysql5.1.33\bin>mysql -h 222.73.48.42 -u root -p
Enter password: *********
ERROR 1045 (28000): Access denied for user ‘root’@’211.160.160.115′ (using passw
ord: YES)"

该错误说明你没有将权限赋予远端连接帐户，由于mysql的安全性在不断的提高，远程连接权限默认是不开放的，你必须自己开放权限。
在服务器上用mysql -h 192.168.0.1 -u root -p mysql命令登录mysql数据库,用如下命令授权：
GRANT ALL PRIVILEGES ON *.* TO root@localhost IDENTIFIED BY ‘password’ WITH GRANT OPTION;
GRANT ALL PRIVILEGES ON *.* TO root@127.0.0.1 IDENTIFIED BY ‘password’ WITH GRANT OPTION;
GRANT ALL PRIVILEGES ON *.* TO root@’%’ IDENTIFIED BY ‘password’ WITH GRANT OPTION;
例如： 
GRANT   ALL   PRIVILEGES   ON   *.*   TO   root@’%'   identified   by   ’123456′  
注意：自己根据情况修改以上命令中的 “用户”“ip地址”“密码”。

Q6:访问落伍投资,一直提示"首页尚未生成，请点击这里进入后台设置相关参数并发布网页"

解决方案：删掉网站根目录下index.html，并刷新首页。

Q7:PHPCMSSP1首页，网站公告区域出错，报mysql访问错误。

没找到解决方案，我把它从首页移除了。公告的作用可以用置顶文章来取代。

Q8：后台fckeditor编辑框无法使用，报错：fckeditor 没定义/fckeditor is not defined/fckeditor is undefined;

出这个问题的原因是PHPCMS\fckeditor\editor\lang\zh-cn.js 的字符格式出了问题。

打开网站文件 PHPCMS\fckeditor\editor\lang\zh-cn.js 用记事本打开后再点一下保存按钮后关闭，这个问题就解决了，简单有效。

Q10:digg出错，digg数不显示并且出现长串的链接地址。

解决方案： 把digg功能网站移除，这个功能华而不实。

Q11:PHPCMS如何添加管理员？
刚接触PHPCMS时，在添加管理员的问题上遇到了困哪。按照惯例，管理员应该在会员管理模块添加、删除、更改等。但是我在后台的会员管理模块中杀了七进七出，也没找到入口。

后来在控制面板里找到了添加管理员入口，答案就是：我的面板|添加管理员。

问题解决了，郁闷了半天。匪夷所思的设计，令人崩溃的体验。

使用Wordpress快一个月了，在配置过程中常常被乱码困扰。下面总结下在哪些情况下会遇到乱码：

1.修改模板后，如果输入中文可能产生乱码。

2.数据迁移后、换主机后可能产生乱码。

3.发送邮件，主题、正文，发件人等字段都可能出现乱码。

4.wordpress版本升级可能导致乱码。

5.使用老外开发的插件可能会遇到此问题。

6.用Windows Live Writer等离线工具写博出现乱码。

 

以上六点基本涵盖了使用wordpress过程中可能遇到的所有乱码问题，如有遗漏敬请留言提示。下面一篇文章具体说明为啥会出现乱码、以及每种情况下的解决方案。

Comsenz推出UCHOME，让所有向往SNS的站长像打了鸡血一样一窝蜂的扑了上去。Comsenz想的很周到，不光替站长考虑，替自己考虑的也很周全。为了避免站长们空虚寂寞之余自己脑袋发热胡乱开发各种插件，Comsenz十分体贴提供了一个有趣的平台，它就是漫游。第一次看到漫游的设计思想，我很佩服Comsenz的深谋远虑。

所有的第三方插件都通过漫游平台来提供，最后的唯一的赢家是Comsenz,康盛将拥有互联网上最为庞大的SNS用户群体。数十万个使用uchome的站长们和无数的应用开发人员将把数以亿计的用户乖乖的送到Comsenz的手心。站长们辛辛苦苦做得工作，等于替康盛做了嫁衣。但是，这些都不是最关键的，最要命的是漫游的运营机制有致命的缺陷，这个缺陷会把通过漫游使用了各种小应用的站长们拖向不归路。

SNS站能否取得成功，取决与四个环节。

1.初期推广，获取初次流量。

2.内容改进，吸引用户回头。

3.提高网站可玩性，吸引用户参与。

4.提升网站内在价值，实现盈利。

对于第一个环节，漫游完全帮不上忙，uchome本身在网站宣传推广方面也没有独到之处。

第二个环节正是漫游的用武之地，林林总总的小应用充分满足了用户的各种需要，有些用户甚至专门玩某个应用才会光顾网站。

在第三个环节上,漫游确实起了很大的作用，很多用户很愿意去参与一些趣味性的游戏，比如“开心农场”、“抢车位”等。但是这也恰恰是一个隐患。如果一个SNS站点里的用户活动都是集中在这些通用的小应用上，那么这个网站绝不具备长期生存能力，非常容易被用户抛弃。一个网站的可玩性应该是独一无二的，一个网站的可玩性应该是无法替代的，一个网站的可玩性应该是由自己独立提供的，并且完全独立掌控的。从这个意义上来说，漫游是裹着糖衣的毒药，尝起来甜，吃起来害死人。

在第四个环节上，漫游起到的是完全相反的作用。前篇一律的应用，数十万家网站都具有的功能，对于网站内在价值的提升没有任何帮助。

有的SNS站，同时启用了数十个漫游应用。网站里所有的动态信息都是由小应用产生的，看起来网站很繁荣，很活跃。但是这些信息都是无效的信息；这些用户活动都是无效的用户活动；这些应用都不是网站价值的真实体现。我认为抛弃漫游对于广大站长来说，是早晚必须要做的事。这件事与其晚做，不如早做，最好现在就做。不要沉迷于漫游应用带来的虚假繁荣，不要依赖漫游应用吸引用户的参与，它会害死你的站。

今天在做UCHOME开发时,遇到一个新问题，在有些情况下在页面顶部会出现下列错误信息：

Warning: array_keys() [function.array-keys]: The first argument should be an array in /www/uch/source/function_common.php on line 1356

Warning: Invalid argument supplied for foreach() in /www/uch/source/function_common.php on line 1356

这个错误提示，在下列情况下会出现：

1.所有用户在非登录状态下访问首页都会遇到这个错误。

这种情况可以通过后台更新缓存解决

2.部分用户在登录状态下，访问首页时会遇到这个问题。

每个用户登录时都会遇到，而且登录之后经过一些操作错误信息会自动消失，经过分析，找到如下规律:

新注册的用户、有消息未查看的老用户会遇到这个问题。没有未查看的通知、消息、留言的用户则不会遇到这个问题。

这是警告信息，不会给网站运行带来太大影响。但在顶部出现这个错误提示，对于用户来说是个很差的体验，可以将common.php中的：

define(‘D_BUG’, ’1′);

改为

define(‘D_BUG’, ’1′);

这样就可以避免在用户面前呈现这些代码了。

摘要：

这是Nginx的基础模块，它提供了最基本的http处理功能。

指令：

指令：daemon

语法: daemon on | off

默认值: on

例：daemon off;

在正式环境下不要使用daemon和master_process指令，这些选项只能用于开发环境。不过你可以放心的在正式环境下将daemon off和runit/daemontools一起使用，不过这种用法会在以后的升级中给给你带来麻烦，你将无法

平滑的升级到新版本。master_process off则绝对不能使用在正式环境中。

指令：env

语法: env VAR|VAR=VALUE

默认值: TZ

上下文: main

这个指令用来定义环境变量集合，如下场合需要创建新的变量或者更改变量值：

1. 在实时环境下升级Nginx的时候
2. 启用内置Perl 模块的时候

如果没有明确的定义TZ的值,默认情况下它集成老版本的值，默认情况下，内置的Perl模块总是可以使用TZ的值。

例：

env  MALLOC_OPTIONS;
env  PERL5LIB=/data/site/modules;
env  OPENSSL_ALLOW_PROXY_CERTS=1;

指令：debug_points

语法: debug_points [stop | abort]

默认值: none

例：

debug_points stop;

在Nginx内部有很多断言，如果debug_points的值设为stop时，那么触发断言时将停止Nginx并附加调试器。如果debug_point的值设为abort,那么触发断言时将创建内核文件。

指令：error_log

语法: error_log file [ debug | info | notice | warn | error | crit ]

默认值: ${prefix}/logs/error.log

指定服务器错误日志存储的位置。

日志中默认的错误级别：

main部分：error

HTTP部分：crit

server部分：crit

Nginx支持将不同虚拟主机的日志存储在不同位置，这是个很有特色的功能。在lighttpd中，他们一直拒绝提供类似的功能。下面两个链接，提供了针对不同虚拟主机提供不同日志的例子：

SeparateErrorLoggingPerVirtualHost

mailing list thread on separating error logging per virtual host.

如果你在编译Nginx的时候，使用了—with-debug指令，你还可以使用：

error_log LOGFILE [debug_core | debug_alloc | debug_mutex | debug_event | debug_http | debug_imap];

注意：error_log off 无法禁用日志，这个写法将会创建一个名为off的日志文件。如果要禁用日志，请用下面的写法：

error_log /dev/null crit;

指令：log_not_found

语法: log_not_found on | off

默认值: on

上下文: location

启用或者禁用404错误日志，这个指令可以用来禁止Nginx记录找不到robots.txt和favicon.ico这类文件的错误信息。

例如：

location = /robots.txt {

  log_not_found  off;

}

指令：include

语法: include file | *

默认: none

用这个指令，你可以包含任何你想要包含的配置文件。从0.4.4开始，include 指令开始支持文件名匹配，

例如：

include vhosts/*.conf;

注意：直到0.6.7版本为止，include 文件的路径是相对于configure时由–prefix=<PATH>指令指定的的路径而言，默认情况下是/usr/local/nginx.如果在编译compiledNginx时你没有指定这个值，请使用绝对路径。

从0.6.7开始，include文件的路径实现归于Nginx配置文件nginx.conf的所在目录而言，不再是nginx编译时指定的路径。这个改进大大增加了include的灵活性。

指令：lock_file

语法: lock_file file

默认值: compile-time option

例如：

lock_file  /var/log/lock_file; 

如果Nginx是由gcc、Intel C++或者SunPro C++ 在 i386、amd64平台上编译的,Nginx将采用异步互斥进行访问控制。