我一直都觉得如果学习PHP，最好的范例就是discuz和wordpress，无论是架构还是语法规范，都有其可取之处。

从这里看到一个不错的项目正在孕育中——BackPress，是WordPress、BBPress程序的核心部分。

官方对这个项目的介绍为：“Core PHP libraries for your web applications.”但我觉得这个更像是一个开发框架，功能列表如下：

• Logging (via bbPress’ logging library) to file/database/other. Supports levels (notice, warn, fatal).
• User Roles management (generally used for access control to portions of your application).
• Schema parser (for comparing schema files to current/live databases).
• User management (including user meta data and DB schema to support it) for managing core user information and arbitrary other user-related data.
• Database Abstraction (including using multiple database servers, clusters and data centers)
• XML-RPC Server and Client operations for interfacing with other systems.
• Mail sending (via SMTP and sendmail, supports attachments)
• Password Hashing/Crypto
• AJAX Responses (standardized XML-based response mechanism for AJAX requests)
• User Authentication using built in crypto for passwords, plus secure cookie management out of the box
• JavaScript and CSS inclusion and dependencies management, including internationalization options for JS strings
• Error handling via objects which can report multiple errors at a time
• Full HTTP library (supporting core PHP HTTP operations, cURL and raw sockets for widest compatibility available. Includes cookie send/receive support)
• Object caching, including using memcached as a backend for semi-persistent storage
• Arbitrary taxonomy management (tagging, categories, other classification systems) with generic DB schema
• Generic options management for handling application-wide options/settings
• Compatibility functions to provide support for useful functionality which is not available in all versions of PHP
• A variety of core helpers for advanced string manipulation, simpler HTTP transactions, security (nonces etc), timezones and more
• Lots of formatting functions for handling strings of all kinds (HTML, typographic features, sanitization, etc)
• KSES: Full security filtering for HTML content
• Complete plugin API, provided via the ability to add “actions” and “filters” to your application and allow any plugin to hook into those places to modify output/perform actions.
• Shortcode API allowing for [bbcode]-style input from a user to be translated using arbitrary rules
• Pseudo-cron functionality, allowing you to fire off events within your application, triggered by visits/page-loads to approximate cron-type functionality

看看，用这些功能库能减少PHP WEB应用中不少的重复工作量（这些重复的工作量也是导致我无心继续开发自己的CMS和项目管理软件的主要原因）。

尽管目前该项目还没有正式版，但的确是一个值得期待的项目，不是吗？

相关文章

• 没有相关文章。

最近在研究openx2.8.2，作为国外老牌强劲的开源广告系统，还是很不错的，目前发现两点问题：

1.管理权限分配，一直没研究出来怎么去进行管理权限分配

2.官方自带的简体中文包存在大量乱码，稍后我会放一个我自己做的简体中文包出来

相关文章

• 没有相关文章。

这几天一直在琢磨这个问题，今天一次会上在白板上粗略了画了一下我的想法，会后抽了点时间自己整理了一下。

基本上这个架构也是按照标准的三层结构来设计的，如下图（点击看大图）：

传统web程序的开发模式基本只有2层：应用层和数据层，有理无理就直接到数据库里去操作（大部分web编程书籍都是这么教的）。

而引入接口层以后，只有对数据的添加、删除和修改是通过接口去数据库里操作，select操作则增加了一个数据缓存，可以大大减轻数据库的压力，而对于一般的大中型网站而言，恐怕更多的访问压力是来自select，而不是对数据的添加、删除和修改的交互性操作。原本，html静态化是解决办法之一，但这个解决办法面临的问题是一旦页面有所变更，则需要全部重新静态化，对于数据量较大的大中型网站，无异是一场噩梦——动静结合，反而能恰到好处。

接口身份验证：采用OAuth，可以做成通用的平台

接口规则：负责将接口方法函数按照select、update、insert、delete进行分类

接口数据缓存：设想是生成数据的XML静态文件，应用层只需要解析这些XML静态文件即可，而接口操作则是输出XML的字符串，可以做成通用平台。引入缓存数据周期，则可以保证不同的应用对于数据本身的实时性的要求得以满足。

接口操作：即实现接口方法函数，根据方法函数到数据库里进行操作，要么输出字符串为XML的结果集，要么输出字符串为XML的操作状态码以告知应用层update、insert、delete操作状态，譬如操作成功、无权限操作等等

应用层：根据业务逻辑的需要调用合适的接口去实现业务逻辑

原则上这样的设计，一方面能平衡网站访问量大带来的程序压力，一方面也能做到应用层与数据层无关。应用层可以采用任何一种开发语言(.net、PHP、java等)，而数据库也可以采用任何一种数据库(MS SQL SERVER、MYSQL、ORACLE)，对服务器操作系统而言，也能做到WINDOWS+LINUX的混合架构，发挥两种操作系统各自的优势。

时间有限，此图还有待完善，譬如可以结合网站的硬件架构。

相关文章

• 没有相关文章。

众所周知，采用ajax分页，会对SEO不利，因为数据都是从远程采用ajax调用的，而spider未必能找到这些数据。

找了一会，发现jQuery Quick Pagination这款分页插件不错，它的分页原理是对页面源码中已有的html标记进行分页。

比如可以采用这款插件，对页面中连续20个<li></li>标记进行每页5个<li></li>标记的分页。这样所有的数据其实都在html代码中，只是前端表现形式为ajax的分页。

demo：http://projects.allmarkedup.com/jquery_quick_paginate/demo.html

插件主页：http://projects.allmarkedup.com/jquery_quick_paginate/index.php

相关文章

• 没有相关文章。

最近在做的一个小项目里需要对中文内容的相似度进行判断，PHP中是有现成的函数的——similar_text。

google出来的大量结果反馈说similar_text函数对中文字符串相似度的判断不是很好。

我做了一个实验：

输出的结果为72.7272727273(这里是百分比)，72.73%的相似度，这个结果已经很理想了。

我的PHP版本为5.2.9，不知道是否因为这个最新的版本提高了similar_text函数对中文的处理能力。

相关文章

• 正式启动LZCMS开发 (5)
• 把discuz 5.5中的模板函数封装为一个类 (0)
• 尝试采用eaccelerator提高PHP执行效率 (0)
• 如何在php中使用Libchart绘制中文的图表 (2)
• 在xslt中调用php函数 (2)

原文标题：Run PHP on the Google App Engine

原文地址：http://www.webdigi.co.uk/blog/2009/run-php-on-the-google-app-engine/

翻译正文：

一年前，Google发布了Google App Engine (GAE)。每个Google App Engine 应用程序都可免费使用多达 500MB 的持久存储空间以及可支持每月500万综合浏览量的足够带宽和 CPU。当然，你也可以查看详细的价格计划以获取更多的支持。

GAE现在已经能支持Java。不幸的是，GAE并不支持PHP。因此，在Google官方发布对PHP的支持之前，我们有一个替代方案。这个替代方案就是基于100%纯Java实现PHP（需要JDK 1.5）。

以下是在GAE上运行PHP的所有步骤：

1. 注册一个免费帐号

2.下载此文件

3.编辑war\WEB-INF\appengine-web.xml文件中的application标记为你所注册的应用名

4.最后上传你的应用。我下载了Google App Engine SDK for Java，并且在windows中运行了以下命令：
appcfg.cmd update C:\projects\phpwithjava\war

这里可以看到示例：
http://phpwithjava.appspot.com/webdigi.php
http://phpwithjava.appspot.com/info.php

注意: phpwithjava是我的GAE的应用名

相关文章

• 正式启动LZCMS开发 (5)
• 把discuz 5.5中的模板函数封装为一个类 (0)
• 尝试采用eaccelerator提高PHP执行效率 (0)
• 如何在php中使用Libchart绘制中文的图表 (2)
• 在xslt中调用php函数 (2)

开源项目地址：http://github.com/jdp/twitterlibphp/tree/master

按照例子来做会出错，下面是我自己调整过的范例

相关文章

• 正式启动LZCMS开发 (5)
• 把discuz 5.5中的模板函数封装为一个类 (0)
• 尝试采用eaccelerator提高PHP执行效率 (0)
• 如何在php中使用Libchart绘制中文的图表 (2)
• 在xslt中调用php函数 (2)

其实是个很无聊的东西——小说搜索引擎。

访问地址：JIU8搜书

PHP+MySQL开发的，基本功能已经都有了。

采集采用的是Linux下的crontab定时执行指定的php文件去采集。

相关文章

• 正式启动LZCMS开发 (5)
• 把discuz 5.5中的模板函数封装为一个类 (0)
• 尝试采用eaccelerator提高PHP执行效率 (0)
• 如何在php中使用Libchart绘制中文的图表 (2)
• 在xslt中调用php函数 (2)

最近要开发一个工期短但是需求繁杂的PHP项目。

工欲善其事，必先利其器。作为项目的前期准备，自然是要寻找合适的开发工具。起初是打算用delphi for php，但是仔细一想，delphi for php主要还是解决了界面上的问题，从开发的角度，还是用开发框架比较合适。

考虑到这个项目上线后的同时在线人数不会太多，因此性能上的要求不高，我选择了毕竟是官方出品的zend framework——没想到已经更新到1.8版本了。

昨晚先搞定了iis+isapi rewrite下的zend framework搭建，颇费了一番周折。

一开始用官方手册给的配置文件，出现了不论采用什么controller和action总是会访问index。也就是说，当URL为：

http://localhost/news/display 或 http://localhost/index/login等等时，它总是访问的http://localhost/index/index

仔细查找各种原因，这才发现，原来我的IIS里装了两套isapi rewrite，删除掉版本比较旧的那个就OK了。

官方的配置文件完全可用，具体如下：

RewriteRule ^[\w/\%]*(?:\.(?!(?:js|ico|gif|jpg|png|css)$)[\w\%]*$)? /index.php [I]

相关文章

• Zend Framework学习笔记（一） (0)

下图是某具备一定用户基数的网站用户分辨率状况，可以看出，800×600分辨率只占据了该网站访问的3.34%，主流已经是1024×768及以上的分辨率。由此，宽屏网页设计已成必然趋势，而在最近这一年时间里，各大门户已经纷纷完成了宽屏改版的工作。

究竟选择什么样的宽度来做宽屏网页的设计？

我收集整理了一下目前国内外部分网站的宽屏网页的宽度。

sina首页、sohu首页、英文yahoo首页：950px

163首页：960px

QQ首页：910px

由以上可以看出，主流的宽屏网页宽度基本为950px。

我个人非常赞同采用950px这一标准，理由如下：

1.可以更好的采用标准广告位尺寸。

由于种种原因，目前并没有宽屏分辨率下的网页广告位尺寸国际标准出台（至少我翻查了很多资料都没有找到）。传统窄屏网页的国标广告位尺寸基本还在宽屏网页上延续，以下为旧标准尺寸：468×60、728×90、234×60、125×125、120×600、160×600、180×150、120×240、200×200、250×250、300×250、336×280。采用标准广告位尺寸对网站有莫大的好处：Google、alimama、baidu及各网站联盟均采用的是国标广告位尺寸，无需修改即可直接嵌入到网页中；另外，各厂商广告代理、公关公司等在制作互联网广告的过程中也是采用的国标广告位位尺寸，同样无需对网页或广告素材进行任何修改就可以嵌入网页中，这一点对于广告业务繁忙的网站而言，非常重要。

以468×60的广告位举例。可以一行放置2个468×60的广告位，目前部分宽屏网站也是采用此方式放置广告。

1+468+1+10+1+468+1=950

2.可以更好的符合网页栅格系统设计原理。

关于这点我就不一一赘述了，详情可以点击这里。

相关文章

• 没有相关文章。