Do you actually have anby data in that field?

No, it's left out for whatever reason in the list model. Normally, it would show the author's alias of the tagged article like it does in the article info.

To make it more clear - it's the field that shows the author's name in the article info.

You are speaking about com_content? Which template? core_created_by_alias is not a field of com_content.

In default_items.php article fields mostly are referred with a leading 'core_', e.g. the title of the article is referred as $item->core_title. This is Joomla native so not depended on any template, but I'm using Cassiopeia. In JsonapiView.php of com_tags created_by_alias is included in the array for document view, but not in the array for list view. This might be on purpose, but it would be great to have it also in list view.

From what I see, we do not store core_created_by_alias of the content item (the field is there, but it is always empty) in #__ucm_content table. So there is no way to get that data in the layout unless you write some custom code to query that data directly from database.

The best thing you can do is using $item->author in the layout and it will display name of the user who created that item (It's name of the user account, stored in #__users table, not created_by_alias of the item).

The field needs to be added to UCM field mappings.

Thanks for the clarification. Unfortunately, $item->author does not work as it shows the user who created the tag, not the article's author.

Thanks for the clarification. Unfortunately, $item->author does not work as it shows the user who created the tag, not the article's author.

Ah, Yes. I expected core_created_user_id field in #__ucm_content table store created_by data of the content item, but it is not (strange to me)

For your case, the simplest option would be updating UCM field mappings so that core_created_by_alias will be stored properly. You can do that by running an update SQL command to your database:

UPDATE `jos_content_types` SET `field_mappings`='{"common":{"core_content_item_id":"id","core_title":"title","core_state":"state","core_alias":"alias","core_created_time":"created","core_modified_time":"modified","core_body":"introtext", "core_hits":"hits","core_publish_up":"publish_up","core_publish_down":"publish_down","core_access":"access", "core_params":"attribs", "core_featured":"featured", "core_metadata":"metadata", "core_language":"language", "core_images":"images", "core_urls":"urls", "core_version":"version", "core_ordering":"ordering", "core_metakey":"metakey", "core_metadesc":"metadesc", "core_catid":"catid", "asset_id":"asset_id", "note":"note", "core_created_by_alias" : "created_by_alias"}, "special":{"fulltext":"fulltext"}}' WHERE  `type_id`=1;

Replace jos_content_types with the right table name (replace jos_ by database table prefix uses on your site). After that, edit articles, re-save it again. The core_created_by_alias will be saved with right data and you can use it in your layout.

Thank you for your extensive reply. I've updated the record with the completed mapping table and edited the articles and re-saved them again, however the author's alias still shows up empty. Is there anything else I need to change/override?

thanks a lot

Seems this breaks the tags - I cannot add tags anymore to an article.

That change should not affect adding tags to article. If you are having with adding tags to article, you can try to apply the change from this PR #39254 to your site

That change should not affect adding tags to article.

This is what happens: I can add tags while editing the article, however once saved and closed, the tags are gone, they also don't show up in the frontend. When I undo the change of the UCM field mappings, tags behave normal again, but the tags I entered during the altered UCM mapping still don't show up. Maybe the order of the fields is wrong? ("core_created_by_alias" : "created_by_alias" after "note":"note")

If you are having with adding tags to article, you can try to apply the change from this PR #39254 to your site

Is 39254 already in J4.3.0-alpha2-dev?

Thanks
Cyana

Maybe the order of the fields is wrong

The order is not important. I tested it on my local computer before and it worked.

Is 39254 already in J4.3.0-alpha2-dev?

I'm unsure. You can try the nightly build package https://developer.joomla.org/nightly-builds.html , I see that it is already included. Or wait for next stable release 4.2.6

I'm very sorry, my mistake. I edited the ucm mappings directly via phpMyAdmin, and entered a CR into it somehow. This obviously broke it. Now it works perfect - thanks a lot for your great help :)

You're welcome. I'm closing this issue for now. If anyone has similar request, please use the solution suggested here #39368 (comment) .

Why was this closed? This needs to be fixed in core.

Without knowing the history of UCM design, I'm unsure if this is a bug or a feature request. I also asked on Bug Squash chat few days ago but there has been no answer/decision about what to do with this issue. As there is no other similar issue reported so far, I closed it because that mean that there are not many uses need it - @Hackwar even said that he would drop the table completely (Yes, part of me agree with you that it is a bug). I will re-open it and hopefully it won't stay open for few years without any further action.

For me, it's a powerful enhancement for tags. Categories are not always suitable, since you can only apply one category to an item. I'm building a book library, and books can have more than one author - just as example.

I too don't know the history of UMC and for me it seems not the right way to use this field. For me is not clear what the content of ths field should be.
In general, informations like these (different authors of a book) are stored as custom_fields, this could explain why this was never mentioned before. With custom fields it seems much more clear.

For me is not clear what the content of ths field should be

It's a standard field of articles, and displays the author in the article_info section.

The cool thing about this field is that it can be overwritten in the article. So I have only one user called book_author , while its alias is overwritten within the book's article to the real author's name.

This is extremely handy because otherwise I would have need to create thousands of users, and the biggest bonus with joomdontion's fix is that the author now also is displayed in tagged lists, eg. list of books with tag 'Thriller' or 'Commedy' and so on:

This all can be done just by using standard Joomla, and that's fantastic. Also, the fix does no harm to any other Joomla implementation, so I don't see why it shouldn't be fixed on default.

In general, informations like these (different authors of a book) are stored as custom_fields, this could explain why this was never mentioned before. With custom fields it seems much more clear.

We are talking about the user as author of an article. Displaying the user who created an article within tagged lists should be helpful also for other Joomla implementations.