User tests: Successful: Unsuccessful:
Pull Request for Issue #13602 #14824.
This PR adds the _getAssetName, _getAssetTitle and _getAssetParentId methods to the Language table class. Prevents storing corrupt asset enties to the #__assets table.
Go to Extensions -> Language(s) -> Content Languages, open one of the languages and save it. Check the #__assets table and you will notice an entry like:

Notice that the parent_id points to asset root.1, the level is 1 and the name and title are not set correctly.
Apply the patch and save the language again. Now the assets table shows an entry like:

The PR makes sure the correct asset data is set. So:
parent_id: should be ID of com_languages assetlevel: should be 2name: should be com_languages.language.X (where X is ID of language)title: should be equal to language title, so e.g. English (en-GB)| Category | ⇒ | Libraries |
| Status | New | ⇒ | Pending |
Add content languages. Check the assets records for those to ensure they have a correct title and inherit from the com_languages component.
I have tested this item
Question: what can we do concerning existing content languages with wrong asset?
Any special message or else?
I have tested this item
| Status | Pending | ⇒ | Ready to Commit |
RTC
@infograf768 not sure if we can do something safe for broken asset
@sanderpotjer or committer : can you make drone happy?
| Labels |
Added:
?
|
||
@infograf768 done.
For removing the wrong assets an option is to include an update script like if we want:
DELETE FROM `#__assets` WHERE `name` LIKE '#__languages.%';
For removing the wrong assets an option is to include an update script like if we want:
DELETE FROM
#__assetsWHEREnameLIKE '#__languages.%';
Since language assets are not being used in J3.7.x
the above seems safe , right ?
They may not be used indeed until someone refactors this for 4.x
See my explanation and link to POC #13602 (comment)
Since language assets are not being used in J3.7.x
the above seems safe , right ?
No. Without correcting the tree values you corrupt the table.
Since language assets are not being used in J3.7.x
the above seems safe , right ?
No. Without correcting the tree values you corrupt the table.
True in the general case,
but in this case the deleted assets '#__languages.nn' have no childs , they are leaves of the tree
so there should be no corrruption, right ?
There's still a gap in the lft/rgt columns making it easier for the tree to be broken.
There's still a gap in the lft/rgt columns making it easier for the tree to be broken
so what should be done ?
is an sql query with a REPLACE() on the assets with name '#__languages.%' enough ?
like
UPDATE #__assets SET name = REPLACE(name, '#__languages.', 'com_languages.language.');at least the above should fix the asset names ?
(but not the asset title, asset title will be ok the next language is saved ?)
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-08-30 11:56:43 |
| Closed_By | ⇒ | mbabker | |
| Labels |
Added:
?
|
||
Thanks for working on this. No idea how to test though.