| Announced on | Rollout starts | Rollout ends |
| August 8, 2023 | August 8, 2023 | August 12, 2023 |
We are excited to announce that content blocks are now enabled by default in all existing help center articles.
这个声明的答案the following questions:
What is changing, and why?
Content blocks let article authors insert the same content in multiple articles. Since their launch, content blocks have been an opt-in feature, which means you had to enable them on every article in which they were used.
We’ve heard from many customers that the need to perform this extra click is slowing down their flow and introducing extra steps they must take to use content blocks. To address this issue, we are now enabling content blocks on all existing articles by default.
How will this affect me?
If you are an Enterprise customer you’ll notice that all your existing articles have the content blocks icon available in the article toolbar and the Enable button has disappeared from the article setting sidebar.
For newly created articles, content blocks will be available only after you save the article for the first time. This is a temporary limitation that will be removed in the near future.
What do I need to do?
You don’t need to take any action. However, if you’re interested in learning more about content blocks readReusing content with content blocks.
9 Comments
Hi,
can you remove us from Roll-Out list? We found that if Content Blocks are enabled the internal article ID changed which cause our automatic Translation tool for Article can´t get this by API and we need a huge re-design.
Why such things are auto roll out when ID´s (internal Edit Mode ID) is changing?
Thanks.
Tobias
HiTobias Hermanns,
The article ID changes only in Guide Admin, not in the published version of the article, so it doesn't affect the functionality of HC API. Do you have your translation integrations set up based on the article editor URL?
Hi,
yes based on Editor URL, as may translation comes in place before publish is ready.
HiTobias Hermanns,
Please help me understand how is your integration set up. As the editor URL is not visible in our API I have trouble imagining your workflow. Are you manually entering the URL into the translation software? How is the translation returned to the editor?
HiKatarzyna Karpinska
The Custom App is query:
"/api/v2/help_center/en-us/articles/01H7AT7KTMF163YBYEBVGT9KJJ.json?include=sections,categories,translations"
However /articles/notexternalID once Content Cues is enabled.
So of course, we can rework our App, but 4 days isn´t much time here.
We query it from Edit Mode automatically by some Browser Extension in advance.
So yes you are right, we can use Preview Mode ID or Publish ID, but the change in Edit Mode interrupt our Apps on August 12.
HiTobias Hermanns,
Thanks for providing the details of your case - it definitely makes it clearer.
Unfortunately, to support further development we need to change all the internal (editor) ids in the nearest future, so to make your script work you'll need to update your current script and base it on preview mode ID or publish ID.
What I can do now is to temporarily exclude you from the rollout to give you some time to do so. If that's okay for you I'll open a ticket where we can discuss further details.
As a side note. Please consider building a translation flow based on ourpublic API. It's the most stable integration point where any breaking changes are announced a long time ahead. Anything else (HTML formats, URLs may be undergoing changes without prior notice).
Hi,
thanks for your offer and understanding workflow. Our developer confirm he can fix it within 3 days so I think we are good. I hope next time of changes may have a bit earlier announcement, new things can be optional enable / disable, but release / change something also need let KB Team know new ways of working and use other id, i.e. if do this process manually.
We are good now and thanks for quick feedback here.
Hi Katarzyna,
Like Tobias, we were caught off-guard by your roll-out.
We use your standard REST API, just the GET/POST requests to download and upload articles - we'd just use the ID from the Editor and that could be used:
a) for uploading/downloading articles and
b) the same ID could be used to open an article in the editor or in the Help centre, depending on what we wanted.
Now it appears we have one ID for an article in the editor, but a different ID for the same article when its in the live Help Centre. And its the Help Centre ID that we need to get for our scripts.
I dont doubt you needed to make changes but its messy & makes more work when for example links to the editor dont work anymore.
I guess my real concern is that you say "to support further development we need to change all the internal (editor) ids in the nearest future"
Does this mean there are more changes coming? When & what sort? I dont think we want to be caught short again.
Thanks
HiPat Higgins,
I'll address your last question first and hopefully won't make it too confusing.
In the near future, all the articles in the editor view will have new ids. Once they receive these new ids they will be stable. We don't expect any further changes to them, but they will permanently differ from the ids of published versions of the articles. You will also still be able to get the ids of the published versions from the preview links within the editor.
We also do not expect any changes to the ids of published versions of the article. These ids are a documented attribute in our public API (as you rightly say) and if, at any point, we will need to make any changes to them we'll announce them in advance as a breaking change. (This is where it gets confusing, but our public API does not include the editor articles).
Why does it matter? We hope in the future to build more public APIs that will allow us to e.g. make changes to the articles before they are published or to manage content blocks. For that, we had to make a lot of strategic changes which resulted in the changes to ids.
Hope it all made some sense and I'm sorry for the frustration it caused.
Pleasesign into leave a comment.