Timber框架中全局上下文菜单项current属性失效问题解析

问题现象

在使用Timber框架时，开发者可能会遇到一个典型问题：当通过timber/context过滤器将菜单添加到全局上下文后，菜单项的current、current_item_parent和current_item_ancestor属性始终返回false值。这种现象会导致前端无法正确识别当前活动菜单项，影响导航高亮等功能的实现。

技术背景

Timber框架通过Timber::get_menu()方法获取菜单时，内部会调用WordPress核心函数_wp_menu_item_classes_by_context()来设置菜单项的状态属性。这个函数依赖于全局变量$wp_query来确定当前页面上下文。

根本原因

问题产生的核心时机在于：

1. 当在timber/context过滤器中初始化菜单时（通常发生在init或after_setup_theme阶段）
2. 此时WordPress的全局查询对象$wp_query尚未完全初始化
3. 导致状态判断函数无法获取正确的页面上下文信息

解决方案

推荐方案：延迟菜单初始化

将菜单初始化逻辑移至wp动作钩子之后，此时全局查询对象已准备就绪：

add_action('wp', function() {
    add_filter('timber/context', function ($context) {
        $context['menu'] = Timber::get_menu('primary-menu');
        return $context;
    });
});

替代方案：模板级初始化

在具体模板文件中获取菜单（确保在渲染前执行）：

// single.php
$context = Timber::context();
$context['menu'] = Timber::get_menu('primary-menu');
Timber::render('template.twig', $context);

最佳实践建议

1. 避免在过早的钩子（如init）中调用Timber::context()
2. 对于必须在早期初始化的功能，考虑使用回调方式延迟菜单加载
3. 保持上下文初始化的统一性，建议集中在wp或template_redirect阶段处理

经验总结

这个案例揭示了WordPress生命周期与Timber上下文初始化时机的重要性。开发者需要注意：

• 全局查询对象的可用时机
• 不同阶段可访问的API差异
• 上下文数据的延迟加载策略

通过合理规划初始化时机，可以确保框架功能按预期工作，同时保持代码的可维护性。