晓闻心雨 » WordPress 翻译

不用插件如何在文章中插入音频

Jacobxx — Fri, 23 Oct 2009 08:32:50 +0000

纯粹的技术文盲，上次突然间想在文章中添加一些音频，可惜又不懂，最终在网上找到代码：

代码说明：
支持的音乐格式： wma、mp3、rm、ra、ram、asf，尽量选用可连接性高的音乐链接，保证音乐可以顺利播放；
width和height表示播放器宽度和高度，可以灵活设置；autostart=”true”表示自动播放，autostart=”false”表示不自动播放； loop=”true”表示连续循环播放，loop=”false”表示不循环播放； loop也可以设为一个整数，比如loop=”3″，表示音乐循环播放3次；
显示的结果就是上一篇的On change，不过需要下载插件QuickTimeInstaller才能显示和播放。

WordPress是否该维护旧版本？

jacobxx — Sun, 27 Sep 2009 07:12:21 +0000

本文转载自wordpress啦

最近对WordPress旧版本的攻击不停，安全问题成为大家讨论的热点。各方的指责、谩骂也不断，当然其中也不少人讨论该如何促进WordPress的发展。我同意Jeff、David等人的看法，认为最终的责任在于网站所有者。虽然WordPress官方博客已经申明WordPress团队已经尽其所能，一些人却还一直抱怨他们是否该多做些努力。在这里我提下我个人的见解，或许会有帮助:维护旧版本。

什么是旧版本维护?

WordPress新版本都有安全补丁，同时还添加了新的功能、数据库变化以及重新设计的用户界面。很多用户对他们已有的WordPress版本的功能已经满意，但迫于要下载安全补丁无奈只得更新其它所有的更改。根据现有的WordPress版本政策，只支持最新的版本。就如，今年夏天 WordPress 2.8.2发现了一个安全漏洞问题之后，更新后的2.8.3 版本修复了这个漏洞。而更旧的版本如 WordPress2.6.5 也容易受此漏洞攻击，但却没有这个版本对应的修复，因为已经不再支持此版本了。很多软件公司都有支持旧版本，我也建议WordPress支持旧版本，时间也不用太久，18个月左右就行。

如何运作?

回顾下WordPress的版本发行的历史。WordPress 2.2.x 和2.6.x本该受支持。假设一个网站在2007年六月份用WordPress 2.2 创建的，根据我的提议，在之后的18个月里，站长只需应用安全补丁(2.2.x)，而无需在2007.9月更新到2.3的版本，2008.3月更新到 2.5版本，或者2008.7月的2.6版本。2008.12月份发布WordPress 2.7的时候，2.2.x版本就可以完全放弃。而后2.6.x 成为受支持的版本: 站长只要将其更新到2.6.5版本。

根据我的提议，任何人用WordPress建站时都可以有两个选择，可以选择安装最新的版本(例如，2.8.4)或旧的受支持版本 (例如，2.6.x)。最新的版本包含了所有最新的功能，但是每隔三四个月就需要升级。旧的受保护版本不包含所有的新功能，但是在被放弃支持之前，只需要安装安全补丁就可以：除非新的版本(例如，3.1) 发布，要不然都不需要升级到下一个受保护的版本(例如，3.0.x) 。

反对意见

大多数人应该都还记得WordPress过去是有支持2.0.x版本的。WordPress团队苦心支持了该版本将近四年，最后在七月份的时候宣告放弃。关于这个问题我曾经与WordPress的团队谈论过，我收到如下的反对意见:

1.维护工作太多

我没有办法否认这一点: 毫无疑问，比起不支持任何旧版本来说，要维护一个旧版本肯定有更多的工作要做。但是这个工作量是确定的，想想要是从一个大攻击中的负面影响恢复过来需要付出的努力是不是更多呢？如果对WordPress旧版本的支持能使大多数的用户网站都处于一个安全的环境中，WordPress团队就可以少花多少时间应付“WordPress不安全” 这样的言论了，也有更多的时间来开发WordPress软件。

2. 没有这种需求

当然我相信没有必要去维护2.0.x 版本。与现在的版本相比，那时候WordPress的功能也非常有限。随着网络的不断快速发展，我也不觉得有必要去维护三四年前的东西。但是，现在的 WordPress 已经日趋成熟，对于很多站长来说，当前的版本使用18个月，其功能还是足够用了。事实上，WordPress 2.6就已经是一个非常好的产品: 很多用户则需要一个安全的WordPress 2.6.x就可以了，不希望这么快就更新为一个全新的用户界面。

随着WordPress的不断发展，很多用户不再像早期用户那么通晓技术，也并不急于每隔几个月就升级新的功能。他们只需要网站能够运行，并且也害怕更新会造成自定义的主题或插件损坏。虽然说继续维护旧的版本不会让他们从此完全脱离这个苦海，他们仍需要更新，但是却会大大减轻维护一个 WordPress网站的负担。

我在WordPress上给顾客创建网站。如果WordPress团队能够采纳我的提议，我将会在最新的版本上创建一些新的网站。然后几个月更新一次直到成为一个受支持的版本。从此，我就可以等18月后再更新版本了。我相信很多 WordPress用户都会为此高兴的: 如果WordPress 3.0.x能够开始实施这方案就太好了。

3. 太容易让用户混淆

这个担心是有必要的，但是我觉得毫无疑问这个体制得充分向用户解释清楚。这一点，我也很乐意帮助WordPress团队。下面是我的粗略设想：

在“下载”页面需要有两个按钮，并在下面附上描述性的文字，如:
[下载 WordPress 3.2]
新版：包含了最新的功能，但需要经常更新:
安全补丁包即日起到3.3版本发布
[下载 WordPress 3.0.x]
旧版: 安全补丁包即日起到3.5版本发布
在旧版用户管理界面上的升级通知需要修改成如下面这样:
[红色警示] WordPress 3.0.3 修正了一个此版本的安全漏洞问题，立即更新。
…或者:
[蓝色警示] WordPress 3.1 添加了新的功能。了解更多详情| 立即更新
… 或者:
[红色警示] 已经不再支持此版本的WordPress，请更新到WordPress 3.4.2 to以保安全。立即更新。

讨论

这是一次讨论，目前为止都是我在这边唠叨，不知道各位的看法如何？你是否希望能够支持旧版本？对你自己的网站？对你客户的网站？你认为有多少用户会使用这里的老版本？用户是否会对经常性升级感到疲劳？扎居在WordPress中用户是否觉得够舒适？这个政策是否有利于消除近日WordPress的安全问题的负面影响？

附原文：

Supported Legacy Branches For WordPress.org?

The recent attacks on older versions of WordPress have made security a hot topic in the community. There has been finger-pointing and mud-slinging from many different directions, but there has also been some good discussion about how to move the project forward. I agree with Jeff, David, and others that responsibility ultimately lies with web site owners. While the official WordPress development blog states that the WordPress team is doing everything they can, others have been wondering if more could be done. I would like to get a discussion going here at the tavern about something that I think would help: a supported legacy branch.

What’s A Legacy Branch?

Newer versions of WordPress currently come with security fixes, but also with added functionality, database changes, and redesigned interfaces. Many users are quite happy with the functionality of their existing version of WordPress, but there is currently no way for them to get only the security fixes without also getting all the other changes. According to the existing WordPress release strategy, only the current branch is supported. When a security issue was found in WordPress 2.8.2 this summer, the new version 2.8.3 was released to fix it. Older versions like WordPress 2.6.5 were also vulnerable to this issue, but no fix was released for them because they were no longer supported. Many software companies and projects do choose to support older versions, and I would like to suggest that the WordPress team supported one legacy branch for around 18 months.

How Might It Work?

Looking back through WordPress’s release history, WordPress 2.2.x and 2.6.x could have been supported legacy branches. Imagine a site built on WordPress 2.2 in June 2007. Under my suggested system, the site owner would have applied only security fixes (2.2.x) for the next eighteen months — not needing to upgrade to 2.3 in September 2007, to 2.5 in March 2008, or to 2.6 in July 2008. When WordPress 2.7 was released in December 2008, the 2.2.x legacy branch could have been deprecated and 2.6.x could have then become the supported legacy branch: the site owner would only then need to upgrade to 2.6.5.

Under my suggested system, someone building a new WordPress site would have the choice between installing the most recent branch (e.g., 2.8.4) or the legacy branch (e.g., 2.6.x). The most recent branch would have all the latest features, but it would also need to be upgraded every three or four months. The legacy branch would not have all these new features, but it would need only security fixes applied until it was deprecated: it would not need to be upgraded to the next supported legacy branch (e.g., 3.0.x) until the version after it (e.g., 3.1) was released.

Objections

Many patrons here at the tavern no doubt remember that WordPress used to support the legacy branch 2.0.x. The branch was supported for almost four years, but the WordPress team abandoned it in back in July. I have talked with WordPress team members about this in the past, at WordCamps and over email, and I have received the following objections to such a system:

1. It’s too much work to maintain.

There is no way for me to deny it: it’s definitely more work to support a legacy branch than not to support one. But it is a known quantity of work. How much work does it take to recover from the negative press generated from large attacks? If a supported legacy branch increases the number of users who keep their WordPress installations secure, the project team could spend less time responding to the latest round of “WordPress is Insecure!” blog posts and more time working on the software.

2. There’s no demand for one.

I certainly believe that there was no demand for the 2.0.x legacy branch. WordPress then had a fairly limited set of features compared to WordPress today. Since the web is constantly evolving, I wouldn’t expect there to be a demand for software three or four years old. But WordPress today is a very mature product, and the current version will be more than adequate for many web site owners for another eighteen months. In fact, WordPress 2.6 was a very good product: many users would have preferred to stay on a secure WordPress 2.6.x instead of upgrading so quickly to a completely new interface.

As the WordPress community grows, many users are not as technically savvy or as anxious to get upgraded features every few months as in the earlier days of the project. They simply want their sites to work, and they rightly fear that an upgrade may break custom themes or plugins. A supported legacy branch would not let them completely off the hook — they would still eventually need to upgrade — but it would greatly ease the burden of maintaining a WordPress web site.

I build business web sites for clients in WordPress. If the WordPress team adopted a system like the one I am suggesting, I would build new web sites on the most recent branch. I would then upgrade my clients every few months until they reached what would become a supported legacy branch. After that, I would be able to upgrade them every eighteen months. I think many WordPress users would be thrilled to have something like this upgrade plan available to them: it would be great if it could be available starting with WordPress 3.0.x.

3. It’s too confusing for users.

This is a legitimate concern, but I have no doubt that a system like this could be adequately explained — and I’m more than willing to help the project team in designing this user experience. Here are my initials thoughts about what could be done:

Two buttons would be needed on the “Download” page, with descriptive text beneath them something like the following:

[Download WordPress 3.2]
Contains the newest features but requires more frequent upgrades:
security patches only available until 3.3 release

[Download WordPress 3.0.x]
Legacy branch: security patches available until 3.5 release
The upgrade notifications in the administrative interface could be modified for users on a supported legacy branch. They might see something like this:

[Red] WordPress 3.0.3 fixes a security issue found in this version of WordPress. Update Now

… or this:

[Yellow] WordPress 3.1 adds new features to this version of WordPress. Learn More | Update Now

… or this:

[Red] This version of WordPress is no longer supported. You must update to WordPress 3.4.2 to remain secure. Update Now

Discuss

This is a tavern, and I have already monopolized the conversation for far too long. I want to hear from the other patrons: What do you think? Would you be interested in a legacy branch for your own sites? For your clients’ sites? How many users do you think would use such legacy branches? Would existing users feel less upgrade fatigue? Would more people be comfortable staying on or switching to WordPress? Could this help WordPress overcome the recent negative press about security?

WordPress进入实时时代: 750万博客实现同步RSS订阅

jacobxx — Sun, 27 Sep 2009 06:06:22 +0000

本文转载自wordpress啦

SS是简单内容聚合（ Real Simple Syndication）的简称。它可帮助你实现聚合所有的新闻和博客资源到一个易于管理的RSS阅读器，如谷歌阅读器上。数百万人都用RSS获取Mashable、纽约时报等新闻资讯。

然而，它也有其局限性，最大的局限性就是速度。 从博客上的文章发布到到达RSS订阅用户的阅读器上可能要花几分钟到几小时的时间。这也是为什么越来越多的人选择直接查看实时网站服务如Twitter、FriendFeed 来获得新闻的最大原因。可在实时网站中，发布的新闻、信息又却不尽都能如人意。

现在WordPress做了巨大改变，克服了RSS订阅时时间拖延问题，使得WordPress.com的750万博客以及其他自建WordPress博客实了实时RSS订阅。它使用了RSSCloud，使得即刻聚集博客的内容成为了可能。不过，要使你的WordPress博客的RSS能像Twitter那样的速度，还有一些工作要做。

RSSCloud和WordPress.com

WordPress创始人Matt今天早上在一篇博文中解释了新发现WordPress 博客系统支持RSSCloud。从本质上来说就是，大多数的RSS阅读器只允许间隔性地检查服务器以获取内容的更新，但是RSSCloud可让服务器实时跟新。这样一来，原本你需要花15分钟才能将你博客文章聚集给订阅用户，现在只要文章一发布就会立即聚集到订阅者的RSS订阅器上。

现在很多feed的用户通常都是一个小时服务器才更新一次。你想象下要是让你等一个小时才能收到邮件，你会是什么感受？(世界本该更高效的) 。RSS Cloud 是你的RSS feed一个额外元素，有了它，订阅者才可以真正意义上说“嗨，有更新立马通知我哦。”

虽然RSSCloud出现已经有些时日了，但是WordPress对其的支持却近日才有的。就如ReadWriteWeb解释道：现在每一个WordPress.com 上的博客，他们的RSSCloud 都是激活的，大概有750万个博客并且这个数据还在扩大。另外，对于自己建立的WordPress博客，你也可以下载RSSCloud WordPress 插件，自己安装。WordPress 也打算通过其它方式使得其它RSS订阅时间更短，包括：Jabber, email, Weblogs.com pings, SUP, pubsubhubbub, Twitter 等。

WordPress也许可以实现实时，不过RSS实时还尚早

虽然WordPress.com支持RSSCloud了，但不意味着所有的RSS feeds 也能保证实时的功能。它需要原始的RSS feed网站和订阅者的RSS阅读器都支持RSSCloud。实际上，如果谷歌和outlook不支持RSSCloud的话，这项技术就没有太大的意义了。

不过，RSSCloud却也很快获得了很多人的支持。River2 目前就支持RSSCloud，LazyFeed 也刚刚宣布将来要支持RSSCloud。不过这些都还是小角色，很快你就会看到像谷歌这样的巨头也会支持它的。实时RSS的优势实在不容忽视。

一旦RSSCloud能获得各方的支持后，我们将会看到RSS一场彻底革新的变革到来。跟Twitter的跟新一样迅速，RSS将会迎来复活时代。我们将会看到新的应用程序和开发者使用RSSCloud 使实时瞬间新闻成为可能。在RSS上的实时会话也成为可能，这意味着全新blogging即将到来。

WordPress + RSSCloud 将可能成为一个分水岭，带领我们走进一个真正的实时互联网时代。

附原文：

WordPress Enters Real-Time: 7.5 Million Blogs Reach Twitter Speed

RSS, short for Really Simple Syndication, helps you stream all of your news and blog sources into an easy-to-manage RSS reader such as Google Reader. Millions of people use RSS to keep up with Mashable, The New York Times, and even LOLcats.However, it does have its limitations. The big one is speed. It can take minutes to hours for a blog post to reach the reader through RSS. This has been a big reason why more and more people are turning to real-time services like TwitterTwitter and FriendFeedFriendFeed for their news. In the real-time web, delayed news and information just isn’t good enough.

Now WordPress has done something big that eliminates that RSS delay problem and brings WordPressWordPress.com’s 7.5 million blogs into real-time, along with any other self-hosted WordPress blog. It has implemented RSSCloud, an RSS element that makes instant syndication of blog posts possible. However, it does have a few obstacles to overcome before your RSS is just like Twitter.

RSSCloud and WordPress.com

WordPress founder Matt Mullengweg explained the blog network’s newfound support for RSSCloud in a blog post earlier today. Essentially, while most RSS readers only periodically check servers for updates, RSSCloud makes checking for updates instantaneous. The result is that instead of waiting 15 minutes for your blog post to be syndicated, it will happen instantaneously:

Right now how most people interact with feeds is by checking that it updated every now and then, usually about once an hour. Can you imagine waiting an hour to get your emails? (The world would probably be more productive.) RSS Cloud is an extra element in your RSS feed that allows subscribers to say “Hey, let me know as soon as you’ve updated, kthx.”

While RSSCloud has been around for a while, WordPress’s support of the element is nothing short of monumental. As ReadWriteWeb explains, RSSCloud is now active on every blog hosted on WordPress.com, which numbers around 7.5 million and growing. There’s also an RSSCloud WordPress plugin for self-hosted installs of the popular blog software.

WordPress also intends to support other ways to make RSS more real-time, which could include integratio nwith “Jabber, email, Weblogs.com pings, SUP, pubsubhubbub, Twitter” and more.

WordPress May Be Realtime, but RSS Isn’t Quite Yet

WordPress.com supporting RSSCloud doesn’t mean that your RSS feeds are instantly real-time though. It requires support by both the originator of the RSS feed and the RSS reader. Essentially this change is useless if Google ReaderGoogle Reader and Outlook don’t support it.

The support RSSCloud movement is gaining traction quickly, though. Dave Winer’s River2 currently supports it and LazyFeed just announced RSSCloud in the future as well. While these are small players, you can expect big players like GoogleGoogle to support it soon. The advantages to real-time RSS are just too large to ignore.

Once that happens, we could see a whole new revolution revolve around RSS. With updates as fast as Twitter, RSS could see a renaissance in terms of usage and innovation. We could be seeing new apps and developers using RSSCloud to make news instant. Real-time conversations are possible in RSS as well, meaning we could see a whole new form of blogging really soon.

WordPress + RSSCloud could be the watershed moment that really pushes us into the real-time era of the web. Hopefully you’ll be getting MashableMashable in your RSS reader instantly very, very soon.

十招阻止WordPress中的垃圾评论

jacobxx — Tue, 01 Sep 2009 07:51:09 +0000

本文转载自WordPress啦！垃圾评论经常令blogger们头疼，它们占用了资源使得博客的运行速度也下降。这里就跟大家分享下，打击垃圾评论的十大招数。

1. 安装Akismet

这是最简单的方法，Akismet 是WordPress系统默认自带的一个很好的防垃圾评论方法，对于普通的blogger来说，安装Akismet后你的垃圾评论就会被挑选出来。但是也有一个问题，它仅是找出了垃圾评论却不能从根本上解决问题。这也是为什么要写这篇文章的原因，我们将从最简单的将垃圾评论区分出来着手，之后转移到如何从源头上阻止垃圾评论。

2. reCAPTCHA

reCAPTCHA 插件，你应该在Facebook、 Twitter 、StumbleUpon等网站上有看到过此插件。什么是reCAPTCHA呢？它跟普通的CAPTCHA(图形验证码)不同，它是使用了从古书中扫描来的字符，然后使用 OCR 软件进行识别的，而 OCR 的识别能力有限，需要人力来一一校对，而且还不能保证完全正确，因此，你每一次的reCAPTCHA验证实际上是在帮助这些书籍的数据化。在此，你可能会问它是如何实现防垃圾评论的呢？答案很简答，reCAPTCHA 验证码中有2个单词，一个是已经正确识别出的，而另一个是未确定需要校对帮助其数据化的单词。图示：

该插件有2.7+版本可安装，搜索下WP-reCAPTCHA下载之后一键点击安装。不过，你需要一个key才可以使用，你可以从这里获得key。弄好之后，在你的评论页面就会显示reCAPTCHA验证。

3. 邀请读者回答简单的算术问题

要介绍的第二款从源头上防止垃圾评论的插件是Math Comment Spam Protection 插件。使用它之后，你的博客评论区会有一个简单的数学问题需要回答，用户才能发表评论。

这里就不讲述如何安装它，在这个插件的官方网站上有一个全面的安装指南。你可以看上面的效果图。

4. 阻止垃圾trackbacks

要介绍的最后一款插件的制作者跟上一款是同一人，叫做 “Simple Trackback Validation ”。它通过检验trackback的发送者的IP地址是否与该trackback URL IP 地址相同来阻止垃圾trackback。在插件的主页面上是这样说的：“检索trackback 中的URL所指向的页面，如果这个页面没有包含一个到你博客的链接，则视为垃圾Trackbacks。由于大多数的垃圾trackback发送者不会专门建立一个页面来链接他们要攻击的博客，这样一个简单的检查就可以很快揭露非法trackbacks。”

与上一款插件一样，在插件的主页面也有安装指南。

5. 用户登录后评论

可能大多数blogger们不是很喜欢这种方法，不过却是阻止垃圾评论的一个非常有效的方法。选上“Users must be registered and logged in to comment.”

在后台的“设置”，点击“讨论”勾上“用户必须注册登录后才能发表评论”，并保存你的更改。

6. 通过IP地址阻止垃圾评论

这里就需要用到 .htaccess文件。你先阅读这里了解下基本介绍。并牢记一条定律，始终都要对.htaccess备份。更多关于.htaccess的知识可以阅读CatsWhoCode和WPShout。

大多数情况下垃圾评论的发送者会制造假IP，此方法不是特别好使，不过，要是有个IP经常骚扰到你，你可以通过下面的代码阻止他们访问你的网站，只要在你的博客根目录下的.htaccess文件插入下面的代码就可以，把第二行的IP地址改成你想要阻止的IP地址。

Order allow,deny
Deny from 100.100.100.
Allow from all

7. 通过禁止黑名单列表IP访问来阻止垃圾评论

使用上面的方法，你仅仅阻止了一个垃圾评论发送的IP。现在有了Perishable Press，你想阻止多少垃圾评论的IP地址都可以，Jeff收集了大量的黑名单列表，你可以从中挑选你需要阻止的地址，在.htaccess文件上实施。你可以通过下面的地址获得最新的黑名单列表:

8. 拒绝不相关的评论请求

另外一个利用 .htaccess来阻止垃圾评论的技巧是拒绝不相关的评论请求，也就是说，如果评论不是来自你的网站的话，就阻止它。把第四行的URL地址改为你的博客地址即可。

RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
RewriteCond %{HTTP_REFERER} !.*yourblog.com.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]

9. 阻止内容盗用

垃圾评论发送者还不仅限于给你滥发评论，他们通常还会窃走你的内容。这里就介绍下如何防止他们通过RSS盗用你的内容。一旦你发现了哪一个网站偷窃你的内容，首先记住网站的IP地址。Ping下结果’ping [站定名称,如：catswhocode.com]‘。然后找到他们的RSS feed，在你的 .htaccess 文件里添加下列代码:

RewriteEngine on
RewriteCond %{REMOTE_ADDR} ^69.16.226.12
RewriteRule ^(.*)$ http://newfeedurl.com/feed

把第二行的IP地址改为偷窃站点的IP，第三行的URL改为该站点的feed地址。

10. 阻止图像盗用

上面，我们阻止了别人从RSS盗用你的内容，现在介绍下如何对付那些复制你并粘贴你的内容到他们网站的窃贼。虽然，从技术上来讲这并不是阻止垃圾评论，不过却对打击垃圾评论发送者有很大作用。

如果你的图像被盗链，你有两个选择：给你的图像印水印或者使用.htaccess。两个我都介绍下，你自己决定使用哪一个。第一种水印，也是万无一失的就是你在上传图像之前就打上水印，可以通过一些简单的软件来实现，这里我推荐完全免费的工具 FastStone Photo Resizer。第二种水印，安装phpThumb并创建一个调整图像大小和水印的简易代码。在functions.php文件里添加下面的代码，把phpThumb上传到你的主题文件夹，上传水印并修改URL地址。你也可以修改下图片的宽度（当前为590）。

return ‘’;
}
add_shortcode(‘img’, ‘imageresizer’); ?>

有了这些代码之后，你按正常的方法上传一张图片后，转为HTML模式并复制图像的url，接着删除该图片在 [img] 和[/img]中间插入图像的URL地址。
当然，你也可以通过在.htaccess 添加如下代码防止盗链(把第三行和第五行的地址做下改动 – 第五行将要显示的图片- 将它转向到空白地址或你站点的广告):

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?yourdomain.com/.*$ [NC]
#RewriteRule \.(gif|jpg)$ – [F]
RewriteRule \.(gif|jpg)$ http://www.yourdomain.com/advert.jpg [R,L]

附原文：

Top 10 ways to stop spam in WordPress

Posted by Alex Denning on Aug 31, 2009 | 17 comments

Spam is a nuisance, and as bloggers, we have all experienced a flood of spam every now and then. Not only is it a pain, but it can slow down your blog and use up your resources. In this post we’ll look at ten ways to combat spam.

Guest post by Alex Denning, a Twitter fan who runs WPShout.com, where he blogs about WordPress tips, tricks and hacks.

1. Install Akismet

This is the simple one that everyone does. Akismet comes bundled with WordPress by default and does a good job of picking up spam – for the average blogger, install Akismet and your spam problems will be sorted. The trouble is though, it just stops spam getting displayed, it doesn’t get to the root of the problem. That’s where this post comes in. We’ll start with some simple methods of stopping spam being displayed and then we’ll move onto stopping the spammers getting on your site in the first place.

2. reCAPTCHA

The reCAPTCHA plugin is one you’ve probably seen around on sites such as Facebook, Twitter and StumbleUpon. It isn’t just your average CAPTCHA (an image containing some letters that are designed so only humans can read them), it uses words from old books, so every time you enter a reCAPTCHA, you’re helping digitise books. At this point, you’re probably thinking but if I’m telling it what the words mean, does that mean I can enter anything? How does that stop spammers? The answer is simple – there are two words, one of which the CAPTCHA knows. The second, it doesn’t and you’re helping digitise it.

The plugin is simple to install, in 2.7+, just do a search for WP-reCAPTCHA and click install. You’ll need a key for the plugin to work, which you can get here. After you’ve done that, reCAPTCHA should appear on your comments’ page.

3. Ask your readers to do 1+1

The second plugin that we’re going to look at as a way of stopping spam being displaued is the ‘Math Comment Spam Protection‘ plugin. Using it, you can add a field to your blog’s comment box with a simple maths (or ‘math’ as they say in the States) question.

I’m not going to go into installing it here as there’s a comprehensive installation guide on the plugin’s website. You can see it in action on WordPress Hacks (image above).

4. Stop spam trackbacks

The final plugin that we’re going to look at is one by the same author who made the plugin above. The ‘Simple Trackback Validation‘ plugin checks if the IP address of the sender of the trackback is the same as the IP address that the trackback URL refers to, thus eliminating [lots]% of trackback spam as spammers won’t use bots running on infected machines. As the plugin’s page says, the plugin also “retrieves the web page located at the URL included in the trackback. If the page doesn’t a link to your blog, the trackback is considered to be spam. Since most trackback spammers do not set up custom web pages linking to the blogs they attack, this simple test will quickly reveal illegitimate trackbacks. Also, bloggers can be stopped abusing trackback by sending trackbacks with their blog software or webservices without having a link to the post.”

Like the ‘Math Comment Spam Protection’ plugin, there’s an installation guide on the plugin’s homepage.

5. Make users login to comment

This is something that probably won’t be a good idea for the majority of bloggers, but it will stop spam – make users login to be able to leave a comment and spammers will be stopped from commenting, but so will one time visitors. Just keep that in mind.

Under ‘Settings’. click ‘Discussion’ and then tick the box ‘Users must be registered and logged in to comment’. Then save changes and you’re done.

6. Ban spammers by IP

Now that we’ve stopped spam being displayed with the tips above, we’re going to move on to blocking spammers getting on your site in the first place. Something we’re going to be using extensively is the .htaccess file. A basic introduction that you should read first is here, and remember the golden rule of .htaccess – always have a backup. Further .htaccess reading is available here on CatsWhoCode and my own blog, WPShout.

In most situations, this tip wouldn’t be too much of a good idea; spammers will fake often their IP, but if there is one IP that is particularly bugging you, then the code below will block them from visiting your site – instert it into your .htaccess file in your blog’s root, changing the second line to include the IP that you wish to ban.
Order allow,deny
Deny from 100.100.100.
Allow from all
7. Ban spammers by IP, on a massive scale

You’ve blocked a single spammer. Well done. Now, with help from Perishable Press, you can block thousands of spammers – Jeff from Perishable has compiled a number of blacklists, from which you can pick and choose which you want to implement into your .htaccess file. The latest blacklists, the ‘fourth generation’ can be accessed below:

‘The Perishable Press 4G Blacklist’

‘4G Series: The Ultimate Referrer Blacklist, Featuring Over 8000 Banned Referrers‘

’4G Series: The Ultimate User-Agent Blacklist, Featuring Over 1200 Bad Bots’

8. Deny comment posting to no referrer requests

Another .htaccess trick and the final comment spam stopping technique we’re going to look at is denying comment posting to no referrer requests – in other words, if the comment isn’t actually coming from your site, then it gets blocked. Make sure you change the url in line four to your blog.
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
RewriteCond %{HTTP_REFERER} !.*yourblog.com.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]
Source – WordPress Recipes.

9. Stop content theives

Spammers don’t just limit themselves to spamming your comments – often they’ll steal your content too. This next trick will stop spammers who steal your content via RSS. Once you’ve found a site stealing your content, first thing to do is find out the site’s IP address. A search for ‘ping [site name, ie catswhocode.com]‘ should give you a result. Once you’ve got that, head over to the offending site and find their RSS feed. Then, open up your .htaccess file and add the following lines:
RewriteEngine on
RewriteCond %{REMOTE_ADDR} ^69.16.226.12
RewriteRule ^(.*)$ http://newfeedurl.com/feed
Change the IP in line two with the IP of the offending site and the url in line three with the offending site’s feed.

Source - WPShout/ SEO Black Hat

10. Stop spammers stealing your images

Now that we’ve stopped spammers from stealing your content via RSS, now it is time to combat those who just copy and paste your articles onto their site. Yes, this isn’t technically stopping spam, but it is helping combat the spammers.

You’ve got two options if people are hotlinking your images – watermark or .htaccess. We’ll look at both, and I’ll leave you to decide which is better. First up, watermarking. The foolproof method is to watermark your images before you upload them, which you can do with some simple software – FastStone Photo Resizer is a great tool that I’d thoroughly recommend. What’s more, it’s free! The second option is to install phpThumb and create a shortcode that resizes and watermarks your image. Copy and paste the following code into your functions.php file, having uploaded phpThumb to your theme’s folder, uploaded a watermark and changed the URLs. You can also change the width that images will be resized to (it’s currently 590).
With the code integrated, now when uploading a picture, upload it in the normal way, then go into HTML mode and copy the image url, then delete the image and then paste the image URL between [img] and [/img].

Of course, you can also easily disable hotlinking by going into your .htaccess file and pasting the following (changing lines three and five – five will display and alternate image – send it to something blank, or perhaps an ad for your site?):
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?yourdomain.com/.*$ [NC]
#RewriteRule \.(gif|jpg)$ - [F]
RewriteRule \.(gif|jpg)$ http://www.yourdomain.com/advert.jpg [R,L]

使用WordPress内置的缓存机制

jacobxx — Tue, 25 Aug 2009 09:19:47 +0000

WordPress可以使用插件缓存，但其实在WordPress内部也有一套缓存机制，你可以使用很多函数轻松实现缓存。为了让大家认识和了解这个功能，我使用一个简单的例子，缓存一个feed并在前端显示。

最先的缓存方案是WordPress 2.3中基于文件的缓存。该缓存是可选的，并需配置一些参数。可通过下面的常量激活缓存: define ( ‘ENABLE_CACHE’, true);

缓存最大改进的还是在2.6版本，此时变为基于对象的缓存。缓存主要依赖于服务器速度，这主要是考虑到最大化地利用服务器资源而不是什么都交由 WordPress处理。这样一来，WordPress中的缓存就无所谓的“被激活” ，因为它一直处于激活的状态。因此，服务器是否有足够的存储就显得尤为重要了， WordPress需要最低需要32兆的存储空间- 但并非每次都如此。例如，当跟新核心数据库的时候，需要128兆的空间，很多情况下都是无法满足的，因此就无法更新。

不过这个不是我们今天讨论的重点。我想向大家介绍如何利用自己的扩展使用缓存。我举个利用关键函数来实现缓存的例子。你可以在wp-includes/cache.php或 Codex里查找到所有的函数。

你可以使用下列函数来实现添加缓存。

wp_cache_add($key, $data, $flag = ”, $expire = 0)

相反的，要删除缓存数据可以通过下面的方法实现。

wp_cache_delete($id, $flag = ”)

提取缓存数据：

wp_cache_get($id, $flag = ”)

替换缓存数据：

wp_cache_replace($key, $data, $flag = ”, $expire = 0)

至于缓存feed，WordPress1.5以后版本的feed都是通过fetch_rss()函数来加载的。

$mycache = wp_cache_get( ‘mycache’ ); // 获取键名为 “mycache” 的缓存
if ($mycache == false) { // 如果没有数据，那么
$mycache = fetch_rss(“http://mycache.com/feed/”); // 解析feed
wp_cache_set( ‘mycache’, $mycache ); // 将内容保存进 “mycache” 中
}
var_dump( $mycache ); // 显示内容

可通过变量$wp_object_cache或使用插件Debug Objects 、WP Cache Inspect 进一步了解WordPress缓存。Debug Objects 就是为此而产生，并只能用于开发环境中。

附原文：

Use WordPress Cache

WordPress has an internal cache, also for extensions can be used. There are various functions available and you don’t have to create something new, you can easily use the cache functionality of WordPress.
To get to know and understand the features a little bit, I use a small example, therefore I cache in the following tutorial a feed, which should be displayed in the frontend.

All functions of cache are in the Codex by WordPress listed, so a look at the Codex is worthwhile if you deal with the syntax.

The first cache solution came with WordPress 2.3 and was file based. The cache was optional and had some parameters to configure.
You were able to activate via following constant: define ( 'ENABLE_CACHE', true);

The biggest improvement happened in version 2.6, in which the cache has changed to an object-oriented solution. Therefore the opportunities for cache usage are lying rather on the server and not explicitly on WordPress. This was mainly realized in order to maximize the resources of the server and not to be handed over to WordPress. With this introduction, the cache of WordPress has no longer explicitly be activated, it is always active. Therefore, it is important that the server has a certain minimum amount of RAM available, WordPress requires 32 MByte – but that is not always the case, for example, when updating the core, it contains a call which defines the RAM to 128MByte, which in many cases is not available and therefore the update does not work.
But this is not the topic of this post today, because I want to explain how to use the cache in your own extensions. So back to the syntax and I just start with the key functions to realize a small example.

All functions can be found in wp-includes/cache.php, or alternatively in Codex.

To reset the cache, insofar there is no data for this key, you can use the following function.

/**
 * @param int|string $key The cache ID to use for retrieval later
 * @param mixed $data The data to add to the cache store
 * @param string $flag The group to add the cache to
 * @param int $expire When the cache data should be expired
 */
wp_cache_add($key, $data, $flag = '', $expire = 0)

To delete cache data for a key, here is the opposite.

/**
 * @param int|string $id What the contents in the cache are called
 * @param string $flag Where the cache contents are grouped
 * @return bool True on successful removal, false on failure
 */
wp_cache_delete($id, $flag = '')

Fetching data for a key is done by using:

/**
 * @param int|string $id What the contents in the cache are called
 * @param string $flag Where the cache contents are grouped
 * @return bool|mixed False on failure to retrieve contents or the cache
 */
wp_cache_get($id, $flag = '')

Should within the cache to a key the content to be replaced, then the following function will work.

/**
 * @param int|string $id What to call the contents in the cache
 * @param mixed $data The contents to store in the cache
 * @param string $flag Where to group the cache contents
 * @param int $expire When to expire the cache contents
 * @return bool False if cache ID and group already exists, true on success
 */
wp_cache_replace($key, $data, $flag = '', $expire = 0)

But now a small example, which caches the feed. The feed gets loaded by fetch_rss(), a function of WordPress which is available since version 1.5.

$mycache = wp_cache_get( 'mycache' ); // fetch data from cache to the key "mycache"
if ($mycache == false) { // if no data, then
	$mycache = fetch_rss("http://mycache.com/feed/"); // parse feed
	wp_cache_set( 'mycache', $mycache ); // save feed content to key "mycache"
}
var_dump( $mycache ); // display content

FYI: You get an insight into the cache of WordPress easily via the variable $wp_object_cache or using the Plugin Debug Objects or WP Cache Inspect; whereas Debug Objects explicitly has been made for this and should be used in development environments only.

玩转WordPress配置文件

jacobxx — Tue, 25 Aug 2009 09:15:45 +0000

本文转载自WordPress啦！

WordPress用户都知道，wp-config.php 文件是WordPress数据库的关键。数据库名、用户名、密码、位置都是在此设置。

但是很多用户并不知道通过wp-config.php文件可以更改很多设置，提高WordPress站点的功能、性能、安全度。在这里，这里跟大家分享下使用wp-config.php的技巧。

数据库信息

WordPress链接数据库需设定以下四个值:

define(‘DB_NAME’, ‘database-name’);
define(‘DB_USER’, ‘database-username’);
define(‘DB_PASSWORD’, ‘database-password’);
define(‘DB_HOST’, ‘localhost’);

在创建数据库前就需准备好数据库名称、用户名、密码，最后一个DB_HOST值可能比较难获得，最常见的是直接用“localhost”，甚至你可以给数据库服务器指定一个备用端口。例如：

define(‘DB_HOST’, ‘localhost:1234′);

define(‘DB_HOST’, ‘mysql.domain.tld:1234′);

还有一种更好的方法就是自动检测数据库服务器值：

define(‘DB_HOST’, $_ENV{DATABASE_SERVER});

如果上面所有方法都行不通，求助你的服务器提供商。

数据库字符集和整理(collation)

截至WordPress 2.2版，你可以给MySQL数据库指定字符集。一般来说，不需要修改默认字符集UTF-8，因为它支持所有的语言。注意，如果wp- config.php文件里，这一字符集已经存在，你只能使用此字符集。下面是默认的设置，也是我推荐大家使用的设置：

define(‘DB_CHARSET’, ‘utf8′);

WordPress 2.2 版本还可以指定collation（校勘/整理），对你的数据库字符集排序。Collation的设置通常由MySQL依据字符集自动处理的，在默认设置里的collation值保留空白就可以。默认的设置：

define(‘DB_COLLATE’, ”);

安全密匙

截至WordPress 2.7后有四个安全密匙来加密cookies。这些密匙只需让它默默无闻地工作就好，并尽可能随意和复杂（你无需记住）。生成这些密匙的最简单方法就是通过WordPress官方密匙服务来自动生成。只要点击这个服务，复制并粘贴生成的结果到wp-config.php 文件中即可。注意，这些密匙可随时更改，这样一来，用户之前的cookies会被清除需要重新登陆你的网站。

define(‘AUTH_KEY’, ‘:dr+%/5V4sAUG-gg%aS*v;&xGhd%{YV)p:Qi?jXLq, define(‘SECURE_AUTH_KEY’, ‘@*+S=8\”\’+\”}] define(‘LOGGED_IN_KEY’, ‘S~AACm4h1;T^\”qW3_8Zv!Ji=y|)~5i63JI |Al[( define('NONCE_KEY', 'k1+EOc-&w?hG8j84>6L9v\"6C89NH?ui{*3\\(t09mumL/fF');

数据库前缀

数据库前缀的设置对提高你的站点安全以及在同一数据库中安装多个WordPress站点都非常有用，通过改变默认值“wp_” 为随机独一的值，可减轻站点受攻击的可能性，总体上提高你的网站安全性。下面是默认值：

$table_prefix = 'wp_';

有很多攻击者就是对准这些默认前缀的数据库进行攻击。稍微修改为如： “x777_”之类的可避免此类攻击。

你还可以使用此设置实现在一个数据库中安装多个WordPress站点，只要给每一个WordPress指定一个单独的数据库前缀即可：

$table_prefix = 'wp1_'; // 第一个博客
$table_prefix = 'wp2_'; // 第二个博客
$table_prefix = 'wp3_'; // 第三个博客

语言设置

WordPress可指定一个语言翻译文件及其相关的目录。语言翻译文件属于 “.mo” 这一类别，其默认位置是 (如果没有明确指定的路径) wp-content/languages (第一)和wp-includes/languages (第二)。下面是默认设置：

define('WPLANG', '');
define('LANGDIR', '');

目录设置

技术上来说，你不太需要关注它。默认的wp-config.php 文件里有几行指定绝对路径并且包含设置文件。我这里提出来，只是为了使这篇文章更完整些：

/** WordPress absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

博客地址和网站地址

默认的p-config.php中不包含这两个定义，不过为了改善WordPress的性能，还是需要添加的。这两个设置是在2.2版本引进来的。在wp-config.php 中添加者两个定义可降低数据库查询数，提高网站的运行。这些设置需与你的WordPress Admin中的设置一致。下面是一个例子 (所有URL地址不以斜线结尾):

define('WP_HOME', 'http://digwp.com');
define('WP_SITEURL', 'http://digwp.com');

可以使用全局变量动态地设置这些值：

define('WP_HOME', 'http://'.$_SERVER['HTTP_HOST'].’/path/to/wordpress’);
define(‘WP_SITEURL’, ‘http://’.$_SERVER['HTTP_HOST'].’/path/to/wordpress’);

模板路径和样式表路径

设定好博客地址和网站地址后，你还可以通过剔除对模板路径和样式表路径的数据库查询，这样可提高站点的性能。下面是默认的值:

define(‘TEMPLATEPATH’, get_template_directory());
define(‘STYLESHEETPATH’, get_stylesheet_directory());

尽管数据库查询还存在，但我们可以减少多余的查询:

define(‘TEMPLATEPATH’, ‘/absolute/path/to/wp-content/themes/active-theme’);
define(‘STYLESHEETPATH’, ‘/absolute/path/to/wp-content/themes/active-theme’);

禁用缓存和缓存有效期

这两个都是针对旧版本的WordPress，还在使用默认的基于对象的缓存机制。第一个选项是启用或禁用缓存。第二个定义让你指定缓存的到期时间。
启用缓存

define(‘WP_CACHE’, true); // 启用缓存
define(‘ENABLE_CACHE’, true); // 启用缓存
define(‘CACHE_EXPIRATION_TIME’, 3600); // 单位秒

禁用缓存

define(‘WP_CACHE’, false); //禁用缓存
define(‘DISABLE_CACHE’, true); // 禁用缓存

指定cookies域

会由于很多原因你需要给站点指定cookies域。比较常见的就是阻止子域名上请求静态内容的cookies不必要的传输。这种情况下，你就可以使用此定义告知WordPress只向非静态域发送cookies，这将会大大提高网站的性能。下面是设置各种cookies路径和域的信息：

define(‘COOKIE_DOMAIN’, ‘.digwp.com’); // 别漏了前面的’.'。
define(‘COOKIEPATH’, preg_replace(‘|https?://[^/]+|i’, ”, get_option(‘home’).’/'));
define(‘SITECOOKIEPATH’, preg_replace(‘|https?://[^/]+|i’, ”, get_option(‘siteurl’).’/'));
define(‘PLUGINS_COOKIE_PATH’, preg_replace(‘|https?://[^/]+|i’, ”, WP_PLUGIN_URL));
define(‘ADMIN_COOKIE_PATH’, SITECOOKIEPATH.’wp-admin’);

覆盖文件权限

如果你的虚拟主机默认文件权限非常严格，在WordPress配置文件里添加这些定义就可以解决这个问题。注意，数值不需要用引号引起来。下面是例子：

define(‘FS_CHMOD_FILE’, 0755);
define(‘FS_CHMOD_DIR’, 0755);

查看所有已定义的常量

需要查看所有已定义的常量吗？用下面的PHP函数就会得到一个所有当前一定义常数的数组：

print_r(@get_defined_constants());

自定义用户和usermeta 表

你也可以通过下面的定义自定义用户和usermeta表：

define(‘CUSTOM_USER_TABLE’, $table_prefix.’my_users’);
define(‘CUSTOM_USER_META_TABLE’, $table_prefix.’my_usermeta’);

FTP/SSH常量

这类定义是用于帮助用户定位和实现FTP/SSH连接。下面是例子:

define(‘FS_METHOD’, ‘ftpext’); // 文件系统的方式，包括： “direct”、”ssh”、”ftpext”和”ftpsockets”
define(‘FTP_BASE’, ‘/path/to/wordpress/’); // 安装根目录的绝对路径
define(‘FTP_CONTENT_DIR’, ‘/path/to/wordpress/wp-content/’); // 到”wp-content” 目录的绝对路径
define(‘FTP_PLUGIN_DIR ‘, ‘/path/to/wordpress/wp-content/plugins/’); // 到”wp-plugins” 目录的绝对路径
define(‘FTP_PUBKEY’, ‘/home/username/.ssh/id_rsa.pub’); // 到SSH公匙的绝对路径
define(‘FTP_PRIVKEY’, ‘/home/username/.ssh/id_rsa’); //到SSH密匙的绝对路径
define(‘FTP_USER’, ‘username’); // FTP 或SSH用户名
define(‘FTP_PASS’, ‘password’); // FTP用户密码
define(‘FTP_HOST’, ‘ftp.domain.tld:21′); //主机名:你的SSH/FTP服务器端口

移动wp-content 目录

从2.6版本开始，你可以修改wp-content目录的位置。这么做有几个理由，包括可提高网站的安全性，以及便于FTP更新。下面是例子：

// 当前目录的完全本地路径(结尾不包括斜杠)
define(‘WP_CONTENT_DIR’, $_SERVER['DOCUMENT_ROOT'].’/path/wp-content’);

// 当前目录的完整URL(结尾不包括斜杠)
define(‘WP_CONTENT_URL’, ‘http://domain.tld/path/wp-content’);

你也可以另外给wp-content 目录指定一个自定义路径。可以解决一些插件的兼容性问题：

//当前目录的完全本地路径(结尾不包括斜杠)
define(‘WP_PLUGIN_DIR’, $_SERVER['DOCUMENT_ROOT'].’/path/wp-content/plugins’);

//当前目录的完整URL(结尾不包括斜杠)
define(‘WP_PLUGIN_URL’, ‘http://domain.tld/path/wp-content/plugins’);

日志修订版的处理

Worepress最新版本提供了一个发布后修改系统，用户可保存不同的博客版本，甚至，如果有需要的话，还可以恢复到先前保存的博客版本。不管你喜欢还是不喜欢这个功能，下面的设置可能都对你有帮助。

限制保存博客版本的数量

define(‘WP_POST_REVISIONS’, 3); // 任意整数，不过不要太夸张。

禁用修订版功能

define(‘WP_POST_REVISIONS’, false);

指定自动保存间隔

跟发布版本功能类似，WordPress其实使用了自动保存功能。默认情况下，WordPress每一分钟自动保存你的作品，不过你完全可以根据需要改变这个数值。不过也注意不要太夸张，以免破坏了你的服务器。

define(‘AUTOSAVE_INTERVAL’, 160); // 单位秒

调试WordPress

自从2.3.1版本以来，有一些错误和警告提示帮助用户调试网站。截止2.5版本，报错等级提高到E_ALL并有激活对一些函数的警告功能。默认(即，没有在wp-config.php文件中指定任何定义)，错误报告被禁用。

define(‘WP_DEBUG’, true); // 启用调试模式
define(‘WP_DEBUG’, false); // 禁用调试模式（默认）

错误日志配置

下面是启用WordPress站点错误日志的一种简单方法。创建一个名为“php_error.log”的文件，使其对服务器可写，并将其放置在你选择的目录下。接着在下面代码中第三行编辑路径，并加入wp-config.php 中：

@ini_set(‘log_errors’,'On’);
@ini_set(‘display_errors’,'Off’);
@ini_set(‘error_log’,'/home/path/domain/logs/php_error.log’);

增加PHP内存

如果你收到错误提示“允许的内存xxx字节已用尽” ，这个设置就对你有帮助了。截至WordPress的2.5版，WP_MEMORY_LIMIT定义，你可以指定PHP使用的最大内存。默认情况下，最大 PHP内存是32兆，因此只有要求大于32兆是菜需要更改此设置。注意，有些虚拟主机禁止你提高PHP 内存，所以你得请求他们帮忙。下面是例子：

define(‘WP_MEMORY_LIMIT’, ’64M’);
define(‘WP_MEMORY_LIMIT’, ’96M’);
define(‘WP_MEMORY_LIMIT’, ’128M’);

保存并显示数据库查询以供分析

这个技术可实现保存并显示数据库查询的信息以备后面分析。这个过程保存了每一次查询、相关的函数以及总的执行时间。这些信息都保存为一个数组的形式，并可显示在任何模板页上。不过，首先得在你的wp-config.php 文件添加下面的指令：

define(‘SAVEQUERIES’, true);

然后，在主题的footer上加上下面的代码：

// 只对admin显示查询数组
if (current_user_can(‘level_10′)) {
global $wpdb;
echo “
”;

print_r($wpdb->queries);

echo “
”;
}

下面是此函数的单行版本:

”; print_r($wpdb->queries); echo “”; } ?>

限制代理访问

WordPress 2.8及以上版本，可用配置文件定义一些常量，包括封锁、允许、过滤从一个代理服务器访问特定主机。例如，如果你的WordPress站点是联网的，你需要阻止访问任何外部主机，只允许本地主机访问，使用下面第一个定义。如果你允许特定主机访问，用逗号分隔主机名称即可，像下面第三个定义一样。注意，请允许api.wordpress.org访问，确保一些核心文件和插件能起到恰当的作用。

define(‘WP_HTTP_BLOCK_EXTERNAL’, true); // 阻止外部请求
define(‘WP_HTTP_BLOCK_EXTERNAL’, false); // 允许外部请求
define(‘WP_ACCESSIBLE_HOSTS’, ‘api.wordpress.org’); // 白名单主机

附原文：

WordPress Configuration Tricks

Many WordPress users know the wp-config.php file as the key to the WordPress database. It is where you set the database name, username, password, and location. You know the one:

The wp-config.php file contains the information required for WordPress to connect to the database

But what many users don’t know is that the wp-config.php file may be used to specify a wide variety of configurational settings, enabling you to improve the functionality, performance, and security of your WordPress-powered site. In this article, I share as many of these configurational tricks as I have been able to collect over the years. This guide covers everything in the WordPress Codex, as well some additional tricks that you probably haven’t seen before. If you know of any other WordPress configuration tricks, share them in the comments and I will add them to the post.

Database Credentials *

This set of four configurational definitions are required for WordPress to connect to the database:
define('DB_NAME', 'database-name');
define('DB_USER', 'database-username');
define('DB_PASSWORD', 'database-password');
define('DB_HOST', 'localhost');
Database name, username, and password should be readily available to you during database creation, but the DB_HOST value may be more difficult to acquire. Most commonly, this value is simply “localhost”, but if that doesn’t work, here are a few other values to try:

1and1 Hosting — db12345678

DreamHost — mysql.example.com

GoDaddy — h41mysql52.secureserver.net

ICDSoft — localhost:/tmp/mysql5.sock

MediaTemple (GS) — internal-db.s44441.gridserver.com

Pair Networks — dbnnnx.pair.com

Yahoo — mysql

You can even specify an alternate port for your database server. Here are two examples:

define('DB_HOST', 'localhost:1234');
define('DB_HOST', 'mysql.domain.tld:1234');

Another cool trick is to detect the database server value automatically:

define('DB_HOST', $_ENV{DATABASE_SERVER});

If all of these fail, or if you are still having problems, consult your hosting provider for assistance.

Database Character Set and Collation *

As of WordPress version 2.2, you may specify a character set for your MySQL database tables. Generally, there is no reason to change the default character-set value of UTF-8, which is usually perfect because it supports all languages. Note that you should only use this definition if it already exists in your wp-config.php file. Here is the default (and recommended) setting:
define('DB_CHARSET', 'utf8');
WordPress version 2.2 also enables you to specify the collation, which is the sort order of your database character set. Setting the collation is generally handled automatically by MySQL according to the character set, which is enabled by leaving the collation value blank as done in the default setting for this definition. Note that you should only use this definition if it already exists in your wp-config.php file. Here is the default (and recommended) setting:
define('DB_COLLATE', '');
Security Keys *

As of WordPress 2.7, there are four security keys available that are designed to insure better cookie encryption. These keys work silently in the background and should be as random and complicated as possible (no, you will never need to remember them). The easiest way to generate these keys is to do it automatically at the WordPress.org secret-key service. Simply visit that link and copy/paste the results into your wp-config.php file. Note that these keys may be changed anytime, and doing so will invalidate all of your users’ existing cookies so that they will have to re-login to your site.
define('AUTH_KEY', ':dr+%/5V4sAUG-gg%aS*v;&xGhd%{YV)p:Qi?jXLq,6L9v\"6C89NH?ui{*3\\(t09mumL/fF');
Database Prefix *

The database prefix setting is particularly useful for increasing the security of your site and for housing multiple WordPress installations in a single database. By changing the default value of “wp_” to something randomly unique, you mitigate commonly targeted attack vectors and improve the overall security of your site. Here is the default setting:
$table_prefix  = 'wp_';
There are tons of crackers out there probing sites for this default database prefix. Changing it to something like “x777_” is a good way to avoid these types of targeted attacks.

You can also use this setting to install multiple instances of WordPress using the same database. Simply specify a unique database prefix for each installation:
$table_prefix  = 'wp1_'; // first blog
$table_prefix  = 'wp2_'; // second blog
$table_prefix  = 'wp3_'; // third blog
Language Settings *

WordPress makes it possible to specify a language-translation file and its associated directory. The language translation file is assumed to be of the “.mo” variety, and its default location (if no explicit path is specified) is assumed to be wp-content/languages (first) and then wp-includes/languages (second). Here is the default setting:
define('WPLANG', '');
define('LANGDIR', '');
Directory Settings *

Technically not something that you should need to mess with, the default wp-config.php file contains a few lines that specify the absolute path and include the settings file. I include them here for the sake of completeness:
/** WordPress absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
	define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');
Blog Address and Site Address

Now we’re getting to some of the cool stuff. By default, these two configurational definitions are not included in the wp-config.php file, but they should be added to improve performance. These two settings were introduced in WordPress version 2.2 and override the database value without actually changing them. Adding these two definitions in your site’s wp-config.php file reduces the number of database queries and thus improves site performance. These settings should match those specified in your WordPress Admin. Here is an example (note that you should not include a trailing slash at the end of either URL):
define('WP_HOME', 'http://digwp.com');
define('WP_SITEURL', 'http://digwp.com');
A cool trick is to set these values dynamically by using the global server variable:

define('WP_HOME', 'http://'.$_SERVER['HTTP_HOST'].'/path/to/wordpress');
define('WP_SITEURL', 'http://'.$_SERVER['HTTP_HOST'].'/path/to/wordpress');

Template Path and Stylesheet Path

As with the predefined constants for blog address and site address (see previous section), you can also boost performance by eliminating database queries for the template path and stylesheet path for your site. Here are the default values for these two definitions:
define('TEMPLATEPATH', get_template_directory());
define('STYLESHEETPATH', get_stylesheet_directory());
As is, these two definitions are still querying the database, but we can eliminate these extraneous queries by hardcoding the values into place:
define('TEMPLATEPATH', '/absolute/path/to/wp-content/themes/active-theme');
define('STYLESHEETPATH', '/absolute/path/to/wp-content/themes/active-theme');
Disable Cache and Cache Expiration

These two options apply to older versions of WordPress that are still using the default object-based caching mechanism. The first definition enables you to enable or disable the cache, while the second definition enables you to specify the cache expiration time.

Enable the cache
define('WP_CACHE', true);      // enable the cache
define('ENABLE_CACHE', true);  // enable the cache
define('CACHE_EXPIRATION_TIME', 3600); // in seconds
Disable the cache
define('WP_CACHE', false);     // disable the cache
define('DISABLE_CACHE', true); // disable the cache
Specify Cookie Domain

There are several reasons why you want to specify a cookie domain for your site. A common example involves preventing cookies from being sent with requests for static content on subdomains. In this case, you would use this definition to tell WordPress to send cookies only to your non-static domain. This could be a significant performance boost. Here are some examples of setting various cookie path and cookie domain information:
define('COOKIE_DOMAIN', '.digwp.com'); // don't omit the leading '.'
define('COOKIEPATH', preg_replace('|https?://[^/]+|i', '', get_option('home').'/'));
define('SITECOOKIEPATH', preg_replace('|https?://[^/]+|i', '', get_option('siteurl').'/'));
define('PLUGINS_COOKIE_PATH', preg_replace('|https?://[^/]+|i', '', WP_PLUGIN_URL));
define('ADMIN_COOKIE_PATH', SITECOOKIEPATH.'wp-admin');
Override File Permissions

If your web host’s default file permissions are too restrictive, adding these definitions to your WordPress configuration file may help resolve the issue. Note that you don’t need the quotes around the permission values. Here is an example:
define('FS_CHMOD_FILE', 0755);
define('FS_CHMOD_DIR', 0755);
View All Defined Constants

Need to view all predefined constants? Good news, this PHP function will return an array of all currently defined constants:
print_r(@get_defined_constants());
Custom User and Usermeta Tables

What about custom user and usermeta tables? Yep, you can do that too, with the following definitions:
define('CUSTOM_USER_TABLE', $table_prefix.'my_users');
define('CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta');
FTP/SSH Constants

This set of configurational definitions is designed to help users locate and utilize FTP/SSH connections. Here is a example set of predefined constants for FTP/SSH updates:
define('FS_METHOD', 'ftpext'); // forces the filesystem method: "direct", "ssh", "ftpext", or "ftpsockets"
define('FTP_BASE', '/path/to/wordpress/'); // absolute path to root installation directory
define('FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/'); // absolute path to "wp-content" directory
define('FTP_PLUGIN_DIR ', '/path/to/wordpress/wp-content/plugins/'); // absolute path to "wp-plugins" directory
define('FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub'); // absolute path to your SSH public key
define('FTP_PRIVKEY', '/home/username/.ssh/id_rsa'); // absolute path to your SSH private key
define('FTP_USER', 'username'); // either your FTP or SSH username
define('FTP_PASS', 'password'); // password for FTP_USER username
define('FTP_HOST', 'ftp.domain.tld:21'); // hostname:port combo for your SSH/FTP server
Moving Your wp-content directory

As of WordPress version 2.6, you may change the default location of the wp-content directory. There are several good reasons for doing this, including enhancement of site security and facilitation of FTP updates. Here are some examples:
// full local path of current directory (no trailing slash)
define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'].'/path/wp-content'); 

// full URI of current directory (no trailing slash)
define('WP_CONTENT_URL', 'http://domain.tld/path/wp-content');
You may also further specify a custom path for your wp-content directory. This may help with compatibility issues with certain plugins:
// full local path of current directory (no trailing slash)
define('WP_PLUGIN_DIR', $_SERVER['DOCUMENT_ROOT'].'/path/wp-content/plugins'); 

// full URI of current directory (no trailing slash)
define('WP_PLUGIN_URL', 'http://domain.tld/path/wp-content/plugins');
Dealing with Post Revisions

Recent versions of WordPress provides a post-revisioning system that enables users to save different versions of their blog posts and even revert to previously saved versions if necessary. Regardless of how much you do or do not despise this amazingly awesome feature, here are a couple of configurational definitions that may prove useful for you ;)

Limit the number of saved revisions
define('WP_POST_REVISIONS', 3); // any integer, but don't get too crazy
Disable the post-revisioning feature
define('WP_POST_REVISIONS', false);
Specify the Autosave Interval

In a similar vein as the post-revisioning feature is WordPress’ actually useful Autosave functionality. By default, WordPress saves your work every 60 seconds, but you can totally modify this setting to whatever you want. Don’t get too crazy though, unless you want to stress-out your server ;)
define('AUTOSAVE_INTERVAL', 160); // in seconds
Debugging WordPress

Since WordPress version 2.3.1, users have been able to display certain errors and warnings to help with the debugging of their site. As of WordPress version 2.5, enabling error reporting raises the reporting level to E_ALL and activates warnings for deprecated functions. By default (i.e., if no definition is specified in the wp-config.php file), error reporting is disabled.
define('WP_DEBUG', true); // enable debugging mode
define('WP_DEBUG', false); // disable debugging mode (default)
Error Log Configuration

Here is an easy way to enable basic error logging for your WordPress-powered site. Create a file called “php_error.log”, make it server-writable, and place it in the directory of your choice. Then edit the path in the third line of the following code and place into your wp-config.php file:
@ini_set('log_errors','On');
@ini_set('display_errors','Off');
@ini_set('error_log','/home/path/domain/logs/php_error.log');
Increase PHP Memory

If you are receiving error messages telling you that your “Allowed memory size of xxx bytes exhausted,” this setting may help resolve the issue. AS of WordPress version 2.5, the WP_MEMORY_LIMIT definition enables you to specify the maximum amount of memory that may be used by PHP. By default, WordPress will automatically attempt to increase PHP memory up to 32MB, so this setting is only needed for values higher than 32MB. Note that some web hosts disable your ability to increase PHP memory, so you may need to beg for them to do it. Here are some examples:
define('WP_MEMORY_LIMIT', '64M');
define('WP_MEMORY_LIMIT', '96M');
define('WP_MEMORY_LIMIT', '128M');
Save and Display Database Queries for Analysis

This technique is perfect for saving database queries and displaying the information for subsequent analysis. The process saves each query, its associated function, and its total execution time. This information is saved as an array and may be displayed on any theme template page. To do this, first add the following directive to your wp-config.php file:
define('SAVEQUERIES', true);
Then, in the footer of your active theme, place the following code:
// display the query array for admin only
if (current_user_can('level_10')) {
	global $wpdb;
	echo "";
	print_r($wpdb->queries);
	echo "";
}
Here is a single-line version of this function:
"; print_r($wpdb->queries); echo "
"; } ?>
Control Proxy Access

Since WordPress 2.8, the configuration file may be used to define constants involved with blocking, allowing and filtering access to specific hosts from behind a proxy server. For example, if you host your WordPress site on an intranet network, you may prevent access to all external hosts and only allow requests from localhost and your blog using the first definition below. You may also allow specific hosts access with a comma-separated list of allowed hostnames, as demonstrated in the third definition below. Note that you should allow api.wordpress.org access to ensure proper functionality of core files and plugins.
define('WP_HTTP_BLOCK_EXTERNAL', true);  // block external requests
define('WP_HTTP_BLOCK_EXTERNAL', false); // allow external requests
define('WP_ACCESSIBLE_HOSTS', 'api.wordpress.org'); // whitelist hosts

修改WordPress的默认发件人名称

jacobxx — Tue, 25 Aug 2009 09:03:31 +0000

本文转载自WordPress啦！

通过WordPress的后台可以轻松添加一个新的用户。2.8之后的版本，还可以通过邮箱发布信息。这个功能不错，不过却没有可修改寄件人的设置。例如，邮件必须以administrator的名义发送。

不过，可通过两个hooks 来修改寄件人。你可以通过一个小插件轻松地实现修改寄件人的姓名及邮箱地址。

可通过下面的代码获得该插件，不会在数据库中留下任何数据。想要修改寄件人的用户都可以用哦！

/**
* @package WP Mail From
* @author Frank Bültge
* @version 0.1
*/

/*
Plugin Name: WP Mail From
Plugin URI: http://bueltge.de/
Description: Change the default address that WordPress sends it’s email from.
Version: 0.1
Author: Frank Bültge
Author URI: http://bueltge.de/
Last Change: 11.08.2009 08:41:06
*/

if ( !function_exists(‘add_action’) ) {
header(‘Status: 403 Forbidden’);
header(‘HTTP/1.1 403 Forbidden’);
exit();
}

if ( !class_exists(‘wp_mail_from’) ) {
class wp_mail_from {

function wp_mail_from() {
add_filter( ‘wp_mail_from’, array(&$this, ‘fb_mail_from’) );
add_filter( ‘wp_mail_from_name’, array(&$this, ‘fb_mail_from_name’) );
}

// new name
function fb_mail_from() {
$name = ‘My Blog is my Blog’;
// alternative the name of the blog
// $name = get_option(‘blogname’);
$name = esc_attr($name);
return $name;
}

// new email-adress
function fb_mail_from_name() {
$email = ‘info@example.com’;
$email = is_email($email);
return $email;
}

}

$wp_mail_from = new wp_mail_from();
}
?>

每个相关函数中的姓名和邮箱地址必需保持一致。此后，检查这两个值，这一步不是必需的。

注意：函数esc_attr()是在2.8版本后才出现的，原来的函数是attribute_escape()。如果更早版本的用户想要使用此方案，需先修改这个函数。

这样修改后，用户就不会再看到寄件人是“WordPress”了！

附原文：

Change WordPress Mail Sender

August 19th, 2009 by Frank • WordPress Plugins • 2 Comments

WordPress makes it easy and fast to add new users in the backend. Since version 2.8 of WordPress, it can send the access information via email. A nice feature, with no additional settings to change the sender of this email. For example the email should be send from the administrator instead from WordPress.

Nevertheless, there is a possibility and with the help of two hooks, the sender can be changed. I created a small Plugin, where you can easy and simple adjust the sender name and sender email.
-
The Plugin is available in the following source code and has no options for the backend and doesn’t leave any data in the database. Anyone who wants can simply extend the Plugin.


/**
 * @package WP Mail From
 * @author Frank Bültge
 * @version 0.1
 */

/*
Plugin Name: WP Mail From
Plugin URI: http://bueltge.de/
Description: Change the default address that WordPress sends it’s email from.
Version: 0.1
Author: Frank Bültge
Author URI: http://bueltge.de/
Last Change: 11.08.2009 08:41:06
*/

if ( !function_exists('add_action') ) {
	header('Status: 403 Forbidden');
	header('HTTP/1.1 403 Forbidden');
	exit();
}

if ( !class_exists('wp_mail_from') ) {
	class wp_mail_from {

		function wp_mail_from() {
			add_filter( 'wp_mail_from', array(&$this, 'fb_mail_from') );
			add_filter( 'wp_mail_from_name', array(&$this, 'fb_mail_from_name') );
		}

		// new name
		function fb_mail_from_name() {
			$name = 'My Blog is my Blog';
			// alternative the name of the blog
			// $name = get_option('blogname');
			$name = esc_attr($name);
			return $name;
		}

		// new email-adress
		function fb_mail_from() {
			$email = 'info@example.com';
			$email = is_email($email);
			return $email;
		}

	}

	$wp_mail_from = new wp_mail_from();
}
?>

The values for name and email have to be maintain in each of the associated function. After that, the two values are getting examined, but is not necessarily needed.

As a note: the function esc_attr() is only since version 2.8 available and replaces the function attribute_escape(). Should the solution be used in an earlier version, then you have to change the function.

For suggestions and improvements, I am grateful, as always. You can use this Plugin to improve WordPress a bit and the user is not surprised about the sender “WordPress”.

创建一个可翻译的WordPress模板

jacobxx — Tue, 25 Aug 2009 08:50:06 +0000

本文转载自WordPress啦！

虽然英语是网络上最有代表性的语言，不过制作主题时多为其他语言用户考虑给他们提供翻译化的主题，当然更好。在这里就一步步教大家如何让WordPress主题可翻译成任何语言。

1 添加必要的函数

从最基本的入手，首先在functions.php 里添加下面的代码：

load_theme_textdomain( ‘Cats Who Code’, TEMPLATEPATH.’/languages’ );
$locale = get_locale();
$locale_file = TEMPLATEPATH.”/languages/$locale.php”;
if ( is_readable($locale_file) )
require_once($locale_file);

看第一行有load_theme_textdomain() 函数，这个函数的作用是允许你加载文本域名。你可以选择任何独一无二的域名。最好选择你的主题名称。

2 国际化主题

翻译WordPress主题，要使用到php gettext 函数。 GetText有两个函数: _e 和 __ (两条下划线)。 “_e”是用来显示 “单纯”文本, __ 函数用于显示已经使用PHP标签的文本。 例如:

注意上面的文本域名(Cats Who Code)必须与functions.php里的文本域名保持一致。

比较枯燥的部分工作是用这些函数代替每一个字符串。这就得看你的主题里有多少字符串了，可能要花点时间。据说利用GNU 工具可以很容易实现从文件从提取字符串，不过我没有试过也不知道如何。有兴趣的朋友可以用谷歌搜索xgettext。

3 创建.po文件

完成上面两个步骤，你的WordPress主题就可以翻译为任何语言。不过要用其他语言显示出来，需要添加.po文件。

.po 文件是一个可变对象，指的是那些包含字符串及字符串另一种语言的译本的文件。例如，如果你下载法语版的WordPress主题，主题包里就会有fr_FR.po 文件。这个文件就包含了所有让你的主题用法语显示的翻译。你的主题就会用法语“Bienvenue ”显示而不是用英语“Welcome”。

好在这次你无需在的主题文件里面查找所有需要被翻译的字符串。一个免费的在线工具icanlocalize.com可以帮你扫描PHP文件并创建.po文件。ICanLocalize 会自动提取所有包含__(“txt”, “domain”) 和 _e(“txt”, “domain”) 的字符串，包括所有双引号和单引号中的字符串以及任何字符编码。

还可以通过专门的免费软件PoEdit来编辑Po文件。

你得翻译每一个文本字符串，翻译完后保存.po文件。PoEdit会生产一个.mo文件（.po文件的编译版）。

4 实施
到此为止，你已经完成了最难的部分，剩下的就是定义WordPress主题地域。

首先是要获得你的语言和国家代码，例如，你的语言是中文，你居住在中国。你的代码为zh_CN。你可以通过GNU gettext手册的页面找到你的国家代码和语言代码。

获得你的代码后，打开wp-config.php文件查找WPLANG常数，如果存在直接用你的代码取代当前的代码，如果不存在，在wp-config.php添加下列代码（用你的需要的语言代码）即可：

define (‘WPLANG’, ‘zh_CN’)。

附原文：

How to make a translatable WordPress theme

Althought English is the most represented language over the Internet, it is a good thing to think about people who speak other languages and offer them trabslated WordPress theme. In this step-by-step tutorial, you’ll learn how to take a WordPress theme and make it translatable for any language.

1 – Add the needed functions

Let’s start by the basics: Paste the following lines of codes on your functions.php file.

load_theme_textdomain( 'Cats Who Code', TEMPLATEPATH.'/languages' );

$locale = get_locale();
$locale_file = TEMPLATEPATH."/languages/$locale.php";
if ( is_readable($locale_file) )
	require_once($locale_file);

On line 1, you see the load_theme_textdomain() function. This function allow you to load a Text Domain. You can pick up any name, but keep in mind that it have to be unique. So the best practice should be to use your theme name.

2 – Internationalize your theme

For translating our WordPress theme, we’re going to use the php gettext functions.
GetText has two functions: _e and __ (two underscores).
The “_e” function is used to print “simple” text, and the __ function is used when the text to be displayed is already wrapped in php tags.

Examples:

Notice again the text domain name (Cats Who Code) above, remember that it should be the same as in the functions.php file.

The boring part is that you have to replace each single string by the required function. Depending on how many strings your theme have, this can take a lot of time. I’ve heard of some GNU tools to easily extract strings from files, but as I never tried it I can’t say anything about it. For those interested, google xgettext.

3 – Create your .po file

Now, your WordPress theme can easily be translated to any languages. But to display text in a foreign language, you have to add a .po file.
.po files stands for Portable Object. basically, theses files contains a string, and its translation in another language. For example, if you download the French version of WordPress, you’ll have a fr_FR.po file in the archive. This file contains all the translations needed for your theme to speak French, so your theme will say Bienvenue instead of Welcome.

Good news, you don’t have to search throught your theme files for all the string to be translated. A free online tool named icanlocalize.com can scan PHP files and create .po files for you ICanLocalize will extract all strings wrapped in __(“txt”, “domain”) and _e(“txt”, “domain”) calls. Strings can be enclosed in either double quotes (“) or single quotes(‘) and with any character encoding.

Po files can be edited with PoEdit, a free software especially dedicated to that task:

As you probably guessed, you have to translate each text string. Once you translated it all, save the .po file. PoEdit will also generate a .mo file, which is basically a compiled version of the .po file.

4 – Implementation

Right now, you have done the most “difficult” part of the job. The only thing you have to do is to define your WordPress locale.
To do so, the first thing to do is to get your language and country code. For example, if your language is French and France is your country of residence, your code will be fr_FR. The GNU gettext manual contains pages to help you find both your country and language codes.

Once you have your codes, open your wp-config.php file and look for the WPLANG constant. If it exists, simply replace the existing code by yours. If it doesn’t exists, simply paste the following line (with your own code, of course)

define ('WPLANG', 'fr_FR');

Sources

The following articles has been very useful to me for writing this post. Thanks to the authors.

在WordPress上将评论与Trackback分开显示

jacobxx — Tue, 25 Aug 2009 08:46:15 +0000

本文转载自WordPress啦！

早在WordPress 2.7版本发布时，WordPress团队就开发了一种全新的评论样式，其中包括嵌套回复，评论的处理发生了戏剧性变化。不幸的是，这一变化却打破了最受欢迎的评论方式：trackback与评论分开。

从那以后，有人就开始想办法在WordPress 2.7及以上版本的博客中实现分离trackback和评论。我在Sivel.net 中找到了目前为止最好的方法，大家可以通过这里查看。按照那里提示的步骤操作就可以了。

注意: 上面的指南只适用于WordPress 2.7 或以上版本。如果是WordPress 2.6或更旧的版本用户，请查看这里。

成功将trackbacks和评论分开后，还可以通过几个小步骤来完善显示效果。首先就是将你的trackbacks/pingback只显示标题而不显示摘要和所有的其他东西，看起来更简洁了。在comments.php 找到下面的代码：

将其替换成：

然后把以下代码添加到functions.php中：

function list_pings($comment, $args, $depth) {
$GLOBALS['comment'] = $comment;
?>

”>

这样trackbacks/pingbacks 区域就比较简洁了，你也可以通过插件显示tweetbacks。

另外，你可能还想修改评论数量，让它显示实际的评论数量，也就是筛除默认评论中包含的trackbacks/pingbacks评论数。只要在functions.php中添加下面的代码即可:

add_filter(‘get_comments_number’, ‘comment_count’, 0);
function comment_count( $count ) {
if ( ! is_admin() ) {
global $id;
$comments_by_type = &separate_comments(get_comments(‘status=approve&post_id=’ . $id));
return count($comments_by_type['comment']);
} else {
return $count;
}
}
?>

附原文：

Separating Trackbacks from Comments in WordPress 2.7+

Back when WordPress 2.7 was released, the WordPress team introduced a completely revamped comment form that included integration of threaded comments into the core software, introducing some dramatic changes with how comments are handled. Unfortunately, this change broke one of the most popular comment hacks, separating trackbacks from comments.

Since then, several people have stepped up and shared some great hacks for separating trackbacks from comment in WordPress 2.7 or newer blogs . So far the best guide I’ve found came from Sivel.net, which can be viewed here. Click over and follow those steps get everything separated.

Note: The above guide is only for people using WordPress 2.7 or newer installations. For people using WordPress 2.6 or earlier, you’ll want to use this tutorial.

Once you’ve got the comments successfully separated from the trackbacks, there are a couple additional tweaks you may want to do to clean up how things look (it really depends on preference I suppose). The first is to clean up your trackbacks/pingbacks by only displaying the title instead of an excerpt and everything else. In order to do this, you’ll need to find the following code in your comments.php file:

Now replace that code with the following:

Lastly, you’ll need to add the following code to your functions.php file (which can be created if you don’t already have one):

function list_pings($comment, $args, $depth) { $GLOBALS['comment'] = $comment; ?>

That should clean up the trackbacks/pingbacks section and you can also apply the same changes if you use a plugin to display tweetbacks.

The other thing you may want to do is fix the comment count to only show actual comments, filtering out the trackbacks/pingbacks which are included in your comment count by default. Simply add the following code to your functions.php file (which again can be created if you don’t already have one):

add_filter('get_comments_number', 'comment_count', 0); function comment_count( $count ) { if ( ! is_admin() ) { global $id; $comments_by_type = &separate_comments(get_comments('status=approve&post_id=' . $id)); return count($comments_by_type['comment']); } else { return $count; } } ?>

给WordPress模板制作者的7个建议

jacobxx — Tue, 25 Aug 2009 08:23:32 +0000

本文转载自WordPress啦！

1. 了解所有的模板标签

WordPress编写代码时一定要注意模板标签。当然你也可以通过简单的PHP代码实现同样的效果，不过，还是尽可能使用WordPress的模板标签。

模板标签参考指南: http://codex.wordpress.org/Template_Tags

2.了解所有的WordPress 选项

主题制作者经常犯的一个错误就是忽略了WordPress选项。你可能会问，那是啥？呵呵，我说的就是WordPress后台设置里可以设置的默认选项。举一个简单的例子:

很多主题都有固定的发布日期和时间格式：

访客看到的效果是这样的: June 10, 2009 at 10:53

但是，要是博客管理员想要另外的时间显示格式呢？他会找到设置下的一般选项然后修改格式，但是最终显示的却还是旧的格式。

正确的做法是运用下面的代码:

$dateformat = get_option(‘date_format’);
$timeformat = get_option(‘time_format’);
the_time(“$dateformat \a\\t $timeformat”); ?>

这样管理员才能真正控制要显示的时间格式，为你的客户减少不少烦恼，帮助论坛中的客户提交Ticket也就随之减少。

选项参考指南: http://codex.wordpress.org/Option_Reference

3. 了解所有的WordPress函数

如果你想对博客布局做大的修改，你得对WordPress的很多函数和参数都要很了解。

有时候，因为你有几年的PHP经验，就会决定用自己的方法去写函数，以为可以取得更好的效果，殊不知这是在浪费时间。始终使用WordPress的功能，对你的用户来说帮助更大。

参考: http://codex.wordpress.org/Function_Reference

4. 给核心的WordPress边栏附件添加基本的样式

如果你计划开发多款主题，我建议你给一些基本（但流行）的WordPress边栏附件创建共同的样式模板，如：文档，日历，搜索，标签云等。

WordPress这些附件一般都使用相同的ID 和类别，因此在你的样式表中不难找到它们。就算它们与你的主题设计不是很搭配，还是尽量这么做。你会发现它会为你省力不少。

5. 不要依靠第三方的插件和附件

这也是另一个常见的错误：主题制作者强迫用户安装一些插件。更糟糕的是，都不检查内置的功能。例如，使用WP-Pagenavi翻页功能来取代WordPress默认的翻页。

错误做法:

在这个例子中，如果没有安装该插件，此行结束后WordPress 将停止执行任何东西，这就是为什么一些主题会莫名其妙出错的原因。

正确做法:

6. 给所有元素创建模板文件

很多主题仅使用到一些模板文件：archive.php, index.php, page.php, search.php, single.php.就这么多，完了。

其实，还可以通过创建其它很多模板文件改善主题的整体体验。如样式模板: author.php, attachment.php, video.php,等。

参考: 模板层次图http://codex.wordpress.org/Template_Hierarchy#Visual_Overview

7.创建一个主题选项(控制面板)页面

如果你还没有使用它，那么现在按我说的做。在给你的主题完成第一个控制面板页面的时候，你就会意识到它还是让你轻松不少。

附原文：

7 Essential Tips for WordPress Theme Developers

When I first started with WordPress (in March 2009) I already had over 3 years of PHP experience. I was used to developing my own CMS engines for my clients, so the first days with WordPress were rather curious: changing core WordPress functions, templates, etc.

After that, with the help of Pavel (@ciorici), I decided to play by the rules: learn The WordPress Way.
Think the way WordPress thinks, instead of working around it.

I hope this list of advices will help starting WordPress theme developers as well as some more experienced ones.

1. Learn all Template tags

When coding a design into WordPress, you really should pay attention to Template Tags. Of course you can achieve the same thing by simple php coding, however, it is better to stick to WordPress Template Tags as much as you can.

For reference: http://codex.wordpress.org/Template_Tags

2. Learn all WordPress options

A common “mistake” of theme developers(coders) is that they forget about WordPress Options.
What is that you may ask? Well, remember all those default options that can be set in Dashboard > Settings? That’s what I’m talking about.

Let me give you a simple example:
Many themes have hardcoded the format of post date and time:

view source print ?

1.'F j, Y \a\t G:i'); ?>


The visitor in turn would see something like this: June 10, 2009 at 10:53
However, what if the blog’s administrator would like to have a different time format? He goes to Settings > General, changes the format and… nothing. The theme still shows the old format.
The correct way to do it would be similar to this:
 


view sourceprint?


1.

2.$dateformat = get_option('date_format');
3.$timeformat = get_option('time_format');
4.the_time("$dateformat \a\\t $timeformat"); ?>


Now the administrator is in full control over how the date and time is shown. Less frustration for your clients, less support tickets in the forums  
For reference: http://codex.wordpress.org/Option_Reference
3. Learn all WordPress functions
If you would like to make major changes in the basic layout of a blog, you will probably have to rely on many functions and conditionals.

Sometimes, if you have a couple of years of PHP experience (guilty), you would decide to “make things better” and end up writing many functions of your own.

That will steal time [and flexibility].

Always try to rely on core WordPress functions. Your customers will thank you later.
For reference: http://codex.wordpress.org/Function_Reference
4. Add basic styling to core WordPress widgets
If you plan on developing more than 1 theme, I recommend creating common style templates for a couple of basic (but popular) WordPress widgets, such as: Archives, Calendar, Search, Tag Cloud, etc.

WordPress always uses same ID and Class for these widgets, so it is not hard to find them and include in your stylesheets.
Even if they don’t quite fit into your theme design, try to do that. That will earn you some karma points.
5. Don’t rely on third-party plug-ins and widgets
This is another common mistake: theme developers “assume” that users will have certain plug-ins installed. To make matters worse, they include functions from these plug-ins without checking for their presence.
For example if you want to use the WP-Pagenavi navigation instead of the default WordPress navigation.
Doing it wrong:

 


view sourceprint?


1.


In this case, if the plug-in is not installed, WordPress will stop executing anything after this line. This is the reason why some themes “break” unexpectedly.
Doing it right:

 


view sourceprint?


1.if (function_exists('SEO_pager'))  {

2. SEO_pager(); } ?>


6. Create template files for all elements
Most themes use just a couple of templates file: archive.php, index.php, page.php, search.php, single.php. That’s it.

Well, there are many other templates that could improve the overall experience with your theme. You might want to style templates like: author.php, attachment.php, video.php, etc.
Reference: Template Hierarchy Diagram http://codex.wordpress.org/Template_Hierarchy#Visual_Overview
7. Create a Theme options (control panel) page
If you’re not using them already, let me tell you this: after you complete your first options page for your theme, you will realize how much freedom that gives you.
Some tutorials to get your started:

ThemeForest: Create an Options Page For Your WordPress Theme
ForTheLose: How To: Create a Theme Options Page for Your WordPress Theme

晓闻心雨 » WordPress 翻译

不用插件如何在文章中插入音频

WordPress是否该维护旧版本？

Supported Legacy Branches For WordPress.org?

What’s A Legacy Branch?

How Might It Work?

Objections

1. It’s too much work to maintain.

2. There’s no demand for one.

3. It’s too confusing for users.

Discuss

WordPress进入实时时代: 750万博客 实现同步RSS订阅

RSSCloud和WordPress.com

WordPress也许可以实现实时，不过RSS实时还尚早

WordPress Enters Real-Time: 7.5 Million Blogs Reach Twitter Speed

RSSCloud and WordPress.com

WordPress May Be Realtime, but RSS Isn’t Quite Yet

十招阻止WordPress中的垃圾评论

1. 安装Akismet

2. reCAPTCHA

3. 邀请读者回答简单的算术问题

4. 阻止垃圾trackbacks

5. 用户登录后评论

6. 通过IP地址阻止垃圾评论

7. 通过禁止黑名单列表IP访问来阻止垃圾评论

8. 拒绝不相关的评论请求

9. 阻止内容盗用

10. 阻止图像盗用

Top 10 ways to stop spam in WordPress

1. Install Akismet

2. reCAPTCHA

3. Ask your readers to do 1+1

4. Stop spam trackbacks

5. Make users login to comment

6. Ban spammers by IP

7. Ban spammers by IP, on a massive scale

8. Deny comment posting to no referrer requests

9. Stop content theives

10. Stop spammers stealing your images

使用WordPress内置的缓存机制

Use WordPress Cache

玩转WordPress配置文件

数据库信息

数据库字符集和整理(collation)

安全密匙

数据库前缀

语言设置

目录设置

博客地址和网站地址

模板路径和样式表路径

禁用缓存和缓存有效期

指定cookies域

覆盖文件权限

查看所有已定义的常量

自定义用户和usermeta 表

FTP/SSH常量

移动wp-content 目录

日志修订版的处理

指定自动保存间隔

调试WordPress

错误日志配置

增加PHP内存

保存并显示数据库查询以供分析

限制代理访问

WordPress Configuration Tricks

Database Credentials *

Database Character Set and Collation *

Security Keys *

Database Prefix *

Language Settings *

Directory Settings *

Blog Address and Site Address

Template Path and Stylesheet Path

Disable Cache and Cache Expiration

Specify Cookie Domain

Override File Permissions

View All Defined Constants

Custom User and Usermeta Tables

FTP/SSH Constants

Moving Your wp-content directory

WordPress进入实时时代: 750万博客实现同步RSS订阅