分类: wp

  • Jetpack 的流量统计好像被墙了

    Jetpack 的流量统计好像被墙了

    从5月23日开始,从 WP 后台的 Jetpack 统计看起来,我的博客访问量大跌。

    一开始我以为是 CDN 的问题,拉着同事研究了半天,没有找到证据。然后检查了 DNS 解析统计,似乎也正常。最后想起来看 GA。从 GA 的数据来看,似乎访问量并没有什么变化。那么只好猜测是 Jetpack 的统计出问题,很多访问没有统计到。

    不过我觉得多半是误伤,毕竟 Jetpack 作为 WordPress 的产品,很容易被“误伤”,而且在国内也没多少人用,不必像 GA 这样还要留点余地。可惜以后我没法很容易的看到统计数据了。

  • 解决 load-scripts.php jQuery is not defined 的问题

    解决 load-scripts.php jQuery is not defined 的问题

    不知道从哪天起,我的博客后台就坏了。没错,就是这个后台。写文章变成非常困难的一件事。各种功能都不好使,页面布局也混乱不堪。于是我打开开发者工具,看到一大堆报错,基本上都是 load-scripts.php jQuery is not defined。看起来是某些 jQuery 插件启动的时候 jQuery 还没完成加载。

    这就有点蛋疼了。我应该没有手动调整过这些脚本的加载,但是也说不定,我好像有把本地的 jQuery 换成 CDN 上的版本,但也不是很确定。不过我有好几台电脑,有些电脑上保留着可用的 JS 的缓存,我就勉强用着,反正也不常写文章。我试着 Google 这个问题,但可能关键词组合没选好,没能找到答案。WordPress 历史太悠久,跟 jQuery 相关的问题不胜枚举,搜索结果里噪音太多。

    结果前两天终于所有缓存都失效了,然后我就没法写文章了,于是必须解决这个问题了。没想到这次我很快找到了解答:

    Try adding define('CONCATENATE_SCRIPTS', false); to your wp-config.php file just below the define('DB_HOST' line.

    https://wordpress.org/support/topic/failed-to-load-jquery-at-load-scripts-php/

    使用后台的时候,WordPress 会试图把所有 JS 合并到一起,以便节省 HTTP 请求。这个设计思路没问题,但看起来他们的实现比较简单粗暴,只是简单的合并,并没有很好的检查依赖顺序,以至于可能导致后台功能失败。

  • 开发 WordPress 的 nginx 配置

    开发 WordPress 的 nginx 配置

    以前比较习惯放在 /etc/nginx/ 里,用 service nginx start 启动(对应 MacOS + brew 就是 /usr/local/etc/nginx/brew services start nginx)。来到我厂后,开始频繁接触 Nginx 和 OpenResty,现在觉得单独放在目录下面比较方便管理,所以改了一个出来。

    配合 Makefile,方便日后使用:

    1. 启动服务 make run
    2. 关闭服务 make stop
    3. 重新加载 make reload
    4. 使用 php-fpm
    5. 代理上传资源(/wp-contents/uploads/)到真实服务器
    6. log 在本地
    nginx = nginx
    
    .PHONY: run
    run:
        mkdir -p logs
        $(nginx) -p $$PWD -c nginx.conf
    
    .PHONY: reload
    reload: logs/nginx.pid all
        $(nginx) -p $$PWD -c conf/nginx.conf -t
        kill -HUP `cat $<`
    
    .PHONY: reload
    stop: logs/nginx.pid
        $(nginx) -p $$PWD -c conf/nginx.conf -t
        kill -QUIT `cat $<`
    
    error_log logs/error.log error;
    pid logs/nginx.pid;
    
    events {
        accept_mutex off;
    }
    
    http {
    
        server {
            listen 9010;
            listen [::]:9010;
    
            include /usr/local/etc/nginx/mime.types;
    
            root /Users/meathill/Sites/wp-dev;
    
            index index.php index.html index.htm index.nginx-debian.html;
    
            server_name wp-dev.com;
    
            location / {
                try_files $uri $uri/ /index.php?$args;
            }
    
            location /wp-content/uploads/ {
                proxy_pass https://blog.meathill.com/wp-content/uploads/;
                proxy_set_header Host blog.meathill.com;
                proxy_ssl_name "blog.meathill.com";
                proxy_ssl_server_name on;
            }
    
            location ~ \.php$ {
                include /usr/local/etc/nginx/fastcgi.conf;
    
                fastcgi_pass 127.0.0.1:9999;
            }
        }
    }
    
    

    代码放在 Github wp-dev-env

  • WordPress + MySQL 8

    如果遇到验证数据库链接失败的问题,可以这样:

    ALTER USER 'username'@'localhost' identified with mysql_native_password by 'password';
    
  • WP Super Cache 的 max-age 有问题

    WP Super Cache 的 max-age 有问题

    我厂做的是高性能网关,CDN 也是其中一大功能,所以就要吃自己的狗粮。之前多次尝试在七牛上配置全站 CDN,均以失败告终,这次因为是自家的产品,可以找同事咨询,所以打算再试一次。

    配置过程暂且不提,基本上很顺利。结果在缓存上遇到一些麻烦,源站(也就是我的博客)控制为:max-age=3,所以基本上完全失效。

    由于这个东西很多地方都可以控制,所以只好逐一排查。首先打开 WP Super Cache 的配置——它负责缓存,所以从它找起——无果;然后 Google “wordpress cache-control”,无结果;然后 Google “max-age=3”,发现这个地址:Cache-Control max-age=3, must-revalidate,原来缓存 max-age=3 竟然是插件的问题,而且一直保留至今。

    按图索骥,打开 /wp-content/plugins/wp-super-cache/wp-cache-phase1.php,没有找到,原来这段已经被挪到 wp-cache-phase2.php,而且亦然没改……修改为 86400,缓存就可以 HIT 了。

    至于这个地方是不是 Bug?我觉得是。这么短的时间不科学,如果真的这样,不如放出来给用户选择。

  • WordPress插件:WPtouch

    使用WordPress的一大乐趣就是试用各种插件。因为开源的关系,所有开发者都可以写自己的插件,一方面选择的范围很宽,另一方面插件的质量也良莠不齐,能找到一个既满足需求又设计精良方便实用的插件很不容易——尤其是,如果想找中文插件就更困难了。

    (更多…)

  • WordPress使用/修改笔记

    WordPress使用/修改笔记

    也是一边记录一边整理吧。

    (更多…)

  • 折腾wordpress,先把样式和操作都改成我希望的,然后把越南游的照片和日志整理好,最后邀请大家来看~~