Add an "Item URL" field to Views

Is there any workaround here how to get URL alias inside "Fields" section in content index view?

Try adding the “URI” field to the index, then it should also appear as a Views field.

Also, the “Link to the Content” option should appear when checking “Use entity field rendering” in the Views field options. Otherwise, “Link this field to its item” should do more or less the same thing.

If none of this helps, please update the IS to clearly state what you want to achieve (and what your current status/problem is). It’s currently mostly about what you tried, which isn’t really helpful. (The “URL alias” datasource is completely wrong for your purpose. This will just add URL aliases as separate search items to your index, not URL aliases for the indexed content.)

+1 I have exactly same problem.

"URL alias: Provides URL alias entities for indexing and searching." is not working for me.
I'm using Database search server. When new Search index field is created, then new table is created (e.g. search_api_db_INDEX_NAME_alias) with correct aliases. But when selecting such field in the Views, it is empty.

What is worked for me :

I have added to the Search Api Index URL field from general tab

In views in Search category URI field appeared and i have added it to view

in URI field rewrite options "Override the output of this field with custom text" i have added <a href="{{ url}}">some custom text</a> where {{url}} is a replacement pattern.

Works for me to workaround read more link in unformatted views fields

@ devad/#10: Seems like you want links with URL alias for content results, not URL aliases as separate results. As the “URL alias” datasource provides the latter it’s clear that it won’t help with your problem.

For me, when editing a field in Views, I either have a “Link this field to its item” option or a “Link to Content” option (depending on the “Use entity field rendering” option), both of which correctly add the link to the URL alias. I can’t tell what is going wrong in your case, but this should be working correctly in general.

Main takeaway: In 99.9% of cases, the “URL alias” datasource is not what you want to use. It’s just there because we provide generic integreation for all content entity types, and URL aliases are on of them.
Enabling a new datasource in general does not change anything about the indexing/searching/display of the existing search results, but adds new documents/result items to the index. So, you will (potentially) get other results on your search page, but the existing ones will not change in any way.
I hope this makes things clearer.

I’m not sure why the options described above are not there for you. Can you provide a screenshot of the field options in the Views UI, or details about the field in question?

Ah, thanks, now this makes more sense.
I think this should still be possible out-of-the-box by adding the “URI (search_api_url)” field to the index. Once it’s in the index, you can add it to the view as a field. It should always display the aliased URL, as desired.

However, I see that adding an indexed field to get something to display, especially such a simple thing as the item URL, is both confusing and needlessly complicated. It turns out we can also add built-in support for this very easily: See the attached patch. With it, there should now be a new “Item URL” field available in all Search API views, which (hopefully) does what you want it to.
Please test/review and tell me what you think.

Before committing, however, I fear this still needs test coverage. Would you be willing/able to provide that? it can just be added to the existing \Drupal\Tests\search_api\Functional\ViewsTest::testViewsAdmin() test method – just add a new field and then verify that’s it’s in the output.

Thanks a lot, good job so far!
However, you’re not testing the right thing: this issue is about not requiring an indexed field anymore, so instead of adding the url field first to the index and then to the view, we should just add the search_api_url field to the view (which should now always be present) right away.

Attached patch corrects this, and at least locally also passes the tests. If both you and the test bot agree with that, then I can commit.

I’d still prefer committing this, now that it’s otherwise RTBC:

• The change is almost trivial, just adding a Views data definition for a property we already have.
• It’s got test coverage (which is also a pretty simple change – with, also, a small general fix to that test which might save headaches in the future (the $this->rebuildContainer() call).
• The fact that there exists a tutorial in an issue somewhere for how to do this won’t help 95% of people wanting to achieve this.
• Adding a field to the index just for displaying goes against the basic principles of the Search API, and adds unnecessary overhead.

Great, thanks again!
Committed.