经常摆弄各种WordPress插件的人,对admin-ajax.php 500报错应该是不陌生的。表症就是在Console栏里看到如下报错。
用Ajax提交数据的插件,出现这类报错曾经让我很容易抓狂,因为它不直接输出PHP代码错误位置,你无法从这种报错中看出到底是哪个插件,哪行代码出的问题。老手应该知道,500报错都是可以从PHP报错日志找线索的。
查看详细
经常摆弄各种WordPress插件的人,对admin-ajax.php 500报错应该是不陌生的。表症就是在Console栏里看到如下报错。
用Ajax提交数据的插件,出现这类报错曾经让我很容易抓狂,因为它不直接输出PHP代码错误位置,你无法从这种报错中看出到底是哪个插件,哪行代码出的问题。老手应该知道,500报错都是可以从PHP报错日志找线索的。
查看详细
今天在开发小程序的过程中发现一个旧的项目在加载了几十条文章数据后,就再也无法继续加载了,微信开发工具中报错“invokeWebviewMethod 数据传输长度为 1957855 已经超过最大长度 1048576”
这是由于微信小程序规定页面的data对象最大只能装载1M的数据,而我的数据源都是很长的文章,在加载了50篇左右就超过1M了。显然用WordPress默认的REST API格式是无法突破这个瓶颈了。于是就要想办法修改API,在要加载大量文章的列表页中,把文章正文内容去掉,就能减少90%的数据量,反正列表页也不需要显示正文;只在文章详细页上加载当前文章的所有数据。
首先是去掉默认API的文章详细内容,并且删除掉一些觉得没用的字段: 查看详细
众所周知我是靠建站吃饭的,SEO并非我的主业,甚至连支线业务都算不上。因为从我手上建成的网站,我都会在代码层做到尽可能的优化,并且通过Yoast SEO插件最大程度的发挥WordPress在SEO方面的技术优势。做到了这些,接下来只要好好写内容就好了。
本博客建立五年,虽然访问量不大,但也算络绎不绝,一直有陌生访客约我建站,从中也认识了不少优质客户,并展开长期合作。这当中,有一部分的功劳属于WordPress得天独厚的SEO基因。当然,这里要自吹一番,WP再强大,用得不好的仍然是大部分人,做出的网站能否发挥SEO功效,还是要取决于使用者。因为相信WP和自己作品的质量,我认为从自己手上做出来的网站,够好了,已没有太大的SEO空间,所以一直不主动接SEO业务。
只有少数预算充足的客户希望从我这里能再榨取一些潜力,会付费让我在我开发的网站上做更多的SEO工作。当然这些工作并不包括常规的优化工作,什么sitemap、TDK、网站提速之类的基础工作在建站的时候肯定都已经做了,不好意思另外再收人家钱。
我后续的收费SEO工作其实大部分是苦逼的劳力付出,比如拼命挖掘客户的微信公众号、博客以及其他我能找得到的资料,在网站上另辟区域重组这些内容,从而增加页面数量、增加长尾词的可能性、增加站内相关页面的互链。定期再去从访客统计记录里找到新冒出来的词,哪怕可能只有两三个访问量,我都会在内容中多加提点。所以SEO的这部分工作,等于把我变成了半个编辑。技术上如果要再多挖一些,或许只有黑帽了吧,不过这些我是不碰的。 查看详细
这应该是一个比较常见的功能需求了,虚拟物品由于不需要进行送货,用户付款后即可算作订单完成,以便网站统计订单后进行更多操作,用户也可能籍此获得一些其他的优惠或者权益。这一切都需要前一个订单在没有人工干预的状态下自动完成。
首先,官方文档中给出了直接完成订单的代码:
1 2 3 4 5 6 7 8 | add_action( 'woocommerce_thankyou', 'custom_woocommerce_auto_complete_order'); function custom_woocommerce_auto_complete_order( $order_id ) { if ( ! $order_id ) { return; } $order = wc_get_order( $order_id ); $order->update_status( 'completed' ); } |
接到一个需求,要把公司的一个酒店行业的WordPress网站里的几百家酒店数据导出为CSV文件,以便其他开发人员把它转成需要的格式开发APP。觉得这是一个比较笨的需求,WP是一套十分便捷的CMS,用WP后台管理这些酒店数据很容易,但对方是要拿静态的CSV文件,转格式后,就要导入另一套不如WP好用的后台。同一套数据两边分别管理,实在是浪费人力。我们为什么不能直接通过WordPress后台同时管理网站和APP数据呢?
由这个切入点,让我想起了WP REST API,从最近发布的WP的4.7版开始,已经官方支持REST API,不需要安装任何插件了。这也是现在的技术趋势,使得WordPress不再局限于PHP语言,能够导出JSON数据被任何其他开发语言和平台所使用。
REST API的基本概念就是直接把网站数据通过类似
http://yourdomain.com/wp-json/wp/v2/posts/
http://yourdomain.com/wp-json/wp/v2/pages/
这样的URL转成JSON
这个URL可以再定义得细一些,比如 查看详细
接上一篇 定制WooCommerce的账户详情(用户资料)页,增加自定义字段,修改默认字段 后,本文记录一下如何修改WooCommerce用户中心的edit-address以及购买商品结帐页面的字段。所有修改还是为了符合国内用户的书写习惯,把姓名合并成一个字段,去掉email字段,把地址栏从2行变成1行。
修改之前是这样的:
首先是去掉lastname、city和address_2这些没必要的字段 查看详细
WooCommerce是一款非常流行的WordPress电商插件。然而也听到很多人反映,它并太符合中国用户的使用习惯。国内用户的电商网站使用习惯大多是被淘宝培养出来的,因此如果要基于WordPress + WooCommerce搭建一个面向国人的小型电商网站,为提高用户体验,还是要对WooCommerce做不少改造的。在做过N个相关项目后,我觉得有必要分几篇文章,把WooCommerce值得改造的点和改造过程总结一下。我的原则还是能不用插件就不用插件,几十行代码能搞定的事情,肯定不会考虑用插件。本文先说说如何自定义账户中心的用户资料页。
首先,默认的WC用户资料页大致是这样的:
查看详细
这个问题在最近的一个项目中反复出现,页面显示截图如下:
由于报错并没有提示是哪个文件哪行代码出问题,所以起初我只能通过一个个关闭插件来排查问题。首先,在这个网站上我用了WP Super Cache插件,关闭它后,报错变得时有时无;同时这个网站上我用了WPML、BuddyPress等大体量的插件,发现关闭其中任何一个,这个报错就不会出现。那么似乎问题就出在这些插件互相间的兼容问题上。然而这几个插件目前来说都是难以被替代的,如果禁用会导致开发成本大大增加,郁闷之余,把项目先放在一边,先陪儿子们玩去了… 查看详细
给WordPress文章添加点赞功能,其基本思路就是给每篇文章添加一个自定义字段,用这个自定义字段存储赞数;在客户端用Cookie存储是否已经点赞的变量。给BuddyPress的帖子添加点赞功能,思路也是一样的,但BP的帖子和自定义字段在数据库中并不保存在WP原来的表中,要读取/操作它们就要用BP自己的API。给BuddyPress添加的点赞功能,效果如图:
查看详细