标签: 开发经验

使用 Github Action 发布 WordPress 插件

black and white penguin toy

WordPress 官网的插件系统采用的是 SVN 来进行管理,如果你希望将自己的插件发布至 WordPress 官网,就必须在本地安装 SVN,不太利于项目的管理。此外,WordPress 官网提供的是一个发布系统,而非版本控制系统(只是将 SVN 用作插件管理,并不是真打算让你每一个变更都提交),因此,你还是需要使用另外的版本控制系统(比如 Git)来管理你的代码。

为了简化发布,你可以采用 GitHub Action 来完成你的插件自动发布,这样你就可以使用 Git 来开发和管理你的插件,并让 Github Action 自动进行插件的发布。

具体操作

1. 配置 Action Secrets

因为你需要使用版本控制来进行发布,以及可能存在的协作开发的场景,处于安全的考虑,你应该将你的 SVN 的信息放置在 Action Secrets 当中。

在仓库当中找到 Secrets – Actions ,新建两个 Secrets:SVN_USERNAMESVN_PASSWORD,配置上你的 SVN 账号信息,稍后将会使用你的这个账号信息来进行插件的发布

2. 创建一个 .distignore 文件

.distignore 文件可以帮助你实现忽略不需要发布到 WordPress 插件系统的文件,这样就让你的插件目录变得更加干净一些。在你的仓库根目录创建一个 .distignore 文件,并填写具体要忽略的文件,即可实现部分发布至 WordPress 插件目录。

以下是我的 Example

node_modules/
.github/
.git/
.distignore
.gitignore
package.json
package-lock.json
yarn.lock

3. 创建 Action 文件

在你的项目的 .github/workflows/ 中创建一个 publish.yml文件,并在其中添加如下代码即可。

name: Publish to WordPress Plugin Directory
on:
  push:
    tags:
    - "*"
jobs:
  tag:
    name: New tag
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - name: Build # 如果没有 NPM 相关构建工作,可以去除这一步。
      run: |
        npm install
        npm run build
    - name: WordPress Plugin Deploy
      uses: 10up/action-wordpress-plugin-deploy@stable
      env:
        SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
        SVN_USERNAME: ${{ secrets.SVN_USERNAME }}
        SLUG: wpstoreapp-spellcheck

4. 发布版本

接下来只需要执行如下操作,既可以发布版本

git add .
git commit -m 'feat: release new version'
git tag 1.0.0
git push && git push origin 1.0.0

上述代码中的 1.0.0 即为具体的版本号,可以根据你的诉求进行修改。

总结

在完成了配置后,后续你的插件发布就变得十分简单了:修改本地的 readme.txt 中的版本号,加入 changelog,并修改插件文件头中的版本,即可提交一个 commit ,添加对应的版本的 tag,然后 Push 到 Github 上,由 Github 来进行插件的发布。

而如果你是以公司/团队的形式来管理插件,也可以用类似的方式,这样虽然每个人都不掌握 SVN 的账号密码,但却可以完成插件的发布,十分方便。

在 WordPress 的插件页面添加更多的连接

turned-on monitor

WordPress 的插件页面提供了不少的 Hooks,可以帮助我们实现自定义的插件页面,让用户在启用插件后,第一时间可以看到我们为其提供的功能,从而降低用户使用的成本。

以上图为例,你可以看到,我在左侧的功能区添加了「配置 Token」和「购买额度」;右侧的更多链接区提供了帮助手册和联系我们,帮助用户优化体验,更快的了解如何使用你的插件。

左侧功能区

首先,在左侧功能,WordPress 提供了两个 Filter来实现这个功能:

一个是 plugin_action_links,这个插件传入两个参数,一个是当前插件的链接构成的数组,另一个则是插件的文件路径,你可以根据传入的参数判断当前是使用哪个插件,并通过返回不同的数组,来实现不同的功能。

另外一个则是 plugin_action_links_wpstore-spellcheck/wpstore-spellcheck.php,是在上一个 filter 的基础之上,加入了插件的路径,从而让你可以无需进行判断,直接针对对应插件来完成链接的修改。

以上图效果为例,具体的代码如下

function wpstoreapp_plugin_action_link($links, $file)
{
	if($file == plugin_basename(dirname(__FILE__) . '/wpstore-spellcheck.php')){
		$links[] = '<a href="./options-writing.php">配置 Token</a>';
		$links[] = '<a href="https://api.wpstore.app/plugins/spell-check/pricing" target="_blank">购买额度</a>';
	}
	return $links;
}

add_filter('plugin_action_links', 'wpstoreapp_plugin_action_link', 10, 2);

这里我选择的是第一种实现方式,主要的原因是我无法保证用户安装插件一定是采用的是 WordPress 插件目录的安装方式,因此,在这种情况下,第二种带了路径的 filter 的名字是有可能发生变化的。

右侧更多链接区

右侧更多链接区可以用来承载联系我们、帮助文档等入口,从而实现用户在使用时,可以快速找到相应的辅助资料,从而获得更好的体验。

从实现的逻辑上来看,和在左侧功能区添加链接的基本逻辑是一样的,需要判断当前插件是否是目标插件,如果是,则可以根据需要添加功能。

add_filter( 'plugin_row_meta', 'wpstoreapp_plugin_row_meta', 10, 2 );

function wpstoreapp_plugin_row_meta( $links, $file ) {
	if ( plugin_basename( __FILE__ ) == $file ) {
		$row_meta = array(
			'docs'    => '<a href="https://www.wpstore.app/?p=291">帮助手册</a>',
			'contact'    => '<a href="mailto:hi@wpstore.app">联系我们</a>'
		);

		return array_merge( $links, $row_meta );
	}
	return (array) $links;
}

总结

WordPress 为我们提供了方便的 Hook,可以让我们可以自定义我们想要的功能,借助这些功能来降低你的用户的 Landing 成本,从而实现更好的服务用户,是一个不错的选择。

如何“抄”一个 WordPress 插件

silver mercedes benz emblem on blue surface

WordPress 作为 CMS 生态的第一产品,PHP 生态的护城河,可以说,只要 WordPress 不死,PHP 就还能继续活下去。而 WordPress 团队也在不断迭代项目。因此,有不少的开发者以 WordPress 开发为生。

而得益于 WordPress 基于 GPL 开发的,所以,理论上,如果你开发的插件是通过 WordPress 官方的目录分发的,你的插件是需要以 GPL 兼容的协议开源的,这也给了想要开发同款插件的开发者们提供了机会。

PHP in WordPress themes must be GPL, artwork and CSS may be but are not required.

Matt Mullenweg, https://wordpress.org/news/2009/07/themes-are-gpl-too/

不过,需要注意的是,只有 PHP 的插件源码才需要以 GPL 兼容协议开源,CSS 和图片文件不需要开源,而随着 Gutenberg 编辑器的不断推广,以后的插件可能不太好“抄”了。

在这篇文章,我们不再讨论 Gutenberg 功能的研究,只谈插件的 PHP 部分。

如何理解 WordPress 的插件开发?

《人人都能学会的 WordPress 课程》当中,我曾经介绍过 WordPress 的插件的运行机制。如果现在用一个更加简单的说法来探讨这个问题的话,WordPress 是通过提供do_actionapply_filter这两个方法,实现了功能的可修改性。而插件则需要 add_actionadd_filter 这个方法来影响 WordPress 的运行表现

当你明白这个问题之后,你就会意识到,如果我们需要解析一个插件的运行机制,来开发自己的同类型插件之时,唯一要做的其实就是找到对应的 Action 和 Filter,修改 WordPress 的运行表现。

因此,你接下来要做的事情就变得简单很多,你需要做的,仅仅是在插件的代码中搜索所有的 add_actionadd_filter,并记录下对应的 action 和 filter 的名字,在 Code Reference 当中搜索对应的 action 的应用场景和用法即可。

Tips

  1. 按照 WordPress 的开发规范,插件的目录中一定有一个和其目录名相同的 PHP 文件,这个文件是 WordPress 插件的入口文件,你只需要从这个插件看起,就能找到你想要了解的实现方式。
  2. WordPress 插件的代码都可以在 WordPress Directory 中找到,你只需要在 Development 目录中,就可以找到对应的插件的源码。

如何从 WordPress 插件目录下架一个插件

silver mercedes benz emblem on blue surface

我在 WordPress 官方上架了不少的插件,但不少的插件如今我已经不再维护了。

再加上现在我开始重新调整 WPStore,因此,决定下架其中一些不再维护的插件,减少 WordPress 官方插件系统中的无用插件。

操作步骤

1. 登陆你的 WordPress.org 的账号,并找到你要下架的插件

比如,我这里希望下架早年为 Payjs 写的付费阅读插件。

2. 点击 右下角的 Advanced View

在 Details 页面找到 Advanced View 的连接,并点击进入 Advanced View 页面。

3. 在 THE DANGER ZONE 中关闭插件

进入 Advanced View 页面之后,向下拖动,在底部的 THE DANGER ZONE 中可以找到 「Close This Plugin」,点击按钮,并在弹出的窗口中,点击确认即可。

4. 删除完成

当你看到如上界面时,就说明你这个插件已经完全关闭了。

总结

其实 WordPress 并没有要求你关闭掉每一个插件,不过从插件的维护角度来看,关闭一个不再维护的插件可以减少你后续的服务的成本,也是一个不错的选择。

WordPress 官方的 Code Reference应该如何使用?

silver mercedes benz emblem on blue surface

如果你要开发 WordPress ,必然会用到 WordPress 官方的文档。而在官方文档当中,除了各种 Handbook ,最重要便是 Code Reference

在使用 Code Reference 的时候,也是存在一些技巧的。

搜索你需要的函数、Hooks、Filter、Class

访问 Code Reference 主页,可以看到有一个搜索框,在这里你可以输入你要搜索的关键词,并在下拉框中筛选出你要用的具体的函数/Hooks/Filter/Class

当然,如果你在开发过程中,明确了你要查询的某个特定的函数,也有一个简单的方式来查询,只需要将下方的链接中的 FUNCTIONNAME 替换为你要查询的函数名,就可以直接跳转到对应的函数的详细界面,查看对应的函数的功能。

https://developer.wordpress.org/reference/functions/FUNCTIONNAME/

如果你查询的是 Hooks、Filter 也有类似的方法,WordPress 的单个函数/Hooks/Filter 的URL非常的明确,因此,你可以在写代码的时候,随时把你需要查询的函数直接复制出来,替换浏览器地址栏中的方法名即可。

理解 Code Reference 的内容

<a href="https://developer.wordpress.org/reference/functions/download_url/" title="download_url">download_url</a> 为例,在 Code Reference 当中,大体上会分为以下几个区域

Description
Parameters
Return
Source
Related
 - Uses
 - Used By
Changelog
User Contributed Notes
 - Feedback

Description

这里介绍了这个函数的基本介绍,一些时候,也会在这个区域加入一些使用的 Tips。

不过这个描述并非每一个函数都会有。

Parameters

参数区域说明了这个函数的入参有哪些,你可以对着入参的介绍调用函数,从而避免传入错误的参数

Return

返回值定义了具体的返回值,你可以根据返回值来判断具体的结果。不仅如此,点击里面的链接,可以跳转到对应的类,查看对应返回结果的类型。

Source

Source 部分则给你了函数的具体的代码,对于一些你在开发过程中百思不得其解的函数,读一下这个函数的源码可能会让你茅塞顿开。

对于比较长的函数,点击 Expand 就可以展开看。如果你希望在本地看,左上角也告诉你了这个函数在具体哪个文件可以查看。你可以直接按图索骥,找到本地的对应函数来查看。

Related

Related 当中分为两个区块,分别是 Uses 和 Used By ,分别介绍当前这个函数是基于哪些函数实现的(Uses)和其他哪些函数使用了当前这个函数(Used By)

有了 Uses 和 Used By,你就可以自己封装一个类似的函数,也可以看看其他的函数是如何调用当前这个函数,心中更有数。

Changelog

Changelog 当中记录了这个函数的具体的变更历史,你就可以非常方便的去了解到一个函数的发展历史,可能某个功能你过去用的好好的,最近不能用了,就是因为函数发生了更新。

User Contributed Notes

在 User Contributed Notes 当中,记录了别人对于这个函数使用的反馈,你可以看到其他开发者是如何使用这个函数的。当你在使用这个函数/Hook出现问题时,就可以参考一下其他人贡献的笔记,可能会更好的帮助你来理解这些 Notes。

总结

用好 WordPress 自带的 Code Reference 可以帮助大家更好的开发 WordPress 的各种功能,花点时间了解一下 Code Reference ,相信可以帮到你~

如何对项目中的图片进行压缩

red and white nescafe ceramic mug

在昨天的文章中,我们找到了项目中的大文件是什么,而大多数时候,你会发现项目中的大文件都是图片,只要对图片压缩一下,就可以轻松获得空间的释放。

为什么图片可以被压缩?

图片记录的信息包括颜色和坐标,而颜色会有很多是相同的。通过对于相同颜色可以进行合并处理。此外,图片压缩软件还会去除图片中的一些冗余信息,让空间只为必须的资源所用。

因此, 我们可以借助一些手段,来压缩项目中的图片,快速释放项目空间,为项目的代码留出空间。

如何批量对图片进行压缩?

其实互联网上一直都有不少的网站可以很好的完成对图片的压缩,比如 tinypng.org

tinypng.org

但这些网站的问题是一方面需要依赖网络,另一方面是对于项目的图片有限制,比如 tinypng 一次只能压缩 20 张图片,在你实际进行压缩的时候,就会遭遇项目中的文件太多,无法一次性压缩完成。

因此,这篇文章中,我会用一款免费软件来完成压缩 —— 图压

图压

图压支持 Windows 和 macOS 操作系统,你可以在你的日常开发环境中安装它,用来压缩项目中的图片。

你可以下载并安装图压,将项目中的图片文件拖入图压,就可以对图片进行压缩。

操作示意图

需要注意的是,图压默认并不会覆盖你的文件,而是在你的项目中生成原文件名-tuya的新图片,如果你需要覆盖图片,则需要点击下方的更多设置,在保存路径中,选择覆盖原文件。

压缩效果

就压缩效果而言,对于图片几乎可以实现 60% ~ 70% 左右的压缩,效果可以说是很不错了。对于一些图片特别多的项目,单纯图片压缩,就可以为项目节省 30% 左右的空间,还是非常可观的。

总结

图压是一个很好用的图片压缩软件,你可以在开发的时候,借助图压对项目中的图片进行压缩,从而实现优化项目的体积,让小程序的打开更加迅速

如何将 HTTP 请求中的 UA 转化为可读的 UA 信息

red and white nescafe ceramic mug

什么是 UA (User Agent)

UA 是 HTTP 在发送请求的时候,带上的请求方的各项基本信息。就我自己为例,我的 UA 是 Mozilla/5.0 (Macintosh; Intel Mac OS X 11_1_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36 Edg/88.0.705.50

这个 UA 当中包含了大量的我的基本信息,包括我的电脑信息、我的操作系统、浏览器的版本等。

在具体的 UA 信息中,具体的结构为

User-Agent: <product> / <product-version> <comment>

如果有多组 UA 信息,则语法如下

User-Agent: Mozilla/5.0 (<system-information>) <platform> (<platform-details>) <extensions>

UA 能够帮助我们理解什么?

UA 可以提供设备的基本信息,比如浏览器、比如设备的版本号等,有了这些信息,我们就可以分析用户的使用习惯、使用场景等信息。

比如,当 UA 中有大量的访问是来自微信浏览器,那么你就可以考虑针对微信的浏览器提供一些优化,比如使用微信自带的第三方 SDK 等信息。

如何将 UA 转换为可读的 UA 信息?

各种语言都有自己的 SDK 来实现从 UA 的 String 提取出操作系统的信息,一般来说,都是通过正则表达式来识别的,你可以在 Github 上找到你所使用的语言提供的 SDK。

不过,除了使用开源的 SDK 以外,你还可以考虑使用一些服务来进行解析,比如我今天发现的 User Stack

UserStack 是一个 UA 识别服务,如果你接入该服务,就无需自己维护 User Agent 的识别规则,由服务帮你维护,你只需要调用该 API 即可实现对设备的识别。

总结

UA 转换为人类可读的信息需要通过第三方 API 或开源的 SDK 来实现,你可以根据自己的需要来选择不同的方案。SDK 免费可用,但可能更新不够频繁,无法很好的兼容一些重要的设备。