文章分类: WordPress

全世界竟然有超过40%的网站是基于WordPress创建的!
博主对WordPress长期深入研究,并有着大量的实践案例,总结了大量的博文笔记,是一位WordPress“硬核”玩家。
本博客不做泛泛的插件、主题分享,博主致力于WordPress深入开发技术的研究,主张牢牢掌握WP核心的开发能力,尽可能脱离插件和主题的束缚。

WordPress自定义文章类型和自定义分类共用同一个根路径slug

在WordPress中如果注册一个自定义文章类型(Custom Post Type),并且同时为这个类型注册一个自定义分类法(Custom Taxonomy),两者使用同一个根slug,访问这个类型的页面就会发生404报错。

这个slug具体指什么呢?举例说明:
https://www.my-site.com/product/123.html
https://www.my-site.com/product/term-name

以上URL分别作为product类型页面的详情页和分类列表页,URL中的product就是根slug。在使用register_post_type注册product文章类型的时候,代码体现为:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
add_action('init', 'create_product_post_type', 0);
function create_product_post_type() {	
	register_post_type('product', array(
		'label' => 'Products',
		'public' => true,
		'show_ui' => true,
		'show_in_menu' => true,
		'capability_type' => 'post',
		'hierarchical' => false,
		'rewrite' => array('slug' => 'product'), //注意此行
		'supports' => array('title','editor','thumbnail'),
		'labels' => array (
			'name' => 'Products',
			'singular_name' => 'Product',
			'menu_name' => 'Products'
			)
		)
	);
}

注意第11行的rewrite参数,就为此自定义类型指定了根slug,即形成如下url:
https://www.my-site.com/product/123.html 查看详细 »

使用WP Super Cache予取予求地刷新指定页面静态缓存

WP Super Cache是我一直以来都在使用的超级缓存插件,他可以帮我们的网站快捷的打开静态缓存,从而大大提高访问速度,节约服务器资源。本人切身感受,同一台服务器,在所有的WP网站都启用静态缓存,并且把图片视频字体等静态资源存入CDN后,服务器的利用率可以提高80%甚至更多。这款插件的设置技巧,搜索引擎上能找到一大堆,本文就不重复了。

本文讨论在某些应用场景下,如何有效地刷新单个页面的缓存。举个例子,一些博客网站有点赞功能,点赞的数据一般我们会作为一个文章自定义字段存储在数据库中,而页面上显示的赞数是在静态缓存页面里的,访客新点了一个赞,数据库里面的那个数字是+1了,但缓存过的页面并不会刷新这个数字,你按多少次F5都没用。

这时候我们就需要手动刷新一下显示这个赞数的页面静态缓存。访客不能进入网站后台,他自己如何刷新页面静态缓存呢? 查看详细 »

把WooCommerce产品购买数量的选项改为下拉菜单

WooCommerce产品数量的选项如图所示,这是一个HTML5的数字输入框,代码表现为

<input type="number" id="***" class="input-text qty text" step="1" min="1" max="" name="quantity" value="1" placeholder="" inputmode="numeric">

这样的输入框可以让用户输入任意数字,直接把一定数量的产品加入购物车。但在一些场合下,用户其实还是更希望有个下拉菜单形式的输入框,从而可以直接选择想要购买的数量。这种场合比较适用于购买数量不多,或者日常库存不多的产品,比如不超过20件的情况。因为如果数量一多,恐怕整个屏幕高度都不够下拉列表的数字显示,反而会对用户造成更大的不方便。

下来菜单其实就是一个select元素,替换掉原来的数字框,在商品页面的前后页面表现是这样的:

查看详细 »

WooCommerce产品页面中添加用户自定义字段(product add-on),并使其影响价格

给WooCommerce产品页面添加自定义字段,并使其影响价格,在很多电商的场景中会需要这个功能。注意这里强调的是用户自定义字段,而非我之前写的 博客 介绍的产品自定义字段,两者不是一个东西。
举几个例子:

  • 卖T-Shirt的网站开通自定义产品的业务,比如让用户在产品页面输入希望印在T-Shirt上的文字。由于输入的文字是随机的,不可能预先设定好产品变量满足需求,只能在产品页面上添加让用户可以自己填写的字段。用户输入文字,即代表产品有定制部分,价格会在基础款式的基础上增加一些。
  • 刻字服务,提供一个字段让用户输入姓名,根据姓名的字数生成新的价格。
  • 蛋糕定制,允许用户填写自己的祝福语在蛋糕上,根据祝福语的长度生成新的价格。
  • 单个产品添加注释字段。我之前写过给订单增加额外注释字段的文章,但如果用户需要对订单内每个产品写需求注释,则用这个功能会更好。
  • 其他,诸如贺卡定制、各种礼物、工艺品、日用品定制等等,都可能需要这个功能…

WooCommerce产品用户自定义字段,英文翻译叫做“WooCommerce product add-on”,在产品页面上可以这样表现:
WooCommerce产品用户自定义字段
我们可以同时添加多个字段,也可以用select、radio、checkbox,datepicker,甚至是file uploader做自定义字段。

要实现这个功能,市面上已经有不少插件了,在官方插件市场上搜一下“WooCommerce product add-on”关键词,就能找到不少同类插件。我测试过过几款,发现功能都差不多,它们也都有免费版和收费版两个版本。一般来说,这类插件的免费版提供各种常规类型的自定义字段,收费版则提供一些特殊类型的自定义字段。另外如果你需要通过这些字段影响商品价格,这个功能我没有在免费版里见过,都需要购买付费版实现。付费版价格在39 – 69美元之间,看上去并不贵。但我的原则仍然是能不用插件就不用,需要用户自定义字段的场景,实际上字段都不多,这个功能不复杂,完全可以自己写出来。 查看详细 »

2021年WordPress的市场份额继续飞速上涨

唠点软话题,非技术范畴的。

以下图片是今年1月和8月的网站CMS市场份额对比图。这个统计是整个互联网的网站所使用的各家CMS(内容管理系统)的占比,简单拿排名第一的WordPress来说,就是在2021年8月,全网有42.4%的网站是基于WordPress搭建的,这是一个几千万的数量级。上下对比则可以看到WordPress在7个月内又多占了接近3%的份额,而3%已超过排名第三的Joomla当前的总份额了,WP的涨势仅用了7个月就吃掉了第三名以后任何一家的总份额,非常惊人。这不是一个野鸡统计表,它来自于w3techs.com,链接点此

这对于一直在使用WordPress建站的我们来讲,也是有很大的激励作用的。虽然我们并不卖主题和插件,不怎么靠WordPress原生的生态吃饭,但每每看到有优秀的网站是使用WordPress搭建的时候,内心就很受鼓舞。
查看详细 »

WordPress文章字段查询meta_query各种高级用法列举

WordPress meta_query 高级用法

WordPress在get_posts或WP_Query方法中,活用meta_query,可以变换出无数种高级检索,是WordPress的入门技能。

最简单的用法,查询自定义字段“post_color”值为“red”的文章

$arr = array(
	'post_type', => 'post',
	'meta_key' => 'post_color',
	'meta_value' => 'red'
);
$myPosts = new WP_Query( $arr );

引入meta_compare参数,查询自定义字段“post_color”值不为“red”的文章

$arr = array(
	'post_type', => 'post',
	'meta_key' => 'post_color',
	'meta_value' => 'red',
	'meta_compare' => '!='
);
$myPosts = new WP_Query( $arr );

推荐写法

下面开始进阶用法,首先要换一种写法,把所有自定义字段相关的参数都打包到meta_query参数中,效果和上面一段一样:

$arr = array(
	'post_type', => 'post',
	'meta_query'=> array(
		'key' => 'post_color',
		'value' => 'red',
		'compare' => '!='
	)
);
$myPosts = new WP_Query( $arr );

查看详细 »

WordPress不用插件实现多张特色图片/缩略图Featured Images

WordPress的文章、页面或者自定义文章类型开启特色图片,通过注册这个类型时,在support中添加参数“thumbnail”实现,比如:

register_post_type('My CPT', array(
	'label' => 'my_cpt',
	'description' => '',
	'public' => true,
	'show_ui' => true,
	'show_in_menu' => true,
	'capability_type' => 'post',
	'hierarchical' => false,
	'rewrite' => array('slug' => 'product'),
	'query_var' => true,
	'supports' => array('title','editor','thumbnail') //这里有了thumbnail就能为my_cpt这个类型添加缩略图
	)
);

这个缩略图有没有可能变成多张呢?比如这样:

查了老半天,WordPress本身并没有提供多张特色图片的API,但这个功能完全可以通过自定义字段实现。本文即是这个原理 查看详细 »

基于WordPress的微信小程序支付功能开发

我在2018年的时候总结过一篇微信小程序支付功能开发与踩坑经验总结,当时因为网上相关文档和资源的缺乏,文章获得了很多关注和转载,并且也有很多人指出了其中的不足。主要不足之处就在于那篇文章把所有的签名字串封装都放到了前端,也就是小程序里,通过JS实现,其中还涉及到了商户key这样的敏感字段,因此是不安全的。不过在3年前微信本身对这块也没有做很严格的限制,比如我把对“https://api.mch.weixin.qq.com/pay/unifiedorder”这个接口的请求放在小程序里,那时候照样是能运行的。

近期,把小程序的基础库改成近期版本后,我发现“https://api.mch.weixin.qq.com/pay/unifiedorder”这个接口的请求已经不能放在小程序里了,即使此域名已经加入到request安全域名下也无效,微信那边会自动把你加入的这个域名过滤掉。这就表示一系列的请求必须放到服务器上完成了。因此我重新整理了一下后端的代码,PHP版本的。并且因为我的微信小程序都是基于WordPress做后端的,索性把自定义的接口这块也缝合过来。

当前最新版调试通过:

打包代码如下: 查看详细 »

WordPress JWT认证授权方式测试调研和开发心得

本文接上回WordPress OAuth 1.0认证方式测试调研,研究JWT认证方式。

JWT,全称JSON Web Token。在WordPress应用场景中,客户端通过JSON格式发送登录信息到WordPress网站,网站返回用户的基本信息,附带一串token给客户端;客户端在下次请求写入数据的时候,在请求头上带上这一串token作为用户标识就可以了。由于token是从网站发来的,客户端不需要做任何的数据处理,只要存储一下这一串token就可以了,很便捷。因为这种便捷性,国内用微信小程序或其他客户端连接WordPress的项目,大部分都是用JWT实现的,如果我说的不对请留言指正:)

使用JWT,先安装插件:JWT Authentication for WP REST API

然后在WP的根目录下修改wp-config.php,增加以下两行配置,开启JWT接口:
define('JWT_AUTH_SECRET_KEY', 'abcdefg...'); //填个复杂点随机字符串
define('JWT_AUTH_CORS_ENABLE', true);

以上准备工作完成,接下来回到Postman测试发送请求。

1. 发送用户名和密码的JSON格式到 https://www.mysite.com/wp-json/jwt-auth/v1/token

返回数据中,除了邮箱、用户名和全名外,注意第一行的token,需要在客户端存储一下,安全起见,推荐存在客户端的后端,尽量不放在前端。 查看详细 »

WordPress OAuth 1.0认证授权方式测试调研

这两天有新项目需要用到站外登录WP,操作WP网站的数据,之前在一些小项目中,通过Rest API操作网站数据,我都是通过Basic认证的。Basic认证有一个安全方面的缺点,就是每次发送请求,都需要把用户名和密码base64编码到请求的header里。这样就得在站外存储WP网站的用户名密码,如果在站外没有做好安全,不小心泄露这个登录信息,就会造成安全问题。为了规避这种漏洞,我的方式是在WP站内建一个秘密用户,只分配用得到的权限,用户在站外请求我的Rest API,如果要写数据,我用一个中转的节点,加上这个秘密用户的用户名密码组成的header去请求数据。当然,这当中还要加上识别用户的业务逻辑,比如用手机号码做用户字段,这就不另外展开了…

所以我重新考虑OAuth认证方式,谷歌了不少资料,网上大家比较公认的是这一篇:https://code.tutsplus.com/tutorials/wp-rest-api-setting-up-and-using-oauth-10a-authentication–cms-24797
如果你也研究过OAuth和Rest API,你应该也看过这篇文章或者它的翻译版本。

一开始我觉得跟着上面那篇tutsplus上的教程跑一遍就好了,也没必要特意写这篇文章去总结。然而实际操作过程还是踩坑了,所以需要自己记录一下,复盘一下跑通OAuth1.0的过程。本文无代码,都是测试截图。
查看详细 »