Expand my Community achievements bar.

Applications for the 2024-2025 Adobe Experience Manager Champion Program are open!
SOLVED

Vanity urls are not working on publishers

Avatar

Level 5

I have a page, where I wanted to add a vanity URL. After adding the vanity URL,

In Author instance, 

When checked on <SERVER_URL>/libs/granite/dispatcher/content/vanityUrls.html - VanityUrl appears fine.

In the Publish instance,

When checked on <SERVER_URL>/libs/granite/dispatcher/content/vanityUrls.html - VanityUrl doesn't appear. It should appear on the publisher instance.

 

When I hit the vanity URL directly on the publisher, I get the page with the correct content. Why do I get the correct page provided the vanity URL doesn't appear in Query?

 

When I hit the vanity URL via the dispatcher, it throws 404 error page.

 

I have checked a few threads in the community related to vanity URLs - but didn't find anything related to my query.

 

Please help me here with suitable pointers.

 

 

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

1 Accepted Solution

Avatar

Correct answer by
Level 5

Hi Everyone, 

 

Thanks for looking into it.

The issue was with the re-indexing of oak indexes. It was not working properly on publishers and hence we need to manually re-index the failing Oak indexes. It resolves the issue.

View solution in original post

11 Replies

Avatar

Community Advisor

@RitendraS11 Could you check if the anonymous user has access to this URL in publish

  /libs/granite/dispatcher/content/vanityUrls.html and set the read permission and do the testing?

 

Avatar

Level 5

@Saravanan_Dharmaraj - didn't get your point here - how the permissions on the vanity URLs page will impact here. The page is accessible on the publisher without login. It works fine with the old configured vanity URLs. Only, newly configured vanity URLs are not reflecting on publishers and dispatchers.

 

I have a similar setup for one test environment and vanityUrls works perfectly there.

Avatar

Community Advisor

Gotcha. I thought none of them are coming through that URL. So its only new one added not showing up. 

Avatar

Level 5

Yes, only the new one added not showing up in publisher and dispatcher.

Avatar

Community Advisor

@RitendraS11 I am not sure if you are using ACS Commons, please check the following rewrite mapper to debug more with VanityURLService.

https://adobe-consulting-services.github.io/acs-aem-commons/features/vanity-path-rewrite-mapper/inde...

Check the last part in that page , the reason why you get the 404 resolution in dispatcher and how to fix it with it. But one thing is if it works for other vanity URLs, it should work for this one too. 
Try to republish the page from Author which has vanity URL configured and see.

 

Avatar

Administrator

@RitendraS11 Did you find the suggestions from users helpful? Please let us know if more information is required. Otherwise, please mark the answer as correct for posterity. If you have found out solution yourself, please share it with the community.

 



Kautuk Sahni

Avatar

Level 5

Hi Kautuk,

 

We have almost solved the issue with the help of the Adobe support team. Once, the issue is resolved, I will add the solution and findings for the community.

 

Best

Riten 

Avatar

Administrator

@RitendraS11 Just a nudge! If you solved this, can you please share the answer with the Community?



Kautuk Sahni

Avatar

Correct answer by
Level 5

Hi Everyone, 

 

Thanks for looking into it.

The issue was with the re-indexing of oak indexes. It was not working properly on publishers and hence we need to manually re-index the failing Oak indexes. It resolves the issue.

Avatar

Level 4

HI,


Could you tell me how it is possible to launch the re-index the failing Oak indexes for the vanity URL?


Thanks

Avatar

Level 5

@robertol6836527 - As mentioned in my query, the vanity URLs appeared fine in the author instance and not in publishers for newly changed URLs. In my checks, I found that some oak indexes were failing. Once, the indexes were re-indexed - the issue was resolved.