Custom Post Types 对你来说，这是一个很好的解决方案。事实上，在几乎所有情况下Post 属于Page 类型不适合您的用例，那么Custom Post Types 将他们应该被认为是Custom Content Types 而不是上述情况。这对他们的目的有一点意义。
您需要Posts 2 Posts 插件依据Scribu? 不是。好的插件，事实上是唯一一个一直被推荐用于将一篇文章与另一篇或多篇其他文章关联的插件，但是在你的例子中，你正在与客户（客户）打交道，他们的个人信息，包括你所说的“站点”。。。
这可以通过，
如何建立
Site 和
Ticket 取决于您向客户提供的服务。是每个用户一个站点还是
Multiple Sites 每
User?
不管怎样，到目前为止，我认为用户Sites 应作为用户元数据添加，因此您是否允许他们创建ONE 或MANY 由您决定的网站。当用户提交票证时，您可以为他们提供下拉列表，以选择票证适用于哪个站点。例如，此下拉菜单（选择菜单）将从与该用户关联的相关用户元字段中提取其数据。
您如何在Custom Post Type 编辑屏幕非常简单，通过使用Custom Meta Boxes 这使您能够将功能用户界面添加到custom fields.
我建议您研究两个自定义元框类，它们将有助于简化构建元框的过程：；
还有其他的，但这两个是我已经使用过的，并且仍然持续使用的。我更倾向于WPAlchemy，因为这是我开始在mass上使用的第一类WPAlchemy，但我现在可以互换使用这两种类型。有人对两者都提出了一些反对意见，这更好，为什么更好，但是。。。这是那些代码鉴赏家需要担心的
:)Custom Taxonomies 也可以发挥作用，但您可能会考虑使用taxonomies 就像你会分类一样。例如，您可以使用分类法对票据的紧急程度进行分类，
- High priority
- Medium priority
- Low priority
- Inquiry only
- Bug report
- Suggestion
...无论什么
您甚至可以通过post meta字段提供上述内容，而不仅仅是taxonomies. 一些元盒类允许您轻松地将自定义分类法集成到元盒设计中。否则，您可以使用普通的分类法元框，一旦注册并与您的帖子类型关联，它就会呈现自己。可能性有点无止境，但不要太深陷其中taxonomies, 请记住，它们将有助于对信息进行分类，并帮助您的用户在每张票据的基础上集体使用这些信息。
