Skip to content

Omit host in entry link urls #339

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
f-elix opened this issue Apr 3, 2025 · 8 comments
Open

Omit host in entry link urls #339

f-elix opened this issue Apr 3, 2025 · 8 comments
Labels
feature request New feature or request

Comments

@f-elix
Copy link

f-elix commented Apr 3, 2025

What are you trying to do?

I work for a web agency and our usual setup for clients involves changing the Craft sites base urls as part of the production process.

Our problem is that when a Vizy entry link is entered, its url is not updated after we change the Craft site's base url. I understand that this is because the field value is stored as JSON in the database.

What's your proposed solution?

We would like for entry link urls to only have the path of the url, not the full one (/en/about instead of https://qa.client-site.com/en/about). Is it possible to add an option for this?

Another alternative, though less desirable, would be to have a way to update the links when a Craft site url changes.

Additional context

No response

@f-elix f-elix added the feature request New feature or request label Apr 3, 2025
@engram-design
Copy link
Member

You absolutely shouldn't need to find-and-replace anything. While we could use the relative URL to the element, that's not going to work if the URI to that element changes (like the slug is changed).

When you select a link to an entry or other element, we record a reference to that element and it's site. Something like: http://vizy.test/my-entry#entry:3674@1 - where you can see the entry ID 3674 and site ID 1 are recorded in the link. That link is then resolved upon render.

This is similar to what other rich text fields like CKEditor do. Is that not what the value of a link looks like in your editor? I'd need some information about the Vizy version you're on.

@f-elix
Copy link
Author

f-elix commented Apr 4, 2025

You're absolutely right about the entry uri changing and causing the same issue, hadn't thought about that!

We're usually keeping Vizy pretty up-to-date. In the project where we noticed the issue, the version is 3.0.7.

To answer your question, no. After changing the site url in the site settings, we noticed that Vizy entry links still point to the old site url, when the link was created. You're saying it should have been updated automatically when we changed the site url?

@engram-design
Copy link
Member

So when you add a link to an entry in the editor, what's the resulting URL? For example:

Image

@f-elix
Copy link
Author

f-elix commented Apr 7, 2025

What we see is pretty much what you have in the screenshot.

For example:

  • We enter an entry link with the following site base url: https://qa.client.com/en
  • The generated url in Vizy (that we see in the editor and the graphql response) is https://qa.client.com/en/entry-uri#entry:1234@1
  • In the Craft site settings, we change the site base url to https://client.com/en (note the qa subdomain is removed)
  • The generated url in Vizy is still https://qa.client.com/en/entry-uri#entry:1234@1 (with the qa subdomain still present).

Does that help you?

@engram-design
Copy link
Member

Hmmm, let me do some testing. But - you mention GraphQL, is that something you're using? If so, can you respond with your query?

I only as because if you're using rawNodes then that's indeed going to be incorrect, because that's the raw data stored in the database, which will always have this link. It's never run through the normalization process that you'd otherwise get in Twig (or, if you called rawNodes in Twig).

Part of the link handling is the fact that while the URL may be incorrect (and always will be until you change the link), so long as it retains the site and ID of the related entry, Vizy will replace the URL shown in the raw editor content with the correct "live" URL.

@f-elix
Copy link
Author

f-elix commented Apr 9, 2025

Yes we're using Craft as a headless CMS and Graphql for all our queries. Whenever we query a Vizy field, we either use the nodes property or renderHtml.

Here are some query examples:

{
  entry(id: "3008", site: "fr") {
    ... on article_Entry {
      articleRichText {
        nodes {
          ... on VizyNodeInterface {
            html
          }
          ... on VizyBlockInterface {
            type
            blockTypeHandle
          }
          ... on articleRichText_superquote_BlockType {
            quote
            authorName
            role
          }
          ... on articleRichText_accordion_BlockType {
            proseDrawers {
              ... on proseDrawer_Entry {
                uid
                displayTitle
                inlineRichText {
                  renderHtml
                }
              }
            }
          }
        }
      }
    }
  }
}

Or simply

{
  entry(id: "3008", site: "fr") {
    ... on article_Entry {
      articleRichText {
        renderHtml
      }
    }
  }
}

Note that we never render inline links ourselves, we always rely on Vizy's rendered html for that. The only reason we use nodes is for our custom blocks.

@f-elix f-elix closed this as completed Apr 9, 2025
@f-elix f-elix reopened this Apr 10, 2025
@f-elix
Copy link
Author

f-elix commented Apr 10, 2025

Sorry didn't mean to close

@engram-design
Copy link
Member

Great, thanks for confirming - looks like you're doing that all correctly. So I can confirm on my end that the links are rendered correctly, and return their dynamic state (if the slug of the entry changes, if the section URL structure changes, if the site base URL changes). I don't suppose it's anything like cached GQL queries or something?

I'll have to investigate further!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants