再收录一篇我自己在知乎平台的回答，因为有不少客户也问过我同样的问题，我的回答总是和大部分建站公司有一些不同之处，各位可以参考。老样子，先上原帖连接：https://www.zhihu.com/question/616170013/answer/3156028663
无论你是做B2B还是B2C的网站，此文都适用。
理想状态下，不管有多少人访问你的网站，语言都是越多越好，因为越多语言意味着你网站页面数量越多，页面数量越多则代表着你网站可被搜索引擎索引的收录页面越多。但是，这里面有一个重要前提是你必须保质保量地做好各语言的翻译工作，而不是用机翻糊弄了事。所以这个问题接下去又变成了一个成本与效果的取舍问题。可不是嘛，几乎所有的工作都是成本与效果的取舍。
为什么你必须自己做翻译，而不能用机翻？因为现代浏览器本身就有机翻功能，我们用的最多的谷歌浏览器菜单里就自带谷歌翻译，你用的机翻插件八成也是谷歌翻译，何苦做这种脱裤子放屁的举措呢？
我的一篇知乎回答，其实也是很多SEO新手会问的问题，略作修改后收录到博客。原答：https://www.zhihu.com/question/607406981/answer/3081451254
过去几年中我在不少于50个网站上使用Yoast SEO插件，大部分为免费版，付费版客户只有四五个。对大部分企业网站来说免费版完全够用，没必要让我的客户再去掏钱购买付费版。
先说结论，绿点有一定的参考价值，但要分场合。
绿点（SEO分析工具）的大致原理：Yoast会用你在“Focus keyphrase”中填写的关键词作为分析基点，检查你的文章标题、正文内容是否符合SEO条件，给出一个分值，如果分值高则显示绿点。
那么问题来了，有两种情况你是不可能拿到分值的。
WordPress的本地化最标准的手段是通过翻译文件进行翻译，之前写过一篇博客“WordPress很多插件不支持中文怎么办？”简单地介绍了实现方法。即使你不会写一行代码，也能通过Poedit这款软件对WP的主题和插件进行翻译。
不过有时候我们会需要对某个页面的某个字段，进行特别标注的翻译，不使用po文件里的翻译，这怎么实现呢？
其实很简单，通过gettext钩子，单独写一个函数返回特定的翻译内容即可：
1 2 3 4 5 6 | //from: https://blog.brain1981.com add_filter('gettext', 'brain1981_change_translation', 20, 3); function brain1981_change_translation( $translated_text, $untranslated_text, $domain ){ //... do something return $translated_text; } |
开启评论的WordPress网站默认会在有用户提交评论后，发邮件给管理员；出于网站安全考虑我们还会把评论设置为需要通过审核才能发布，这种情况下评论通知邮件会变成“有评论需要审核”通知邮件。这两个设置在后台的Setting – Discussion下。如果你的网站比较“热闹”，你就会经常收到评论通知邮件。如果你不想这样被频繁打扰，也可以去掉这两个勾选：
查看详细
新手用WordPress喜欢装各种插件，装了这些插件又苦于他们没有中文界面…
这是一篇本人写于知乎问题的回答，自己博客再发布一下，文章略有修订。原答链接：https://www.zhihu.com/question/55772594/answer/2975663716
WordPress庞大的生态，使全世界任何国家地区的开发者都可以加入为他开发插件和主题，所以在这个生态里，绝大部分插件和主题都是第三方开发者开发的，这个第三方可以是技术实力雄厚的公司，也可以仅仅是一个个人开发者，甚至可能是个刚刚研究WordPress没几天的初学者。这些人中，母语汉语的中国人不是没有，但总体比例肯定是少之又少。
如果一个不说汉语的人开发了一款插件或主题，那它的界面自然是基于开发者的母语的，如果想要它提供中文界面，就需要另一位懂中文的人翻译这款插件。翻译插件/主题还有一个重要前提，就是被翻译的插件/主题需要基于标准的语言规则，把界面文本写入po文件，这样其他语种的人才能借助翻译软件，像填excel表那样填写对应字段的翻译。
这是用Poedit软件打开po文件，进行插件/主题翻译的截图：
做基于WooCommerce的微信小程序，一个绕不开的技术点是需要自己写购物车的接口。WooCommerce至今都没有在自带的Rest API中提供购物车接口，我一直认为这是一个遗憾。
在查了一些资料后，我大致能明白WooCommerce不提供购物车接口的原因，因为大部分的第三方并不需要WooCommerce来提供购物车数据。如果你用WordPress+WooCommerce做后台，开发了一款独立APP，用户可以在APP上完成完整的购物流程，最轻便的做法是不让WooCommerce提供购物车数据，购物车只在APP本身提供即可，WP后台只负责提供商品和订单信息足矣。所以WooCommerce提供的Rest API是足够完成一款普通的第三方应用的需求的。但我们考虑另一种情况，如果你的WooCommerce同时以网站和APP两端提供服务，即同一个用户既能登录网站购物，也能从APP购物，那么你就要考虑购物车的数据同步问题了，要让网站的购物车和APP的购物车同步，我们就不得不需要WooCommerce端有购物车接口了。
这篇博客是对去年写过的一篇“WooCommerce购物车对象使用以及方法函数概括”，进行的一个扩展。在熟悉了购物车一些对象和方法使用后，我们是可以自己写一个购物车接口的。
首先定义一下接口：
1 2 3 4 5 6 7 8 9 10 11 12 | add_action('rest_api_init', function(){ //from: https://blog.brain1981.com register_rest_route('wx_app/v1', 'cart', array( 'methods' => 'GET', 'callback' => 'brain1981_rest_wc_cart_list', 'show_in_index' => false, 'permission_callback' => function ($request) { if (current_user_can('read')) return true; } )); }); |
访问这个接口的地址就是 https://你的域名/wp-json/wx_app/v1/cart， 主要业务代码放在brain1981_rest_wc_cart_list函数中。下面是这个函数的写法： 查看详细
本文源自我在知乎的一篇回答，略有修改。原答链接：https://www.zhihu.com/question/507937340/answer/2285849519
我们算是设计行业的一员，但不得不承认在某些时候，过度设计会是一种浪费，因为好的设计肯定是要花钱的，而对于一些不需要设计就能高效获客的场景，你的确（暂时）不需要太注意页面设计。
这种场景哪里有？举个例子，在一个小县城做垂直业务，比如开锁、卖肥料、装摄像头…如果你是这个地区这个业务唯一的网站/小程序/APP，只你一家，那你就可以不必花钱做设计了。但若是有任何一个竞争对手出现，他的网站看起来比你漂亮专业，你就得开始弥补设计短板，要不然客户很快会被对手抢去。 查看详细
WordPress 6.1是近期发布的版本，如果你持续关注WordPress的更新和对网站的优化，会发现更新到6.1版本后，会多引用一个名为classic-themes.min.css的样式表。
该样式表很小，里面只有一条对按钮的定义，对网站并不会造成明显的影响，但毕竟是多引入了一个通常都无用的文件。本着“应优化尽优化”的原则，我们可以取消对改样式表的引入。 查看详细
woocommerce_order_item_product这个函数，在很多插件里都用到过，但是这个函数自从WooCommerce 3.0版本就开始过期了，如果你用的插件或者主题里还包含了这个函数，会产生一个这样的报错：“woocommerce_add_order_item_meta is deprecated since version 3.0.0! Use woocommerce_new_order_item instead”
尽管报错信息里提示用woocommerce_new_order_item函数代替，但实际上woocommerce_new_order_item函数的参数和woocommerce_order_item_product并不完全相同，不能靠直接替换函数名称来解决问题。
之所以写这一篇博客，是因为我之前的一篇关于产品自定义字段的博客里有代码遇到了这个报错。这里重新贴一下这段代码：
//6.在订单中保存自定义字段 add_action( 'woocommerce_add_order_item_meta', 'brain1981_product_add_on_order_item_meta', 10, 2 ); function brain1981_product_add_on_order_item_meta( $item_id, $values ) { if ( !empty( $values['my_custom_addon'] ) ) { wc_add_order_item_meta( $item_id, 'my_custom_addon', $values['my_custom_addon'], true ); } } //from: https://blog.brain1981.com |
写在前面，WordPress多站点并不适合初学者，而对于熟悉WordPress开发的人来说，也应该慎用。WordPress多站点本身是一个比较理想化的解决方案，它在某些维度上简化了拥有多个网站的站长的管理流程，节约了服务器的空间；但它也增加了一层系统结构上的复杂度，使你在操作网站搬家、迁入等大的维护工作的时候容易踩坑。比如对于数据库，如果是单个WordPress网站搬家，我通常只要直接导出数据库就行了，而对于多站点中的子站点就需要做一些额外工作了。本文只讨论WordPress多站点的建立流程，因为我最近正好又为一位客户实施了一次，可以完整滴梳理一下实施过程和容易出错的地方。
WordPress多站点有两种形式，子域名和子目录。这次要配置的是子目录形式，也就是站点一是abc.com/site1 ; 站点二是abc.com/site2 这种形式。
首先，到原站点的设置 – 常规 页面中，把站点地址由原来的 abc.com形式，添加你需要的子目录名，变为 abc.com/site1，并保存设置。此时你访问 abc.com，浏览器会自动跳转到 abc.com/site1 。 查看详细
