php,php info,php news,php framework
最近折腾了下pagespeed,因为使用的是openresty,所以过程稍微复杂了一些，笔者使用的是oneinstack,因此直接通过其upgrade.sh脚本来升级安装。 1. 首先下载pagespeed，然后放在oneinstack的src/pagespeed目录下 wget https://github.com/apache/incubator-pagespeed-ngx/archive/v1.13.35.2-stable.tar.gz 2. 下载需要的安装包: CentOS: sudo yum groupinstall “Development Tools” Ubuntu: sudo apt-get install build-essential 3. 接着修改include/upgrade_web.sh […]
安装好了memcacheD，如何通过php来连接之，测试是否正确运行呢？下面这段代码可以帮助我们测试。注意，我们使用的是memcacheD. $cacheServer = new Memcached(); //create memcacheD instance $cacheServer->addServer(‘127.0.0.1’, 11211); //connect to memcacheD server $cacheServer->set(‘uname’, ‘flower’); // add key and
用了一款开源的php应用，在替换原有的memcache为memcacheD的过程中出现了一些问题。因为程序在linux server上，本地又没有php环境，没法很好的debug。于是各种搜下找到了xdebug.在笔者重装系统之前，曾经在windows下使用过xdebug，配合PHPStorm，很是方便。那么Linux下如何使用呢？ 1. 下载xdebug: https://xdebug.org/download.php 2. 下载后编译，这里有两点要注意 a: xdebug需要phpize的支持，因为你要检测你是否已经安装了phpize。 b:编译时候除了–prefix还需要指定phpize的路径 –with-php-config=/path/to/php-config。 确定好了上述两点，编译之。 下面是我的编译过程： ./configure –enable-xdebug –with-php-config=/usr/local/php/bin/php-config make -j4 && make
很多时候不遇到问题，是不会想着去解决问题的，WordPress加速问题对与笔者这种懒惰的家伙亦是如此。昨天突然发现wordpress打开超级慢，于是乎开始了问题寻找之旅。首先linode后台，查看longview.关于什么是longview，可以看看笔者之前的文章Linode Longview简单使用，首先发现httpd占用cpu的确蛮高，会不会是这个问题呢？不管是不是，能想办法降低下cpu的负载吗？带着这个问题第一反映就是静态化，于是乎第一个给力的插件出现了WP Super Cache,这货可以在对应的目录下生成wordpress对应的纯静态页面，这样，负载将直接从apache转嫁到nginx上。不必php引擎解释，不必mariadb查询，不必….还可以js,css各种缓存。总之，静态话好处多多，速度很快！(其实说到静态化，随之而来的另一个方案就是CDN，静态化后很多资源都可以通过CDN来加速，抛开后台动态解析以及数据加载等开销，单单CDN一项就值得我们这样去做！) 静态化之后，再次尝试访问歇歇脚，发现仍然卡顿。呃。。。这不应该啊。监控一下，发现1. Google CDN js脚本加载缓慢， 2.Gravatar加载缓慢。原因比不说，大家都知道。那么有么有办法解决呢？于是乎第二个给力的插件出现WP Acceleration for China，从下面的图中可以看到，加载js地址已经从google cdn变为ajax.lug.ustc.edu.cn。如此一来速度已经飞起。
今天看linode后台，发现一个叫做Longview的监控工具。因为最近重新折腾了下vps，所以想看看到底性能怎么样。于是乎安装Longview尝试了一下。Longview分为免费版和收费版。收费版本为Longview Pro，刷新周期短（貌似为1分钟刷新一次），可监控的节点也比免费节点多，免费的为10个。当然还有其他限制，各位有兴趣的看官老爷可以自己去看看喽。安装过程十分简单，按照后台提示即可。具体使用方法可以参考这里：https://www.linode.com/docs/platform/longview/，同时值得注意的是如果apache端口修改过，那么对应/etc/linode/longview.d/Apache.conf下面的内容也要修改，比如： location http://127.0.0.1：81/server-status?auto 最后附上一张简单的Longview效果图，确实很好看！:)
编译php5.4，碰到一个妖异的错误。 undefined reference to icu 55， icu4c是我手工编译的icu4c-55_1，于是乎卸载掉，重新编译最新版本的icu4c-57_1,安装臂弯重新编译php5.4结果继续出现undefined reference to icu 57。搜索了半天，终于发现貌似是在之编译其他软件时候安装了CentOS7.2源里的icu4c,只要干掉默认安装的即可解决问题。从下面的查询可以看到，源里的版本是50.1.2，而我使用的是55.1和57.1,但编译过程中会自动去寻找系统安装的50.1.2版本，不知道是否是因为我没有指定icu目录的问题，有时间再编译一次试试。 yum list |grep icu icu.x86_64 50.1.2-15.el7 base libicu.i686 50.1.2-15.el7
WPRobot 3.4.1发布的消息已经通过WPRobot自带的升级提示功能发布出来了，关注WPRobot的朋友可以通过官方给出的升级地址获取最新的WPRobot 3.4.1下载地址下载升级使用。本次发布的WPRobot 3.4.1是WPRobot 3.4系列的第一个升级版本（小版本的升级），从官方给出的change list来看算是一个不折不扣的bug修复版本，其实WPRobot之所以能名列各种采集插件之首，最主要的原因还是起使用方便更新速度快。毕竟采集源的变化是相当之快的，如果更新赶不上变化，那采集出来的可绝对就是垃圾了。为了应对目前Google针对垃圾站的处理措施，即便是做垃圾站，也要看起来不像垃圾站才可以（囧一个，看起来不像垃圾站的垃圾站是什么站呢？） WPRobot 3.4.1主要改进包括： WPRobot 3.4.1修正了goarticles.com采集过来的文章头部包含多余空白的bug WPRobot 3.4.1修正了PR模块中一些错误信息 WPRobot 3.4.1一些采集过程中细微的调整和bug修复（这就是WPRobot最大的优势所在，根据采集源变动及时调整采集规则，如果你用pipes或者你手动写规则，那你就需要持续关注这个） WPRobot 3.4.1修正了WP Robot Control Center与W3 Total
WordPress 3.0.5下载地址发布了，这是WordPress 3.0系列第五个小版本的更新，关注WordPress 3.0系列的朋友可以直接去官方获取最新的WordPress 3.0.5下载地址下载升级，当然也可以通过WordPress后台的升级功能直接升级到最新的WordPress 3.0.5了。（不过笔者发现由于虚拟主机的各方面原因，后台升级有可能会导致一些比较棘手的问题，因此直接下载最新版本覆盖貌似是一个不错的选择） 从官方给出的说明来看，本次发布的WordPress 3.0.5是一个安全更新版本，而WordPress 3.0.5面向的用户群体是所有WordPress 3.0系列用户。值得一提的是，如果当前WordPress中包含了不信任的用户的话，那么强烈建议升级到最新的WordPress 3.0.5。同时官方也表示本次更新对WordPress 3.0的安全系统进行了进一步的强化，因此所有WordPress 3.0用户最好都更新到最新的WordPress 3.0.5。 在WordPress 3.0.5发布的同时，WordPress 3.1 RC4也悄然发布，相信过不了多久WordPress 3.1正式版应该就会和大家见面了，如果等不及想尝鲜的朋友可以试试WordPress 3.1
phpVirtualBox 0.42下载地址发布了，喜欢VirtualBox的朋友可以直接去phpVirtualBox在Google code上的站点获取最新的phpVirtualBox 0.42下载地址下载试用。说起phpVirtualBox或许很多朋友都比较陌生，没错即使是笔者也是第一次看到这个有趣的东东。不过从名字来看给笔者的第一感觉就是将virtualbox和php联系在一起了。没错phpVirtualBox就是一款试用php实现的virtualbox控制台，也可以说是virtualbox的web版的用户接口。看到这里，笔者在此感慨一下，其实在笔者试用vmware server 2.0的时候，vmware已经将用户接口转移到了web上。印象很深刻的当时vmware server 2.0针对firefox和ie都提供了对应的插件，用户只要在浏览器上安装了对应的插件，就可以通过浏览器直接访问虚拟机了，可谓方便之极。不过随着Firefox的升级vmware的Firefox web console迟迟没有升级的动静，导致笔者只能用ie访问了。没想到时隔几个月的时间，笔者在此看到的就是virtualbox的web控制台了，是在是感慨开源力量的强大，向phpvirtualbox作者致敬一下。 或许有很多朋友还不知道virtualbox到底是什么，这里扫盲一下。但凡听说过虚拟机的朋友或许都知道vmware吧，没错vmware是老牌的虚拟机产品，而virtualbox则是原Sun公司推出的一款开源的虚拟机产品。后来由于Oracle收购了Sun于是乎VirtualBox更名为Oracle VM VirtualBox，网站也仍然没有变化。就在笔者撰写此文的同时笔者也看到在VirtualBox官方也挂出了phpVirtualBox的网站链接，不知道是不是VirtualBox的开发人员也有参与phpVirtualbox的开发呢？总之phpVirtualBox的确是被virtualbox认可的一款优秀的web console，有了它远程操作virtualbox将不会成为选择虚拟机软件的一大屏障，同时也让VirtualBox使用更加轻松，或许这也是Oracle想让VirtualBox更加商业化的一颗棋子吧。毕竟开源产品本身很少有能做到收费软件那么好的服务的，但很多开源产品核心和思想都十分优秀，欠缺的只是进一步的完善和支持，如果Oracle这么做了，那么它收购的所有开源产品都将成为更加优秀的商品，或许这就是Oracle的经营之道吧。Oracle果然会赚钱。 phpVirtualBox 0.42下载地址： phpVirtualBox 0.42下载
Dreamhost是国外一家十分不错的空间商，笔者一直蹭朋友的空间来使用的说感觉十分不错，歇歇脚就是放在Dreamhost上的。不过今天早上起来，因为调整博客模板发现居然爆出了一个诡异的错误： Fatal error: Cannot redeclare class wpdb in wp-db.php on line 53 按照笔者的想法，多半是因为升级插件或者版本导致的问题,不过折腾了半天发现居然让我重新安装，晕。。。，不过莫怕，这种情况笔者也不是第一次遇到了，笔者在若干天之前曾经备份过一次博客，此时正好拿出来恢复，哈哈。于是花，备份现有的版本呢，更换之前的备份版本。折腾了5分钟，恢复到了之前版本，结果发现问题依旧。这次可有点棘手了（其实此时基本已经可以排除程序的问题了，因为毕竟之前是好用的，现在出问题，肯定是程序后面的问题，比如Database）。 因为备份都没有搞定该问题，于是乎笔者开始求助搜索引擎，疯狂google。20分钟过后，笔者发现虽然有人提出此问题，但是大部分都没有回答，郁闷ing…。让笔者自己去分析wordpress代码，是在是没心思和力气，于是与笔者寄希望于最后的phpmyadmin查看下数据库。这一看终于明白问题出在哪里了，居然笔者的MySQL数据库被清空了，里面一张表都没有了，抓狂ing… 不过笔者的wordpress安装了dbmanager，会自动备份数据库，不过是昨天的数据，想想也不错了，正在准备动手恢复的时候，突然发现dreamhost的mysql管理像中，有一个restore选项，这意味着dreamhost应该提供了某种回复机制，点进去一看，顿时欣喜若狂，里面居然有16小时之前的数据库备份，太好了。这里不得不说的是dreamhost提供了50G的备份空间，这让我们几乎无需手工备份mysql了，选择恢复方式并恢复，2分钟后笔者的blog再次正常访问了。