置顶信息：这些年来我们已经积累了几十家客户，一百多个由我们独立完成的项目案例。团队虽小，能量却很大。不同于个人的单打独斗，我们一直把JennyStudio作为一家正规公司运营着，把每一个项目当作自己的孩子一样培育。
长期承接外包项目，若你有WordPress相关的建站需求，微信小程序开发需求、H5页面设计制作需求，请移步JennyStudio。
Gravity Forms提供了强大的表单系统，但是它的电话号码格式却没有11位手机号码的格式，虽然我们可以用International这个选项代替（就是不限制格式），但终归不够完美。查了一下官方文档，把这个需求给填上吧。
直接上代码：
add_filter( 'gform_phone_formats', 'brain1981_phone_format' ); function brain1981_phone_format( $phone_formats ) { $phone_formats['china mobile'] = array( 'label' => '手机号码', 'mask' => false, 'regex' => '/^1(?:3\d|4[4-9]|5[0-35-9]|6[67]|7[013-8]|8\d|9\d)\d{8}$/', //手机号码正则 'instruction' => "11位手机号码", ); return $phone_formats; } |
早有耳闻微信小程序的支付功能开发是一步一坑，这两天果然踩了个遍。除了简要到令人愤怒的官方文档外，网上所有能搜到的相关文章，也没有任何一篇提供的代码是能够顺利跑通的。好在还有一部分前人的经验可以吸取，再加上个人的一点直觉引导，终于在凌晨的时候真机测试通过。
趁热打铁把踩过的坑罗列一遍，最后会附上真机跑通的代码。
首先是小程序支付功能的申请。在半年前我有另一个小程序项目，虽然当时没有开通小程序微信支付的需求，但是我留意过应用号（小程序号）后台微信支付的相关选项。当时，这个小程序因为绑定过已认证的服务号，因此小程序支付是可以直接申请的，无需任何费用。但是这次的项目，同样是另一个已经绑定过认证服务号的小程序，在微信支付界面，提示我要认证当前的小程序号才能开通微信支付，也就是说，绑定服务号还不够，必须把这个小程序号也交300元认证后，才给开通支付功能！真的很坑，好在客户没有什么怨言，非常配合地就把认证给办了…
一天后小程序号认证通过，就有了申请支付的入口：
果断选右边那个，根据给出的提示，到商户平台里面用小程序的appid绑定就行了。 查看详细
发现阿里云的云主机可以按最短一周时常购买了，以后做测试环境，花点小钱买台短期主机做测试的成本又降低了（虽然ECS总体还是涨价了）。这次想尝试一下在最新的CentOS下安装node.js会不会踩坑，于是开干。
在失败了多次，东拼西凑了很多文章和教程后，终于把nodejs（8.7.0）给装上了，下面整理所用命令行以及过程。 查看详细
记录一下几个简单的ES6的字符串和数值方法
字符串查找（当前版本Chrome已支持）
let a = "hello world!"; a.startsWith("hello"); //true a.endsWith("!"); //true a.includes("w"); //true //第二个参数表示搜索位置索引 a.startsWith("ello" , 1); //true a.endsWith("hello" , 5); //true a.includes("hello" , 5); //false |
最近粗略看了一下ES6的一些特性，如果运用成熟，写JS的感觉将比ES5要愉悦很多。随着微信小程序开发量的增加，自己也觉得是时候拿起ES6了。买了一本阮一峰的《ES6标准入门》，从第二章开始慢慢看了起来。在自己的博客上也整理一些笔记，记录学习轨迹。
let 和 const 命令声明的变量，有严格的块级作用域限制，当前{}内声明的变量，在当前{}外无法使用；同一作用域下在变量声明之前，也不能使用；否则都会报错。另外，不允许重复声明同一变量。
for(let i=0 ; i<3; i++){ let i="a"; console.log(i); //输出三次a；在()内声明的i和在{}内声明的i并不在同一作用域内 } console.log(i); //报错 |
几个月前踩过一个坑，在微信小程序页面上，用setData更新地图上的marker数据，地图并不会改变，而且这个问题当时只在真机上调试才会发生，之前在小程序开发工具中调试并没有发现，使我开发到很晚还要回过头来找问题，浪费了不少时间，当时也用一篇博客记录了这个问题 https://blog.brain1981.com/1696.html，用地图组件控制接口wx.createMapContext的translateMarker方法修改坐标，绕过了这个坑。
大半年过去了，似乎已经淡忘了这个问题，这几天那个小程序有个较大的继续开发需求，使我又回到了小程序开发中来。测试了一下之前的地图，发现translateMarker修改坐标在真机上居然也有小概率会失效。原因暂时不明。微信小程序在这半年里面已经更新过二十多个版本，自然也没办法去追述到底是更新导致了我的问题，还是当时就没写好… 不过时隔多日再回头看文档，发现还是有一些新东西可用的。
先想办法解决这个老问题，查了一下资料，原来map这种级别高的系统原生组件，是不会跟着页面数据的修改而重新渲染的。如果要更新map上的marker，势必要重新渲染map，那么就要强制渲染一下。最简单的方法是给map组件上添加一个if语法。通过绑定map的值（0或1），修改map组件的显示与否 查看详细
在WordPress中如果要更新某个自定义字段，只需要用到函数update_post_meta()就可以了。在执行update_post_meta的时候，WP会查找到你要更新的字段，如果没有符合条件的字段，WP会用add_post_meta添加新的字段，不用人工写判断，很方便。
使用add_post_meta添加新字段时，如果添加了参数$unique为true，WP会查找有没有相同键名（meta_key）的字段，如果有，则不会添加任何东西。
删除自定义字段delete_post_meter也不需要预先判断有无字段，如果没有该字段，delete_post_meter会返回false值。
相关文档：
https://codex.wordpress.org/Function_Reference/add_post_meta
https://codex.wordpress.org/Function_Reference/update_post_meta
https://codex.wordpress.org/Function_Reference/delete_post_meta
查看详细
经常摆弄各种WordPress插件的人，对admin-ajax.php 500报错应该是不陌生的。表症就是在Console栏里看到如下报错。
用Ajax提交数据的插件，出现这类报错曾经让我很容易抓狂，因为它不直接输出PHP代码错误位置，你无法从这种报错中看出到底是哪个插件，哪行代码出的问题。老手应该知道，500报错都是可以从PHP报错日志找线索的。
查看详细
做外包开发好多年，本着诚信待客的原则，我们都会在项目签订之前就和客户约定清楚有哪些售后服务，消灭隐形消费。建站这一行水也挺深的，经常听到有客户诉说自己在别家被坑的故事，尤其是在售后这一块。很多建站平台以极低的价格揽客，客户上钩后，稍微要定制一点东西就花费不菲，售后服务更是变着花样收钱。那么怎样能才算是项目合作双方正确的姿势呢？这里发一篇我在知乎上回答的问题。
原题： 网站售后服务包括那些？如果网站前台代码需要调整或者更改图片文字属于售后服务这块吗？
答： 首先，网站开发完毕后，一切后续工作都可以算是售后服务
但是网站在上线之后往往还会有大量工作要做，稍微有一点业务逻辑的网站，其上线后要做的工作可能都要比早期开发工作量都要多很多。而把网站外包的甲方往往没有这一点意识，觉得只要关于网站的一切，无论是代码修改，还是内容修改，乙方都应该永远负责下去，但只愿意付第一笔开发费用，或则很少的维护费用。很多乙方为了能拿到项目，在开工之前也是各种承诺售后，但真的碰到甲方无休止的修改需求后，因为觉得钱没给够，就撂挑子了。这个就是我所见到的行业乱象，非常普遍
正确的做法应该是双方在明确一切售后服务的可能性后，再签单开工。我会把所有售后可能提供的服务都列出来，比如：
基础的服务，服务器监控保证网站出问题后多小小时内能恢复、网站数据多久备份一次
网站内容修改，每周最多修改几次，总共不超过多少小时的工作量
SEO的配合，每周不超过多少小时工作量
网站新板块、新功能的开发需要商量后再重新签订二期、三期的开发合同
网站是否有可能要改版
等等…
售后服务是一个很难量化的东西，但有一个量化标准可以被普遍使用，那就是时间。售后服务的成本就是服务人员的时间，那么按照时间来商定价格是比较合理的。有些时候甲方认为很简单的修改，乙方可能要花很多时间去做，也有些乙方会忽悠甲方一个简单的修改花了很多时间。但还是要比“增加一个页面要多少钱”、“换一张图片要多少钱”这样的坐地起价合理有效多了。