I will add here that the patch in 🐛 Fields Content Deletions of (already Translated) Entity Content are not reflected in new Translations updates Needs review seems not needed anymore - the issue described there doesn't exist anymore (at least in my tests).
Performed more testing and troubleshooting - no luck. Then looked at the dates - it has been almost 3 years since the patch was added. Back then TMGMT was v1.0. I removed the patch and everything worked as expected. The issue described in this ticket seems to be gone, which means the patch is no longer needed. Removing patch also fixes 🐛 Error when creating new translation Active
This needs review and testing.
In my application I am working with two languages - EN and ES. I have node entities referencing paragraphs with fields referencing other paragraphs. The translations seems to be failing on the nested paragraphs (or maybe any embeddable entities). That is when this patch is applied. Long story short - the patch does not seem to account for nested/referenced entities such as paragraphs.
I don't know the internal mechanics of the translations that deep, so can't really tell what is happening under the hood, but the Drupal\tmgmt_content\Plugin\tmgmt\SourceContentEntitySource::doSaveTranslations has the following flow when it comes to translating a node with a referenced paragraph:
- on the first call it deletes existing translation of the parent node entity (if the translation exists) - this is a change the patch introduced,
- then it recreates a fake translation with the original untranslated values (source language), gets the actual translation for the target language, then
- goes over parent entity's fields - sets translated values, then
- goes over embeddable fields - and attempts to set values for each embedded field's item (in my case paragraph) by recursively calling itself with the paragraph as the entity to operate on.
When the initial doSaveTranslations call is made, the passed in node entity has the default (source) language set as the active language, and when the second recursive call is made for a referenced entity (paragraph in my case) - the passed in referenced entity has now the target language set as the active language. The doSaveTranslations method once again attempts to delete existing translation for the passed in entity (paragraph this time) and then goes over the same workflow - paragraph own fields, referenced entities' fields.
It fails on line 528:
527: if ($manager->isEnabled($translation->getEntityTypeId(), $translation->bundle())) {
528: $manager->getTranslationMetadata($translation)->setSource($entity->language()->getId());
529: }
Not entirely sure what is the purpose of the line 528, but calling setSource() eventually leads to getTranslatedField, where there the following unexpected condition happens:
protected function getTranslatedField($name, $langcode) {
if ($this->translations[$this->activeLangcode]['status'] == static::TRANSLATION_REMOVED) {
throw new \InvalidArgumentException("The entity object refers to a removed translation ({$this->activeLangcode}) and cannot be manipulated.");
}
$this->translations[$this->activeLangcode]['status'] is actually NULL, but the "==" makes it equal to static::TRANSLATION_REMOVED which is 0. Changing the operator to "===" solves the issue for me.
This however does not address the origin of the issue, which I believe is the way nested paragraphs are being processed after the patch is applied - the source should not be set to the target language on the line 528.
I added post update hook to update job statuses to "finished". The criteria for the update - a job must have all job items accepted.
Added a merge request , and also posting the updated patch in case anyone needs it.
+1 to the above comment
FYI, the patch in #39 has lot more stuff than needed.
Attaching the new path which works with v1.5.0
@chris dart - what are other changes required and have you had a chance to create a ticket?
Scanning the module with rector reveals only one change needed, your comment is a bit confusing.
+1, considering just the version change in the info file.
The filters were added into https://www.drupal.org/project/helpfulness/issues/3518878 🐛 The report page crashes at 50k records Active
I have changed the ticket from the bug report to feature request. MR7 now contains full refactoring including filters. MR6 contains only report refactoring for performance.
I refactored the report page a bit:
- Added automated Pagination and Sort/Order support via PagerSelectExtender and TableSortExtender
- Added limit to display 25 records per page,
- refactored and cleaned up the code a bit.
This is ready for review and testing.
I am going to create another ticket for adding filtering support.
I am working on refactoring of the report page. It is a bit sub-optimal from the coding and usability perspective:
- Instead of looping trough results to convert each of them into an array, PDO::FETCH_ASSOC could be used to get results as arrays in the first place.
- from the usability perspective, unlikely anyone is interested too see hundreds results on a single page
- it needs a pager paging
- it needs filters - no way to only see results you need
- the results are split into two tables, where it should be one table with filters
- etc.
It is easier to refactor and get a good UI.
The project page needs updates:
- Looks like the API and Plugin information has to be dropped, as the module doesn't seem to provide any API and doesn't define custom plugin types,
- README.md should be updated for the same reasons.
This issue seems to be outdated: the module is already at 8.x-1.2
Should this be closed or refactored as the 2.x roadmap?
Closing as cannot longer reproduce on a clean D10 install. Other factors not directly related to the Scanner module might have played role.
Ok. This is a year old ticket, it was originally created against version 8.x-1.0-rc7 of the module. Back at time the issue was present.
Apparently version 2.x works as expected. 8.x-1.0 works as expected as well.
It could have been a combination of a few factors, but I can't replicate it now, at least not on a clean D10 setup.
Probably makes sense to close?
How are you triggering this issue?
Simply by searching the content. The output HTML is corrupt.
Ok. That should be simple.
I am not sure what the projects's technical plan is so don't know what the next step would be - keep supporting GeneratedURLs or drop the support?..
Firefox, Chrome, Edge... I believe it happens on desktop (or rather at the desktop zise) during initialization, after which the sidebar trigger is failing. It works on mobile (again screen size, not a device) and if you hide the taskbar on mobile screen size, it will be not possible to show it back on desktop screen size.
Not sure if this helps, but for me is throws an error in console and refuses to update related variable in the local browser storage:
Error:
`Uncaught TypeError: can't access property "innerHTML", sidebarTrigger.nextSibling is null
And the local storage variable that is not getting updates as the result of the above is Drupal.gin.sidebarExpanded.desktop
I added Merge request !11248, which is a rebase of the MR5758 on top of the 11.x branch. Fixed a few pipeline issues, but few other pipeline issues remain as I am not sure where the tests are failing or the tests need to be adjusted.
Also, I do not understand the changes entirely, so would be great if @ksenzee or @jurgenhaas could review the changes.
I am going to apply this changes against 10.4.x since this is where I need them. 10.4.x path is coming soon (should I have success)
euk → changed the visibility of the branch 3168966_cke-inline-media_rebased to hidden.
euk → changed the visibility of the branch 3168966_cke-inline-media_10.2.x to hidden.
euk → changed the visibility of the branch 3168966_cke-inline-media_10.2.x to active.
euk → changed the visibility of the branch 3168966_cke-inline-media_10.2.x to active.
euk → created an issue. See original summary → .
I want to add that Solr's default results limit is 10 items -- in my scenario, where I have Solr search and filter by taxonomy term - out of 600 nodes with about 20 terms used I only get 10 terms for the first 10 nodes returned.
Minor fix to the 1.3.x. patch.
A few more updates to the 10.3.x patch.
Adding updated patch for 10.3.x
While D10.3.x. merge fails (specifically - unit test, though it shows 100% success rate), here is the patch for D10.3.x - should work with 10.3.6 and up, till 10.3.10 at least.
euk → changed the visibility of the branch 606824-allow-admins-to to hidden.
@ramprassad, you bit me to it =) Though I am currently working on creating a D10 patch, and there are a few differences anyway. I looked at your PR and left a couple of comments. I also have a few suggestions:
- I do not recommend storing a default UID for this new cancellation method in the configs: developers then have to maintain this config, while most of the time admins probably want to reassign content to different users (based on my experience with medium to large sites), therefore making this default setting irrelevant and annoying.
- Added to the above - if the account matching the default UID has been disabled/deleted - you would have to update the config and also might have to deal with consequences of assigning content to deleted/disabled users.
- When reassigning content, you should account for editorial permissions - is the new user able to edit content? The simplest way to check that the content belonging to the account being deleted can be edited by the new users is to compare roles and make necessary adjustment to the account suggestions in the entity autocomplete.
- Same as above should be also considered for multiple accounts being deleted in bulk - here you'd want the new user have all the roles the deleted users had, or let the admins know what the consequences are if there are some mismatches.
- There should be a hook/event allowing to alter user selection - some modules like Workbench Access have their own content permissions model and need to be able to intervene.
I am including the above into my D10 patch. Hopefully will have it by EOD.
There is a module that attempts to solve this - https://www.drupal.org/project/user_delete_reassign → , but it was not updated for a long time, has a few bugs reported and doesn't work for me with the view bulk op out of the box. Another considerations to be made - this should work with Workbench Access and similar modules. For that there should be a hook/event and validation system which would allow to alter username suggestions or validate new owner content access rights.
+1 for this feature. Going to look at it.
Apologies! Use this file instead.
Here is the re-roll, however I haven't had a chance to test it yet
Looking at the code I wonder - why does ariaCheck() need a click event listener? It actually looks like it calls back this.closeMenu(), which calls ariaCheck() again creating an infinite loop?
Btw, ariaCheck() needs to be documented.
Same issue with BEF v6.0.6.
This will be always an issue if BEF is going to keep changing their create() and __construct() signatures all the time. Additionally, VeflTrait has a very obscure dependency on the Vefl service, which doesn't really exist in Vefl trait, but rather is expected to be added in the "treated" class.
The way to decouple from this is to provide Vefl service along with the trait, as a getter for example. There are a few traits in the core that use this approach, so we can call this an acceptable practice.
Another confusing thing is when an inherited member from a base class is overridden by a member inserted by a Trait, but this is a different story.
I am adding another merge request to help with the service dependency.
The DynamicMethodResolutionTrait trait performs mapping of form IDs to internal methods. Internal methods naming should be in the form of "formAlterFormId". E.g. for a form with ID "node_form" the matching method would need to be called "formAlterNodeForm". Specific form ID has a precedence over the base form ID, thus still allowing for targeted form alters. If there is a need to use a generic form alter callback that would cover all the form IDs supported by plugin the 'genericFormAlter' can be used.
An old ticked, but it is still relevant, and just recently caused me an issue. I spent a good chunk of time today figuring out what in the world has happened to a merge of a few filter.format.* config files. Turns out weights were merged somewhat incorrectly. Not sure what happened there, but while comparing those config files for ordering I found that it is really hard to see how the ordering has changed with just a diff tool. You really have to spawn a site, import configs and compare ordering of filters visually through the UI. With the weight values and without visual augmentation - go figure what is the order.
I am not sure why are we so hung up on using weights?
Assuming a machine name is used for keys and the config maps are sorted by config keys - why not implement a binary tree with the reference to left and right (top and bottom) children by their machine name. This seems to solve the ordering and doesn't require storing a numeric position which apparently changes constantly and is the root of all troubles.
- There is always a root at the top - has left, first child, pointer empty,
- Leaf items will always have their right, next child, pointer empty,
- The rest is self explanatory
Benefits:
- Each item is clearly marked where in the tree it is located.
- Splitting or inserting an item anywhere in the tree will only alter the adjacent items, not the whole tree
- Reordering items in the UI and saving the configs will not alter the structure, if the final ordering is kept the same
At least for flat structures like filter formats, fields without field groups etc - this should be really simple.
Merged into 1.x
Just tested it with paragraphs - the patch works.
The patch in #71 🐛 BaseFieldOverride fails to take into account ContentEntityInterface::bundleFieldDefinitions() when invoking onFieldDefinitionUpdate() Needs work still fails. This time with the following error:
Error: Call to a member function getSettings() on null in /var/www/web/core/lib/Drupal/Core/Field/FieldConfigBase.php on line 376 #0 /var/www/web/core/lib/Drupal/Core/Field/FieldConfigBase.php(289): Drupal\Core\Field\FieldConfigBase->getSettings()
This happens on config import, and seems to be related to translations somehow (probably not the cause but one of the triggers for this issue), as the only update affecting the current build was enabling translation...
euk → created an issue.
Here is a patch that worked for me.