It seems a better way to store multi-value data as JSON encoded string. Raised merge request according to that.
Before MR changes:
After MR changes:
Now pages load fine in frontend.
Moving to NR.
supreetam09 → created an issue.
An even simpler patch.
There is some SSH error, I can't create MR.
Adding a patch instead for the fix.
We need to handle 2 cases:
- When the count of type of entity bundles involved is more than 1, then current code will work, as
count($handler->getReferenceableEntities(NULL, 'CONTAINS', 2))will return 2 - When the count of type of entity bundles involved is equal to 1, we need to count the items inside bundle array key. Ex: in my case, the count should have been of
count($handler->getReferenceableEntities(NULL, 'CONTAINS', 2)['gallery_item'])
Changes from this caused a new issue https://www.drupal.org/project/inline_entity_form/issues/3469864 🐛 Remove entity button not showing in Complex Inline Entity Form after upgrading to 3.x from 1.x Active
Supreetam09 → created an issue.
Patch in #19 does not work anymore with 3.0.0-rc20. Re-rolling.
Tests are pending still, so keeping NW.
@Rajeshreeputra I am fine with taking it up in a separate issue as well, ultimately resolving the issue matters.
(I think it would be better to keep both issues 1 & 2 under one umbrella for better context, so creating a single issue would be better)
Created new MR https://git.drupalcode.org/project/entity_clone/-/merge_requests/85 to handle the issue
Request to maintainer to reopen this and set to needs review.
This is causing inconsistent behaviour in multilingual sites.
In a multilingual site, the moderation status dropdown is not shown in the entity clone form, rather the old Save cloned Content as published checkbox is shown.
But when we select the checkbox and clone the entity, the entity gets cloned in draft state, instead of published as selected - this behaviour is inconsistent.
First point in Acceptance Criteria says,
If multiple languages are configured on the site, there is no change to the entity clone form (this preserves existing behavior that will set all cloned translations to "draft")
But, if thats the case, either we need to hide the Published checkbox completely for multilingual sites, or be consistent with chosen option and publish all translations upon cloning.
We need a new tag for this. Upgrade is blocked.
In that case, this issue can be closed right?
Closing this. Reopen if you feel otherwise.
Adding the patch to achieve the desired result.
Supreetam09 → created an issue.
@baaluaanand Check if you have created a custom client plugin extending OpenIDConnectClientBase. It was the same case for me as well. If thats the case, you need to update your custom plugin for the methods you are overloading.
I created a new patch refining the code in #14. Since languageManager is not being used anymore, I removed the references for it in my patch.
I don't think this issue is coming from advagg module. We are also facing this issue and trying to figure out whats causing this but we are not using this module. Maybe try to uninstall this module once and check if the issue still persists to confirm if the issue is from this module.
@acke I think this issue would get fixed if you create a new release for 2.x (ex: 2.0.1) with the commit https://git.drupalcode.org/project/back_to_top/-/commit/b085e769bd1c365a... and reverting the changes from https://www.drupal.org/project/back_to_top/issues/3337192 🐛 The module jquery_ui_effects does not exist Needs work
This 2.0.1 release will make the upgrade path smooth from 2.x to 3.x
@b_sharpe You mean checkboxes with GET, POST, PUT, DELETE etc. options?
Adding similar patch here as well. Please review.
Supreetam09 → created an issue.
Adding patch to fix the issue. Please review.
Also check the screenshot for clear understanding.
Supreetam09 → created an issue.
Adding patch to fix the issue. Please review.
Supreetam09 → created an issue.
I think the previous patch/commit is still incomplete as I landed on the error while accessing view:
TypeError: Drupal\search_api\Utility\QueryHelper::addResults(): Argument #1 ($results) must be of type Drupal\search_api\Query\ResultSetInterface, null given, called in /var/www/html/docroot/modules/contrib/search_api/src/Plugin/views/cache/SearchApiCachePluginTrait.php on line 186 in Drupal\search_api\Utility\QueryHelper->addResults() (line 86 of modules/contrib/search_api/src/Utility/QueryHelper.php).
Its kind of expected since the query is NULL, so the result set in https://git.drupalcode.org/project/search_api/-/blob/8.x-1.x/src/Plugin/... also becoming null.
Since previous patch is already committed, adding a second patch to fix it (excluding the changes in #9). Please review!
For people who are facing such, you need both this patch and the patch in #9 to make it work.
Adding patch for the config change.
Supreetam09 → created an issue.
We had the same issue and under same scenarios.
We had a disabled search index and we ended up on the same error. Also other update hooks from Facet module facets_update_8012 was failing for the same error.
I can also confirm after applying the patch #9, the issue got fixed. Thanks for the patch.
I think we can move to RTBC!
Adding the patch to fix the issue.
Supreetam09 → created an issue.
Re-rolling patch for Password Policy 4.x
#3 only partially fixes the issue.
I am using latest version available for both Password Separate Form(2.0.0) and Password Policy(4.0.0) module.
The latest changes introduced in Password Policy module brings in lot more changes than #3 patch. We should replicate the exact same behaviour as Password Policy module does here. Check out the entire changes from this line in Password Policy module.
Adding patch for the same.
The previous 9.5.x patch is not applicable anymore after Drupal 9.5.8 release as ImageStyleDownloadController.php has been changed in this release. Adding new patch for 9.5.8+