EMwI插件启用失败的问题

有几名External Media without Import的用户向我反馈说插件启用失败,提示语法错误。其中还有一名用户就此问题在github上向我提了一个issue。具体的错误提示是Parse error: syntax error, unexpected T_STRING in …….external-media-without-import.php on line 25。

然而external-media-without-import.php的第25行仅仅是一个名字空间定义:

经过调查与沟通,发现原因是用户使用的PHP版本低于5.3.0,而PHP到了5.3.0才引入名字空间的特性,见PHP 5.3.0 Release Announcement。起初用户以为自己的PHP版本是5.6.30,但依据经验我猜测对方机器上可能有多个PHP版本,并且WordPress使用了较老的PHP。后来用户在自己的WordPress上安装了Display PHP Vesion插件,果然发现WordPress用的是PHP 5.2.17。

因此各位用户如果遇到这个启用失败的问题的话,请用Display PHP Vesion插件查看一下WordPress所用的PHP版本,确保PHP是5.3.0或更高的版本。

想不到那么老的PHP版本都还是有很多国内外用户在用啊。

EMwI插件更新:防XSS攻击

8月底的时候External Media without Import插件在github上收到一个pull request。对方指出我的代码存在XSS漏洞。惭愧,直到最近才腾出时间仔细研究他说的问题。插件的1.0.2版本合并了对方的pull request,修复了该漏洞。

在修复之前,我的插件中有如下代码(点击查看源文件):

这个函数将width 、height 和mime-type等信息通过 urlencode编码后设置为url的参数,然后重定向到该url。在url的响应函数中,我调用了 urldecode读取来这些信息: 继续阅读EMwI插件更新:防XSS攻击

WordPress官方的代码审查意见

在向WordPress官方首次提交插件代码的时候,我收到了对方的反馈邮件。WordPress官方在邮件中对我的代码提出了一些审查意见,其中的内容挺值得学习的,因此在这里分享一下。其实大致意思就两点:一是后端不要信任前端发来的数据,要多做检查和处理,这是做后端的常识;二是尽量使用WordPress已有的API而不要自己直接调用curl。

原文如下:

There are issues with your plugin code.

Please read this ENTIRE email, address all listed issues, and reply to this email with your corrected code attached. It is required for you to read and reply to these emails, and failure to do so will result in significant delays with your plugin being accepted.

Also please remember in addition to code quality, security and functionality, we require all plugins adhere to our guidelines. If you have not yet, please read them:

* https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

## Please sanitize, escape, and validate your POST calls

When you include POST/GET/REQUEST calls in your plugin, it’s important to sanitize, validate, and escape them. The goal here is to prevent a user from accidentally sending trash data through the system, as well as protecting them from potential security issues.

SANITIZE: All instances where generated content is inserted into the database, or into a file, or being otherwise processed by WordPress, the data MUST be properly sanitized for security. By sanitizing your POST data when used to make action calls or URL redirects, you will lessen the possibility of XSS vulnerabilities. You should never have a raw data inserted into the database, even by a update function, and even with a prepare()  call.

VALIDATE: In addition to sanitization, you should validate all your calls. If a $_POST  call should only be a number, ensure it’s an int()  before you pass it through anything. Even if you’re sanitizing or using WordPress functions to ensure things are safe, we ask you please validate for sanity’s sake. Any time you are adding data to the database, it should be the right data.

ESCAPE: Similarly, when you’re outputting data, make sure to escape it properly, so it can’t hijack admin screens. There are many esc_*()  functions you can use to make sure you don’t show people the wrong data.

In all cases, using stripslashes  or strip_tags  is not enough. You need to use the most appropriate method associated with the type of content you’re processing. Check that a URL is a URL and don’t just be lazy and use sanitize_text  please. The ultimate goal is that you should ensure that invalid and unsafe data is NEVER processed or displayed. Clean everything, check everything, escape everything, and never trust the users to always have input sane data.

Please review this document and update your code accordingly: http://codex.wordpress.org/Validating_Sanitizing_and_Escaping_User_Data

Example:

WordPress comes with an extensive HTTP API that should be used instead of creating your own curl calls. It’s both faster and more extensive. It’ll fall back to curl if it has to, but it’ll use a lot of WordPress’ native functionality first.

https://developer.wordpress.org/plugins/http-api/

—-

Please make sure you’ve addressed ALL issues brought up in this email.

译文:

继续阅读WordPress官方的代码审查意见

搭建本地WordPress开发调试环境

WordPress的运行环境是很传统的Apache + MySQL + PHP,其中PHP用的是PHP5,因此部署过程中应该不会有很难解决的问题,只不过步骤可能会比较繁琐。除此以外就是调试的配置需要摸索一阵子。

一开始我曾想过花钱买MAMP PRO来搭建WordPress的本地开发环境(MAMP免费版本只支持PHP7),图省事。但后来还是决定自己折腾,省下这笔钱。于是花了那么几天自己搭建了一套本地WordPress编码、运行和调试环境。除了Apache + MySQL + PHP之外,为了能在编辑器中单步调试,我还给PHP加装了Xdebug扩展,并给Vim编辑器加装了Vdebug插件。最终我将自己的WordPress站点从云主机拷贝到了本地,并在Vim中愉快地编写和调试里面的PHP代码:

让我哭笑不得的是,在我把环境搭建好一个月后写这篇文章的过程中,才发现其实Mac本身已经自带了Apache和PHP,并不用我自己去下载源代码再安装。

继续阅读搭建本地WordPress开发调试环境

让WordPress媒体库支持外链图片

最近有一个月左右没更新了,因为这个月的业余时间都在忙于一个WordPress插件:External Media without Import。

其实只是很小很简单的一个插件,代码不过短短几百行。不过这东西一旦被当成产品认真做起来,依然让我感到——每天在上班时间以外,应对完工作上的需求和bug之后,接着还要在业余时间认真做好另一个产品是多么劳心劳力。这是我正式发布并打算认真维护的第一个个人项目。为此我还自己设计制作了用于WordPress官方渠道的插件图标和Banner:

闲话少说,还是来介绍一下这个插件。先列出插件地址。

插件的WordPress官方渠道地址:

https://wordpress.org/plugins/external-media-without-import/

插件的Github地址:

https://github.com/zzxiang/external-media-without-import

继续阅读让WordPress媒体库支持外链图片