telerik/docs-seed

Incorrect parsing of slug links inside Tip blocks

Closed this issue · 17 comments

attilaantal commented

Description
Slug Links in Tip blocks are not interpreted/parsed correctly, hence the generated URL is invalid. Issue appears on multiple pages in the documentation.

To Reproduce
Visit any of the following pages, find the Tips that contain links and inspect the item.
Batch Editing Overview
Batch Editing Client-Side API
Data Editing - Custom Edit Forms

Additional context
Probably the entire Documentation is affected, where slug links are included in Tip blocks.

imtodor commented

Works fine with docs.telerik.com/devtools/justmock/getting-started/quick-start (link to the article - https://github.com/telerik/justmock-docs/edit/master/getting-started/quick-start.md).

Can you check whether the slugs exist?

marin-bratanov commented

The JustMock article does not have the custom alert blocks from the ajax docs. My best guess is that the liquid tags within custom blocks are not evaluated at all. I think the fix we used to have for this was to make sure the custom blocks parsers either ran first, or ran last, perhaps Ianko Dzhemerenov will remember more, he wrote them.

The issue still manifests in the ajax docs, here is another article (see the Which File Do I Need to Install link in the second tip): https://docs.telerik.com/devtools/aspnet-ajax/getting-started/first-steps#first-steps-with-ui-for-aspnet-ajax.

Sample markup that causes the problem

>tip The following article can help you choose the installation type that is most suitable for your needs and preferences: [Which File Do I Need to Install]({%slug installation/which-file-do-i-need-to-install%}).

Resulting link https://docs.telerik.com/devtools/aspnet-ajax/getting-started/%7B%slug%20installation/which-file-do-i-need-to-install%%7D

Correct slug is present in the article: https://github.com/telerik/ajax-docs/blob/master/installation/which-file-do-i-need-to-install.md

imtodor commented

Here is another example for working slug in a custom alert block - https://docs.telerik.com/devtools/wpf/controls/radbulletgraph/radbulletgraph_overview

marin-bratanov commented

Here is another example of it not working in a custom alert block (see the second block): http://kendobuild-staging.openstack.progress.com/blazor/components/window/size

The problem comes from the / symbols. The ajax repo (and now the blazor repo, because it is me writing it) use those to match the paths in the slugs. The WPF repo uses dashes. I tried changing the slashes to dashes in the article above and it worked. Is there a way to keep using slashes? Even if I can rework the blazor repo (only 20ish articles at the moment), the ajax repo has well over 6000 so changing that is not feasible.

  • 👍2
bsivanov commented

We isolated that all blocks except the default one (> or >warning) are breaking the slugs.

  • 👍1
dessyordanova commented

Please refer to the following help article and have a look at the first 3 important fields: https://devdocs.telerik.com/devtools/winforms/controls/richtextbox/overview
It seems that a slug with a slash in it breaks the link.

marin-bratanov commented

Yes, it's the slash in a slug in a > block #14 (comment) . I've started using dashes even though I have >100 articles with slashes already. Dashes are ok.

dessyordanova commented

Yes, the slashes are OK. But we have quite a huge number of articles with slashes in the slug.

marin-bratanov commented

oh, yes, in AJAX where I first hit this we have thousands (probably > 7000), in Blazor I have about 120, I think.

imtodor commented

Substituting slashes with dashes is easy, nevertheless the count of the slugs...Find/Replace with a regex will do the job.

dessyordanova commented

But this will require redirects which are not always so easy to implement as it sounds.

imtodor commented

But this will require redirects which are not always so easy to implement as it sounds.

AFAIK, a slug is something like a 'key' for a given article? Why the redirect?

  • 👍1
dessyordanova commented

I suppose because, on the website, the real URL (containing the slash) will be stored in the page, not the slug. If we change the slug, wouldn't it change the URL as well? Maybe I am wrong?

marin-bratanov commented

The slug is an internal ID, it does not pertain to the actual URL. The file name determines the URL

pepinho24 commented

The issue seems to be related to the RegEx finding the slug inside the alert. It currently searches for "\w" and a dash:

A potential fix is to enhance the regex to include some of the more common characters as well /.*?(%7[Bb]%slug%20([0-9a-zA-Z_\-\(\)\*\.\/\,\%\'\?\:]+)%{2}7[Dd])/

This covers all the following scenarios: https://rubular.com/r/5xkN2wCqUr4mWN

  • "slug-with-dashes",
  • "slug/with/forward/slashes",
  • "slug.with.dots",
  • "slug-with-(brackets)",
  • "slug_with_underscore",
  • "slug*with*stars",
  • "slug1with2numbers3"
  • "slug,with,comma"
  • "slug%with%percentage"
  • "slug:with:colon"
  • "slug?with?question?mark"
  • "slug'with'quote"

Here is a ruby file that can be used for testing