Laravel模型需显式配置以复用WordPress表：设$table为wp_posts等真实表名，$primaryKey为'ID'，$keyType为'int'，禁用timestamps；避免隐式id条件和排序，用where('ID',123)->first()和orderBy('ID')；wp_options值需字符集一致并用maybe_unserialize解析；wp_users密码校验须用wp_check_password而非Laravel Hash。
WordPress数据库表结构怎么映射到Laravel模型
wordpress用的是前缀化、非标准命名的表结构（比如 wp_posts、wp_users），laravel默认约定是复数、下划线分隔、无前缀（如 posts）。直接用 php artisan make:model post -m 生成迁移，根本对不上。
实际做法不是“迁移表结构”，而是“复用现有表”——Laravel模型通过配置跳过迁移，直连 WordPress 表。关键在三处：
-
$table属性必须显式指定为wp_posts这类真实表名 -
$primaryKey得设成ID（WordPress主键大写，Laravel默认小写id） -
$keyType要设为'int'，因为ID是BIGINT UNSIGNED，Laravel 10+ 默认会报类型不匹配警告
示例模型片段：
class WpPost extends Model
{
protected $table = 'wp_posts';
protected $primaryKey = 'ID';
protected $keyType = 'int';
public $timestamps = false; // WordPress用 post_date/post_modified，不兼容 Laravel 的 created_at/updated_at
}
如何避免 Laravel Eloquent 自动加 `id` 条件或 `created_at` 排序
Laravel 在查询未指定排序时会悄悄加 ORDER BY id ASC；执行 find(123) 会生成 WHERE id = ? ——但 WordPress 表主键叫 ID，小写 id 字段根本不存在，查不到还静默失败。
这不是 bug，是约定冲突。必须主动关闭这些隐式行为：
- 禁用自动主键条件：用
where('ID', 123)->first()替代find(123) - 禁用默认排序：所有查询末尾加
->orderByRaw('1')或显式->orderBy('ID', 'desc') - 如果要用软删除，别碰
wp_posts.post_status字段——它不是布尔值，不能直接套SoftDeletestrait
否则你会看到空结果，或者日志里出现 Column not found: 1054 Unknown column 'id' in 'where clause' 这类错误。
生产级WordPress REST API集成，用于管理文章、页面、媒体、WooCommerce产品、Elementor内容、SEO元数据、ACF及JetEngine字段
wp_options 表读取时中文乱码或序列化数据解析失败
wp_options 里大量值是 PHP serialize() 后存的字符串，比如主题设置、插件配置。Laravel 直接 $option->option_value 拿到的是原始字符串，不是数组。
更麻烦的是：WordPress 默认用 utf8mb4 存，但部分老站点建库时没设对 collation，Laravel 读出来可能是乱码或 unserialize() 失败。
- 先确认数据库连接的
charset和collation配置和 WordPress 一致（通常是utf8mb4/utf8mb4_unicode_ci） - 不要手动
unserialize()——用maybe_unserialize()兼容函数（WordPress 提供，可复制进辅助函数） - 敏感字段如
siteurl、home建议单独缓存，避免每次查wp_options表
常见错误现象：unserialize(): Error at offset 0 of 123 bytes，基本就是字符集不匹配或字段被意外截断（option_value 字段类型是 longtext，但有些导出 SQL 没带长度声明）。
Laravel 连接 WordPress 数据库后，wp_users 密码没法直接校验
WordPress 用的是 wp_hash_password()（基于 phpass 的哈希），和 Laravel 的 Hash::check() 不兼容。直接拿 $request->password 去比 $user->user_pass 一定失败。
- 别重写密码逻辑——用
wp_check_password()函数（可从 WordPress 源码提取，它只依赖phpass类，不依赖 WP 环境） - 如果你只是读用户数据（比如同步昵称、邮箱），没问题；但凡涉及登录态，就必须走这套验证链
- 注意
wp_users.user_login是用户名，user_nicename是 URL 友好别名，别混淆用错字段
最容易被忽略的一点：WordPress 的 user_pass 字段长度是 VARCHAR(255)，而 Laravel users.password 默认是 VARCHAR(100) ——如果后期想把用户导入 Laravel 原生表，得先扩字段，否则截断哈希值导致永远无法登录。
