com_contenthistory is hardcoded to use com_categories as option when the view is category, this means that when you have an extension that has its own category view that is NOT build on com_categories, this will break the contenthistory for this component / view.
I have backtraced the issue to file ./administrator/components/com_contenthistory/src/View/History/HtmlView.php lines 113 .. 119
if ($aliasArray[1] === 'category') {
$option = 'com_categories';
$append = '&extension=' . $filter->clean($aliasArray[0], 'cmd');
} else {
$option = $aliasArray[0];
$append = '';
}
| Labels |
Removed:
?
|
||
| Labels |
Added:
No Code Attached Yet
|
||
Hi @pratibha-builds, thanks for following up!
When you have an extension that has a MVC named 'category', you in the CategoryModel set the $typeAlias to 'com_myextension.category'
The typeAlias is used by com_contenthistory to know what the history is for.
As you can see in the code above, the name 'category' is hardcoded and when used the component (option) 'com_myextension' is overwritten by com_categories.
This results in when saving a com_myextension category, being redirected to com_categories instead of to com_mycategory with all kind of errors, one of then the contenthistory not being saved / being saved in the wrong place.
workaround here is to never use the Category name for any of you own extensions. So I am refactoring my component that is almost a decade old and for which I am now implementing core joomla content history category name into another name.
another workaround is to keep using the category MVC in your extension, but set the typeAlias to e.g. com_myextension.xyzcategory, then you also have to create a placeholder XyzcategoryController that extends your extension CategoryController and make some additonal 'patches' in CategoryModel, as well as implement your own implementation of $toolbar->versions (as the regular implementation fetches the model name which is category and you want to set xyzcategory. This is resulting in messy code with lots of patches to get the actual result you want: difficult to maintain and likely to break in the future.
As always, hard-coding is bad practice as some day it will break things... and here we are, broken... :)
Hi @Ruud68 as i am seeing this issue could you please provide me some hint to reproduce this bug. Should i have to create some components for this issue ?