k1sul1/k1kit

维护者

详细信息

github.com/k1sul1/k1kit

源代码

问题

安装: 22

依赖: 0

建议者: 0

安全: 0

星级: 4

关注者: 1

分支: 0

开放问题: 7

类型:wordpress-plugin


README

下一个Jetpack,但更少癌症。作为WordPress开发的工具包使用。"设计"用于REST API驱动的站点,但在传统WordPress开发中也很有用。

新功能可能会被添加,但使用它们是否由您决定。

由于此插件处于早期开发阶段,向后兼容性可能会在任意时刻中断。达到1.0后,插件将遵循语义化版本控制,重大更改将始终伴随着主版本号的增加:1.2.3 => 2.0.0

功能

  • 自定义Gutenberg块支持
  • 使用Polylang支持多语言
    • 每个语言的ACF选项页面
    • 如果Polylang不可用,则回退到核心i18n函数
  • 可重用且可组合的数据驱动模板
    • 由于目前PHP不支持JSX,它们可能看起来有些丑陋
    • 如果您不喜欢这种风格,插入Twig或其他解决方案应该是可能的
    • 示例模板可在k1sul1/wordpress-theme-base获取
  • URL解析器
    • 维护wp_posts中每个资源的索引(可筛选)
    • 可以通过URL从REST API请求资源。对于遵循WordPress永久链接结构的单页应用程序很有用。
  • 瞬态重写
    • 假设Redis可用
    • 瞬态列表及其管理UI
    • 完整使用依赖于Redis!
  • 用于REST路由生成的紧凑API
    • 自动缓存

*:WIP,您可能希望在生产中隐藏此功能。

安装

与其他插件类似安装,将插件文件夹放入wp-content/plugins,或者如果您更复杂

composer require k1sul1/k1kit

快速入门

安装插件。您也可以激活它,但这不是必需的,如果您确保此插件已加载,您可能想这样做。

require_once WP_PLUGIN_DIR . '/k1kit/src/php/init.php';

这样做也确保了插件始终处于激活状态。

我建议您创建一个新的函数,您可以使用它来访问App类。您会经常使用它。

/**
 * $options is doesn't do anything on subsequent runs
 */
function app($options = []) {
  return \k1\App::init($options);
}

App类是一个单例(要么就是全局变量),因此您可以多次调用app(),"昂贵"的部分只执行一次。这也意味着第一次调用的位置很重要,所以我建议您在functions.php或您的插件早期这样做。

有几个选项供您选择

$options = [
  'blocks' => [],
  'templates' => [],
  'languageSlugs' => ['en'],
  'generateOptionsPages' => true,
  'manifests' => [
    'client' => __DIR__ . '/dist/client-manifest.json',
    'admin' => __DIR__ . '/dist/admin-manifest.json'
  ],
]

$options['blocks']应包含包含块的文件的路径数组。留空以“禁用”块功能。$options['templates']应包含包含模板的文件的路径数组。留空将不加载任何模板。$options['languageSlugs']应包含网站将使用的语言slugs数组。$options['generateOptionsPages']确定是否为您创建ACF选项页面。$options['manifests']应包含到manifest文件的路径的键值数组。设置为false以禁用manifest功能。

请参阅https://github.com/k1sul1/wordpress-theme-base/blob/master/functions.php,了解如何在构建资源清单的主题中正确操作。

App类本身不包含许多公共方法。

$app = app();

$app->getOption('key'); // Get value from an ACF options field, using the current language unless other specified
$app->getBlock('Hero'); // Get a custom block instance. Useful if you want to render a block manually.

一些功能被拆分为“子类”:AssetManifest和i18n。它们会为您实例化并放置在合适的位置。它们中的任何公共方法都是可用的。

$app = app();

$app->i18n->getText('Something that should be translated');
$app->i18n->getLanguage();
$app->i18n->getLanguages();

// A different AssetManifest instance if created for each manifest
$app->manifests['client']->enqueue('client.js');
$app->manifests['client']->getAssetFilename('something.svg', false) // Set second parameter to false to return a filesystem path instead of an URL

就这样吗?

有点像。在src/php/lib下还有许多有用的辅助文件。我个人的最爱是k1\params、k1\withTransient、k1\dotty、k1\Media\svg和k1\Media\image。svg依赖于客户端清单中存在的svg。建议您浏览这些文件,看看是否有您喜欢的。

但等等,还有更多!

幕后还有一些类:Block、Resolver、RestRoute、TransientList和Transientify。

Block用作ACF块的基础类。class SomeBlock extends \k1\Block Resolver创建一个新的数据库表,并在其中构建一个用于快速url_to_postid等价的永久链接索引。您可以使用过滤器配置要索引的内容。RestRoute用作构建REST API路由和端点的基类。轻量级的抽象提供了缓存功能和一个紧凑的API。TransientList是你可能会看到的最复杂的东西。如果存在合适的对象缓存(Redis),则Transientify创建的transient引用将保存在列表中,并作为transient存储。它的目的是允许精细的缓存控制,但您仍然需要知道自己在做什么。讽刺的是,如果您遇到性能问题,这可能是原因。不太可能,但仍然有可能。Transientify是一个用于*_transient函数的高级API。它的早期版本帮助芬兰最大的技术杂志之一保持运营。一开始可能会有些令人畏惧,如果您迷路了,看看它在哪里被使用。\k1\withTransient可能是您的朋友。

还有更多!

一些功能公开了REST API端点:(请注意,此列表可能已过时,最好检查src/php/api

  • k1/v1/transientlist
  • k1/v1/transientlist/delete
  • k1/v1/resolver/url
  • k1/v1/resolver/index
  • k1/v1/resolver/index/build
  • k1/v1/resolver/index/continue

Resolver已绑定到类Kit,如果您需要访问Resolver的PHP API,您可以使用\k1\kit()->resolverTransientList没有绑定到任何地方,但也没有在任何地方初始化,它只是一个静态类。如果您想尝试管理transients,只需直接访问它:\k1\TransientList::read()\k1\TransientList::delete()

仅此仓库可能有些原始,请确保查看k1sul1/wordpress-theme-base,了解我如何在客户端项目中使用它,以及k1sul1/kisu.li,了解我的个人作品集。(WIP,尚未公开)

警告

Resolver

默认情况下启用了解析器。您可以使用add_filter('k1kit/use-resolver', '__return_false')将其关闭。如果您不使用它,您应该将其关闭。

当您激活插件时,它将构建解析器索引。索引将包含所有标记为公开的帖子类型,但您可以使用过滤器更改此设置。随着您添加、修改或删除帖子,索引将自动更新。

如果您更改网站域名wp search-replace),索引将损坏,因为索引表索引是URL的sha1散列。您可以通过在管理后台重建索引来轻松修复此问题。旧索引将保持功能直到新版本生成。

数据库表非常轻量。

MariaDB [wordpress]> DESCRIBE wp_k1_resolver;
+---------------+---------------+------+-----+---------+-------+
| Field         | Type          | Null | Key | Default | Extra |
+---------------+---------------+------+-----+---------+-------+
| object_id     | bigint(20)    | NO   | PRI | NULL    |       |
| permalink     | varchar(2048) | NO   |     | NULL    |       |
| permalink_sha | char(40)      | NO   | UNI | NULL    |       |
+---------------+---------------+------+-----+---------+-------+
3 rows in set (0.002 sec)

transient

要彻底改造瞬态,就必须改造背后的软件。你可以使用WP DB作为瞬态存储,但不应该这样做。

如果不存在object-cache.php,则数据压缩将被关闭,并且不会存在瞬态列表。

这已经在Redis上进行了测试,使用了最流行的插件:[WP Redis](https://wordpresstheme.cn/plugins/wp-redis/) 和 [Redis Object Cache](https://wordpresstheme.cn/plugins/redis-cache/)。

只要WP使用实际的键值存储来处理set_transient和get_transient,这个插件应该可以正常运行。

Memcached

Memcached适用于小型网站,但它有一个硬编码的最大值大小为1MB,这导致如果瞬态列表超过这个大小,就无法将其存储在memcached中。超过这个大小后,它将失败。

#GOTTAGOFAST

如果去除对象缓存的抽象,瞬态可能会更快。这意味着放弃WordPress的*_transient函数,并使用类似Predis的东西,但加载WordPress的成本使得这样做几乎毫无意义,并且这个插件将不再是对象缓存无关的。

生成的键可能是可预测的,因此可以存储类似REST API响应的内容,并直接从对象缓存中为用户提供服务,只有在瞬态不存在时才加载WordPress,但这超出了这个项目的范围。