分类
服务器端

解决 Raspberry Pi 4 安装 php-mbstring/php-curl 的问题

最近要在 flarum 上做二次开发,尝试直接用 php -S localhost:8080 未果,于是打算在树莓派上搭个开发环境,省得它整日落灰。

因为在本地创建过仓库,所以这次直接从 GitHub clone 项目下来,然后打算执行 composer install 安装依赖。结果提示差了 php-mbstring(解决汉字等多字节字符)和 php-curl(用于远程请求)两个模块。然后我就打算用 apt install php-curl 安装模块,没想到失败了,仔细看错误信息,因为这个模块依赖 libcurl3,但是系统里是 libcurl4,所以不行。

那就安装 libcurl3 呗,结果系统认为明显 libcurl4 更新,不给装 3,哪怕删了重装都不行。

后来查了半天,找到答案。原来我添加的源是 stretch 的,也就是面向 Debian 9 的;而 Raspberry Pi 的系统是基于 Debian 10,也就是 buster 的,所以依赖处理上,两方面就冲突了。

这个时候,需要用 sh -c 'echo "deb https://packages.sury.org/php/ buster main" > /etc/apt/sources.list.d/php.list' 把属于“buster”的源添加进系统,接着删掉之前 stretch 的源,然后 apt update 之后,就可以正常安装了。


参考链接:https://github.com/oerdnj/deb.sury.org/issues/1193

分类
php

PHP built-in web server 支持自动查找入口

使用 php -s localhost:8080 可以快速启动一个开发服务器,非常方便,是我现在需要简单服务器支持时的首选。

不过我最初了解到这个功能的时候,它(可能)还不支持请求重写,也就是说,我们访问 /foo/bar,它就会去当前目录里查找 /foo/bar,找不到就 404。如果想要实现 index.php 重定向,必须手动编写路由文件,比较麻烦。我宁可用 nginx 实现,因为部署上线的时候早晚要用。

最近偶然发现,PHP built-in web server 已经支持请求重写了,如果命中,就会直接返回目标文件;如果没有命中,就会沿着目录往上找,直到找到 index.php 或者 index.html,或者到启动服务器的根目录,然后把请求地址放在 $_SERVER['PATH_INFO'] 里,留待 php 处理。

这样一来,无论是 WordPress,还是 Laravel,还是其它基于路由的单一入口项目,都可以直接使用 PHP built-in web server 开发了,简单方便快捷。甚至连纯前端项目,如果你不熟悉服务器端的配置,也可以简单的安装一个 PHP 来实现。

比如,在本地开发 WordPress,可以这样:

# 安装 php 和 mysql
brew install php
brew install mysql

# 配置 mysql root 用户密码,替换下面的 `NEWPASS` 
$(brew --prefix mysql)/bin/mysqladmin -u root password NEWPASS

# 下载并解压 wordpress.zip,进入目录,启动服务器
php -s localhost:8080

# 完成!

参考文档:

PHP manual: Built-in web server

分类
php

解决 composer global install 失败的问题

今天突发奇想,打算写会儿 PHP,按照 Laravel 文档,准备先安装 laravel/installer,结果 composer global require laravel/install 安装失败,提示错误信息:

Your requirements could not be resolved to an installable set of packages.

出问题的包是 symfony/console,需要的版本和已安装版本不一致,安装新版本失败。简单搜了一下,答案比较多,有说版本问题,有说权限问题,有说 PHP 模块问题。

我看了一眼权限,应该没问题。然后 composer help 看了看命令参数,发现有一个命令,可以查看所有已安装,现在版本有些旧了,可以升级的包:composer global outdated。执行之,发现以前安装过 laravel/installer 1.x,自然也安装了 1.x 需要的 symfony/console 作为依赖。那么,多半是这个旧版本阻止了新版本的安装,导致新版 laravel/installer 安装失败。

于是 composer global remove laravel/installer 先删除就版本,然后安装新版本,就 OK 了。

然后,折腾了半天,我又不想写 PHP 了……

分类
服务器端

解决 PHP 7.2.8 + MySQL 8.0.12 连接失败的问题

这两天又反复遇到这个问题,先写解决方案:

1. 使用 caching_sha2_password  插件

修改用户密码,并且用插件生成,可以解决 WordPress 的问题。

ALTER USER 'user'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'password';

2. 修改 my.cnf,使用原生密码

使用 Laravel + MySQL 8.0 的时候,遇到

SQLSTATE[HY000] [2054] The server requested authentication method unknown to the client

修改 /etc/mysql/my.cnf (我是 Ubuntu 16.04),添加下面一行:

[mysqld]
default_authentication_plugin= mysql_native_password

然后重置密码:

ALTER USER 'user'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';
分类
服务器端

Failed to start php-fpm.service: Unit php-fpm.service is masked.

周末手一抖把服务器从 17.10 升级到了 18.04,然后博客就挂掉了。

根据提示信息,nginx 应该正常工作,问题多半出在 PHP 上。service --status-all 之后,果然 php7.1-fpm 没有启动。然后照常 service php7.1-fpm start,咦,奇怪,报错了:

Failed to start php7.1-fpm.service: Unit php7.1-fpm.service is masked.

换用 service php-fpm start 也一样,区别就是 service 名字不太一样。然后 Google 之,没找到很靠谱的说法,但是找到一个类似的情况,发生于使用 do-release-upgrade 升级到 16.04 时,php5-fpm 启动不了,报类似的错误,解决方案是升级到 php7。

如此一来我也试试好了,因为直接 apt install php-fpm 会解析出来 php7.2,所以我尝试 service php7.2-fpm start,果然可以。既然如此,干脆升级到 7.2 好了,反正我也没啥特殊要求。

于是修改站点配置文件,把 php 接口指向 7.2 的 socket,然后安装几个欠缺的模块,终于又把博客跑起来了。

分类
php

MySQL 的编码问题

前几天朋友的小程序遇到点问题,同样的代码,有些人就是注册不上,有些人就没问题。让我帮忙看。

看代码应该没问题,我自己试也没问题,很诡异。后来我发现,说注册不上的一个截图里,昵称里有一个雨滴的符号。我们知道,传统的编码是没有表情符号的,表情符号是 Unicode 后期才加进去的,那么会不会是数据库字段的问题?看了一眼,Laravel 默认创建的数据库,字符类型是 utf8mb4_unicode_ci,而他们数据库是 utf8_general_ci,Google 一下,找到下面这篇文章:

為什麼MYSQL要設定用UTF8MB4編碼 UTF8MB4_UNICODE_CI

里面提到:

當資料庫需要儲存或處理以下資料:emoji (手機端常用的表情字符)

应该使用 utf8mb4_unicode_ci,因为它会用更多的空间存储字符。基本锁定是字符集的问题。然后看到梦康大的一篇博文:直接使用 mysql utf8 存储 超过三个字节的 emoji 表情 ( 不使用 utf8mb4 ),决定参考他的方案,毕竟改库改表不是小事情。

不过时过境迁,梦康文中的 func_overload 已经可以用 mb_strlen($str, '8bit') 来替代,所以最后的代码大约是这样的:

// 替换
protected function encodeEmoji($input) {
  $length = mb_strlen($input, 'utf-8');
  $result = '';

  for ($i = 0; $i < $length; $i++) {
    $tmp = mb_substr($input, $i, 1, 'utf-8');
    if (mb_strlen($tmp, '8bit') >= 4) {
      $result .= '[[Emoji:' . rawurlencode($tmp) . ']]';
    } else {
      $result .= $tmp;
    }
  }
  return $result;
}

// 替换回
protected function decodeEmoji($nickname) {
  return preg_replace_callback('~\[\[Emoji:(.*?)\]\]~', function ($matches) {
    return rawurldecode($matches[1]);
  }, $nickname);
}

所以说,程序员心态要保持年轻,步调要跟年轻人保持一致,这样才更容易发现新问题,所以我的昵称已经改成“肉山🎩”了。

分类
php

Laravel 开发笔记

记录 Laravel 开发中的一些心得体会,踩过的坑。

分类
技术

诡异的 Mac + PHP + Nginx 问题

问题描述

这次是微信公众号开发,本身就有很多问题,也严重加剧了我调试的难度。正在做一个 WordPress 插件,功能是将公众号文章和 WordPress 互相同步。之前一切正常,突然有用户反馈抓不到公众号上的文章了。

顺便说下,插件地址:https://github.com/meathill/wp-plugin-weixin 目前支支持手动部署,完成二维码之后开始做发布版。

分类
服务器端

Ubuntu 16.04 搭建 LNMP 开发环境

前天帮人配了台机器,未来可能还要帮人配。在学会用 Docker 之前,先写一篇记录下怎么搭建环境吧。

这篇收费!¥4.99,请阅后自觉打钱。

分类
php

使用 Satis 搭建私有仓库

题外话

开始正题之前聊一些题外话。PHP 是个很好的语言,简洁高效,易学强大。但是出身不好,工程学上的高起点反而成为大家轻视它的原因。很多开发者也的确对自己要求不高,只写业务逻辑不考虑语言特性,使得代码难看难改难维护。所以我想多说两句回顾一下 PHP 本身的发展史。(以下以我个人经历为主)

上古时期

我们一个页面写一段 PHP,或者一个动作写一个 PHP,收集请求,做出处理,给出回应,完成。

好处:

  1. 简单,好上手
  2. 逻辑关系清晰,从前端可以直接找到目标程序
  3. 一个地方出错,多半只挂一个功能

坏处:

  1. 代码复用率低,不好维护
  2. 难以批量修改

古典社会

随着工程变大,需要大量的 PHP,分散碎片化的代码实在难以管理和维护。于是我们开始把一些共用代码抽出来,做成一个函数,叫 functions.php,其他所有页面都 include 它,这样公用的代码就不会这里一份那里一份了。

好处:

  1. 提高了代码复用性,减少开发量,提升效率,降低维护难度

坏处:

  1. 工程大的话,一个 functions.php 好几千行,可读性也没好到哪儿去
  2. 有时候我们需要对一个函数进行一些小修改,于是不仅函数库会膨胀,函数本身也在膨胀

中世纪

PHP 引入类的概念,并且提供了“魔术方法”来实现一些功能。有些程序员也意识到不能所有代码都自己手写,该引用的还得引用,于是从一些开源的库拷来代码开始用。这个时候连 Google Code 都不存在,下载代码多半在网上搜索 + Ctrl C/V,所以代码中各种混用。经常出现,我 include 一个文件,然后就挂了,原来是类被重复定义,或者全局环境下同名函数互相覆盖。开发乱象不断,形如黑暗的中世纪。

好处:

  1. 不考虑维护的话,开发速度还是可以的……

坏处:

  1. 越到后来坑越多,项目一大积重难返
  2. 内部执行环境不统一,a.php b.php 的内部环境都不一致,共享代码反而更加困难

文艺复兴

PHP 对类的支持已经十分完善了,大家也开始习惯用命名空间划分领域。通过使用设计模式、继承、接口,复写功能和代码管理的情况大大改善。同时,伴随 Google Code 和 GitHub 的出现和发展,大家有了一个托管代码和寻找代码的好地方。我们也开始用 SVN 管理代码,不会再搞出 action.php action.php.bak action_new.php action_new.20160102.php 这样的幺蛾子。开始学习开发规范,开始更多的的用类管理代码。

好处:

  1. 代码规范
  2. 版本管理后,更好追溯代码的变更记录
  3. 可以下载到新版本的代码

坏处:

  1. SVN 不方便进行多仓库的管理
  2. 测试还靠人工发掘问题

近代社会

Git 开始普及,我们可以更方便的管理代码了。GitHub 发展速度很快,从上面找好代码也很容易,凭借 Git 子仓库的概念,维护依赖也容易很多。MVC 框架开始普及,单入口开始流行,内部执行环境得到统一。开发者意识到测试的重要性,开始使用测试工具进行测试开发,代码的稳定性进一步提升。

好处:

  1. 内部执行环境统一,全局修改变得容易
  2. 开始写测试了

坏处:

  1. 学习成本开始增加,新入行的人开始搞不懂,为啥写一个脚本就能干的事,你们要搞这么复杂一套架构出来

现代社会

包管理工具成为标配。项目依赖不再通过复制代码或者子仓库来管理,而是直接使用包管理工具 Compposer。并且整合测试、部署脚本,方便我们更容易地完成整套开发流程。另一方面,前端之前已经崛起,PHP 可以更多的考虑后端业务逻辑,输出纯粹的数据接口。

好处:

  1. 大型项目稳定性可用性大大增加
  2. 专业分工加强,PHP 程序员可以更多考虑后端逻辑

坏处:

  1. 学习曲线更加陡峭,新人入行更难,甚至连有经验的老人都未必能适应新形态的开发。

然则历史的车轮不可阻挡,我们势必会走向学习成本更高、学习曲线更陡,但业务量更大、更稳定的未来。


正文开始

正如前面所说,现在我们更多使用 Composer 进行依赖管理。和其它语言的包管理工具一样,Composer 使用 GitHub 托管代码,可以根据配置文件管理依赖,也可以建立各种脚本,执行特定任务。总之好处很多。

实际工作中,我们可以把多个项目公用的逻辑抽出来,作为一个依赖,然后提交到 Packagist,就可以在其它项目中引用它了。但是,与 NPM 这种工具不同的是,PHP 程序多半会部署在服务器上,通过接口接受外部访问,对安全性的要求高很多。前端可以放开给大家随便观摩,后端最好还是放在别人轻易看不到的地方,万一哪个同事把密码、salt 写到代码里提交,被搜出来,结果可能就很危险。

此时我们就需要一个工具,能够搭建私有源,里面都是私有仓库,对内不对外。

Satis 就是 Composer 官方提供的建立私有源的工具。它的文档在这里 以及 这里

整体流程并不复杂,文档里都有,我简单复述一下,只包含我用过的部分,重点穿插我的经验。我假定读者已经了解 Composer 的基础使用,如有问题,请自行翻阅文档。

1. 建立项目

使用 Composer 自带的建项目功能,这个相当于 git clone + composer install + 运行 post-install 脚本。

composer create-project composer/satis my-satis --stability=dev --keep-vcs

2. 建立配置文件

/path/to/my-satis 目录下建立 satis.json 文件

{
  "name": "仓库名称",
  "homepage": "http://satis仓库地址",
  "repositories": [
    { "type": "vcs", "url": "https://github.com/mycompany/privaterepo" },
    { "type": "vcs", "url": "http://svn.example.org/private/repo" },
    { "type": "vcs", "url": "https://github.com/mycompany/privaterepo2" }
  ],
  "require-all": true
}

注意:仓库名称需要和仓库里 composer.jsonname 定义一致,和路径没什么关系,不然就会找不到。我当时被这个卡了好久……

因为加入私有源的仓库本身可能也有依赖,require-all 会把这些依赖的信息也抓进来。如果不需要的话,可以指定某个仓库,甚至某个版本:

{
  "name": "仓库名称",
  "homepage": "http://satis仓库地址/",
  "repositories": [
    { "type": "vcs", "url": "https://github.com/mycompany/privaterepo" },
    { "type": "vcs", "url": "http://svn.example.org/private/repo" },
    { "type": "vcs", "url": "https://github.com/mycompany/privaterepo2" }
  ],
  "require": {
    "company/package": "*",
    "company/package2": "*",
    "company/package3": "2.0.0"
  }
}

3. 生成仓库列表

执行

php bin/satis build satis.json ./web

就可以在 path/to/my-satis/web/ 里生成仓库列表了。

4. 在其它项目中使用私有源

只需要在项目的 composer.json 文件的根上添加

{
  "repositories": [
    {
      "type": "composer",
      "url": "http://satis仓库地址/"
    }
  ],
  "require": {
    "company/package": "1.2.0",
    "company/package2": "1.5.2",
    "company/package3": "dev-master"
  }
}

之后再通过 composer require 或者 composer install 想要的仓库就可以了。

注意:源里面只有“仓库列表”,并没有真的同步代码仓库过来,所以下载还要走托管代码的机器,比如 GitHub,内部 GitLab 等。所以需要确保相关的 ssh-key 已经添加,或者在配置文件中写上登录信息(不建议这么做)。

Tips: secure-http

satis 默认要求使用 https,不过 https 需要证书,不太好搞,比如前司运维就不愿意弄(当然,他们工作很忙,我十分理解)。此时我们可以设置 secure-httpfalse 强制 Composer 接受 http 的源。需要注意,secure-httpconfig 的属性之一,写在根上是没用的。

{
  "config": {
    "secure-http": false
  }
}

总结,Satis 私有源的搭建,对于使用 PHP 的开发团队来说是非常必要的。用 Composer 管理依赖效果也非常好,希望所有 PHP 开发者都好好学一学。我现在用的也比较浅,将来有心得继续补充。