标签: kentico-kontent

我有一个简单的Gatsby原型，它利用Kentico Cloud作为数据源。对我来说幸运的是，他们已经构建了一个源插件，我正在利用该插件来获取一个名为“ BlogPost”的数据类型。这按预期工作。

gatsby-node.js源代码

const path = require(`path`);

exports.createPages = ({graphql, actions}) => {
    const { createPage } = actions;
    return new Promise((resolve, reject) => {
        graphql(`
        {
            allKenticoCloudItemBlogPost {
              edges {
                node {
                  elements {
                    url_slug{
                      value
                    }
                  }
                }
              }
            }
          }
        `).then(result => {        
            console.log(result);
            result.data.allKenticoCloudItemBlogPost.edges.map(({node}) => {
                createPage({
                    path: `${node.elements.url_slug.value}`,
                    component: path.resolve(`./src/templates/blog-post.js`),
                    context: {
                        slug: node.elements.url_slug.value,
                    },
                })
            })
            resolve();
        })
    });

}

这很好用，但是我真的想添加第二种数据类型，称为“ Articles”

按照Gatsby Kentico入门模板示例，我修改了gatsby-node.js文件

const …

我正在试验使用VueJS的Kentico Delivery Preview API，该API允许您通过提交用于授权的承载令牌来获取未发布的内容（https://developer.kenticocloud.com/reference#authentication）。但是，无论我做什么我都会得到401的响应。PROJECT_ID，ITEM_NAME和TOKEN都是正确的，是从项目中提取的，因此这不是拼写错误。我承认我对auth没有太多经验，但是可以提供任何帮助：

var app = new Vue({
    el: '#app',
    data: {
        message: 'Hello Vue!'
    },
    mounted () {
        axios
          .request({
            url: '/items/ITEM_NAME',
            method: 'get',
            baseURL: 'https://preview-deliver.kenticocloud.com/PROJECT_ID',
            headers: {
                'Authorisation': 'Bearer TOKEN'
            }
          })
          .then(response => {
            console.log(response.data)
          })
      }

})

ASP.NET Core 2.2网站显示了来自Kentico Cloud CMS的数据。其中一些项目包含富文本字段。这些字段可能包含指向其他内容项的链接。这些链接应由网站解析为URL。

该文档建议通过实现IContentLinkUrlResolver接口来完成此操作。但是，对于我们的网站而言，该样本实在是太虚伪了。我们的解析器需要知道请求的上下文（例如当前的UI文化，因为该站点是多语言环境）和路由定义，因为这是定义URL外观的唯一位置。

实际上，解析程序需要能够调用Url.Action，就像它可以在视图内部一样。

网址解析器应尊重路由和当前的ui文化。预期其逻辑如下：

if (the linked content item type is Page)
{
    Url.Action("Page", "Home", new [] { codename = content item’s codename });
}
else if (the linked content item type is PageFont)
{
    Url.Action("Font", "Home", new [] { codename = content item’s codename });
}
else
{
    throw an error about an unsupported content type.
}

规则定义为：

var localizationOptions = app.ApplicationServices.GetService<IOptions<RequestLocalizationOptions>>();

app.UseRouter(routes =>
{
    routes.MapMiddlewareRoute("{culture=en-US}/{*mvcRoute}", subApp =>
    {
        subApp.UseRequestLocalization(localizationOptions.Value);

        subApp.UseMvc(mvcRoutes …