这个问题很笼统，我已经发布了一个版本 here .不过，我希望通过在此论坛中提问，我将有更好的机会获得回应，并对更多人有用。
当所有内容都加载到 drupal 页面上时，将内容关联在一起是一件棘手的事情。在 drupal 中，每个页面，无论是哪个站点，都基本相同:中间有主要内容(一个 View 、一个节点或多个节点)，围绕该中心内容的 block 。为了使 block 以某种方式了解中间的内容(更不用说彼此了解)，您要么必须在自己的自定义模块中做一些非常花哨的步法，要么必须在 URL 中提供“参数”。
我一直在研究spaces/context/features/purl developmentseed 提供的模块套件，我还研究了 Panels/Ctools Earl Miles(写 View 的人)制作的模块。虽然两者都提供了使我的工作更轻松的工具，但我对每一个的理解是，如果我想要由我的“上下文”定义的 block 的内容，我仍然需要在 URL 中放置“参数”(我通常使用它)意义，而不是上下文模块或 Ctools 中的上下文概念所指的特定意义)。
我错过了什么，还是我们在 Drupal 的地方？
最后，我应该说，我知道其他模块可以在有限的情况下帮助解决此类问题。 Views attach模块和 Node reference views例如，每个模块都针对一个非常具体的用例尝试解决这个问题。它们都是很好的模块，还有其他类似的模块，但我真的很想找到解决这个问题的方法。
最佳答案
我想我不太明白你的目标是什么，但我还是会尝试:
对于每个非静态网站，无论是基于 Drupal 还是其他任何东西，都有两个基本的东西为决定为给定请求提供什么内容提供“上下文”。
第一个也是最重要的显然是请求本身 .这是唯一保证始终存在的信息。在大多数情况下，这将只是一个 GET 请求，并且对于这些请求，URL 隐含地是可用的“上下文”的主要来源。除了 URL 之外，POST 请求还可以提供更多“上下文”，但是对于您的问题，有人可能会争辩说它们只是 GET 请求的一种更复杂的变体，除了来自 URL 的那些(以及在大多数情况下，无论如何都可以将 POST 请求转换为具有更详细 URL 的 GET 请求)。
第二个“提供上下文”的东西是 session .无论 session 处理基于什么机制(现在主要是 cookie)，目标总是相同的，即携带一些“状态”信息跨越固有无状态请求的边界。它通过将给定请求与来自先前请求的信息相关联来实现这一点，这些信息存储在服务器端。这允许“丰富”可用于决定为请求提供什么内容的信息。基本上，可以将其视为向请求添加更多“参数”的一种方式。
就是这样。组装响应所需的任何其他信息都需要以某种方式从请求中给出的信息中导出(并且可以说 session 处理已经是这样做的主要过程，通过添加基于 cookie 或其他一些标识符的“上下文”随请求而来)。
Drupal 很好地反射(reflect)了这个过程，恕我直言，因为它首先根据 URL 为响应组合“主要”内容，并在 session 中“附加”附加信息(例如关于用户)。只有在通过调用 $return = menu_execute_active_handler() 组装主要内容之后在 index.php 中，通过调用 theme('page', $return); 添加响应的其他元素(例如 block 、菜单等) .
因此，无论您想要“传递”给其他元素的“上下文”是什么，您要么必须从已经用于组装主要内容(URL、 session )的信息中“重新提取”它，要么必须暂时存储它在主要上下文的生成过程中。您可以通过多种方式做到这一点，例如通过将它添加到已经存储在 session 中的信息中，通过在某些函数中使用静态缓存，通过设置全局变量(不要;)，通过数据库传递东西等等......
再说一次，我似乎不明白你的目标是什么。你在这里缺少什么？
关于drupal - "context"在 Drupal 页面上，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1927883/