Just ran into this, steps to reproduce:
- Site had existing term reference field
- New term reference field added to facilitate manual content entry changes before feature launch
- Original term reference field deleted on feature launch
- Term pages show content for field that no longer exists
Sorry about that, just pushed a fix.
Actually, marking as "needs review" as I'm unsure if prod issue is related yet.
Changing to needs work as this fixed locally, but not on production server, investigating further
The patch fixes the issue, marking as critical as uploading images is key functionality not possible on the current Drupal release.
Fixed ajax issue, marking as needs review.
Pushed progress on fixing this, problems identified:
- Assumes the nested depth of form field in form, this is not true if in paragraphs.
- Tries to return a field value as an ajax response, must be render array for field or ajax command.
I haven't fully solved the second issue yet, so leaving as "needs work" for now. It no longer errors on style value change, but the icon value is yet not updated successfully.
It doesn't solve the issue I'm seeing, the paragraph is on a block content entity where I'm investigating which could be related
In the case I'm looking at the issue is that the icon field is nested within a paragraph field. There may be other issues with the logic in this function that the provided patch would work for, but it does not solve for every case.
Pushed a temporary fix commenting out all full cache clears, not to be merged.
The correct fix is to add the appropriate cache tags to the render array in question.
damondt → created an issue.
This is also addressed in the larger D10 compatibility issue https://www.drupal.org/project/webform_dropzonejs/issues/3299484 📌 Automated Drupal 10 compatibility fixes Needs work
Update: it appears having confirmation type of inline may be requirement to reproduce
Not reopening without being sure of all steps to reproduce, but I ran into this on Drupal 10 with a paragraph relationship and a rendering language of "Content Language of View Row"
The issue tag "needs tests" is for when code has been written but it needs tests, removing tag and changing back to "active".
@naveenvalecha The issue description contains all steps to reproduce. To provide it more verbose and in list form:
- add a webform reference field to an entity bundle (ie content type)
- add an entity (ie node), select a webform for that reference field, and save the entity
- enable metatags for that entity type and set the meta description to a token that will render the webform (ie the default [node:summary])
- ensure that field is output for the view mode you will view the entity in (ie default) and view the entity
@cilefen It's not rendered twice on the page, where I encountered this and in the related issues where this is mentioned the only step to reproduce is that it go through the render process, being output on a page isn't a requirement to reproduce.
Pushed progress to 3398223-support-hr-tag-classes, not yet fully functional. Focusing on hr tag first.
The approach described in the ckeditor issue queue when implimented with drupal's existing ckeditor methodology looks like:
- Add support for an "hrClass" attribute in the dckeditor data model in ckeditor5.ckeditor5.yml
- Have drupal allow classes for hr tabs in ckeditor5.ckeditor5.yml
- Create a DrupalHorizontalLine plugin similar to the DrupalEmphasis plugin except it runs attributeToAttribute on init()
Running into a js warning currently "Failed to load horizontalLine - HorizontalLine", but I believe the approach is solid, taking the recommendation from the ckeditor community and applying it with Drupal's ckeditor methodology.
This works, marking as reviewed.
Looking at a related ckeditor issue they offered a work around.
editor.model.schema.extend( 'horizontalLine', { allowAttributes: [ 'hrClass' ] } )
editor.conversion.attributeToAttribute( {
model: 'hrClass',
view: 'class'
} );
Could this be implemented in Drupal?
As of 4.3 this hook has been removed in favor of using event subscribers.
Subscribe to the Drupal\search_api_solr\Event\SearchApiSolrEvents::POST_CREATE_INDEX_DOCUMENT event instead.
As of 4.3 this hook has been removed in favor of using event subscribers.
See
https://www.drupal.org/project/search_api_solr/issues/3254486#comment-14...
📌
Move and revise code examples from hooks to events
Active
I ran into this on 2.x, updated version and reopened, steps to reproduce:
- Add an untrusted role
- Delete that role
- Run drush security-review
Can confirm this works
Can confirm patch works, no longer can be sure of problematic markup since it's been said that ckeditor fixes it with this patch
This tests out great and provides helpful link in warning message.
This should work before or after explode and loop over the array if after. How does tamper normally handle multiple values? Should this be handled in the tamper module and it loop over values if there are multiple?
Patch #273 tests good
Attaching a patch for the entity_clone module that can be used in combination with @sun-fire's patch here to achieve D10 compatibility. Overriding the entity form class could be done in this module to avoid having to patch entity clone, so I'm leaving this as needs work until that is accomplished in this module.
On a D10 site with translations I get the following error cloning a menu item:
InvalidArgumentException: Field status is unknown. in Drupal\Core\Entity\ContentEntityBase->getTranslatedField() (line 583 of core/lib/Drupal/Core/Entity/ContentEntityBase.php).
It appears ckeditor 5 has Image Resize capability, and adding it might just take changing some settings in the media and image plugins.
The methodology in Media Embed Extra is flawed enough that I would hesitate to reference it.
Pushed a fix for this based on linked docs
Opened merge request
Pushed a fix removing the template file and theme hook and opened a merge request
Do you have 3.2 for menu_link_clone?
Thanks for the patch!
Including snippets for composer.json that can be used to update for D10 compatability before this gets merged in:
In "repositories" above the default one:
{
"type": "package",
"package": {
"name": "drupal/ckeditor_responsive_plugin",
"type": "drupal-module",
"version": "dev-3334636-create-new-version",
"source": {
"type": "git",
"url": "https://git.drupalcode.org/issue/ckeditor_responsive_plugin-3334636.git",
"reference": "3334636-create-new-version"
}
}
},
And update the constraint to
"drupal/ckeditor_responsive_plugin": "dev-3334636-create-new-version",
Looks like a slightly different equivalent of this ended up making it into 3.2.
Patch no longer applies as it's been replicated, think this can be closed.
@Sun-fire thanks for the patch!
I added it to the issue fork on 3347898-drupal-10 branch and only modified it to fit with the .info format there.
To use to make the module compatible with D10 via composer add the following to "repositories" above the default ones:
{
"type": "package",
"package": {
"name": "drupal/menu_link_clone",
"type": "drupal-module",
"version": "dev-3347898-drupal-10",
"source": {
"type": "git",
"url": "https://git.drupalcode.org/issue/menu_link_clone-3347898.git",
"reference": "3347898-drupal-10"
}
}
},
And set the version constraint to:
"drupal/menu_link_clone": "dev-3347898-drupal-10",
And run
composer update drupal/menu_link_clone
@TipiT It's possible to encrypt usernames, the default username field could be autofilled and hidden and optionally an encrypted psudo-username field added. This patch just gets it to work on the default username field. And I don't think GDPR applies here, my understanding is that only requires consent for data storage as opposed to encryption.
Added as issue fork so that the patch can be added via composer for D10 compatibility because patches get applied after version constraint checks. This can be applied using the following addition to the repositories key (above default ones) in composer.json:
{
"type": "package",
"package": {
"name": "drupal/domain_language_negotiation",
"type": "drupal-module",
"version": "dev-3296976-automated-drupal-10",
"source": {
"type": "git",
"url": "https://git.drupalcode.org/issue/domain_language_negotiation-3296976.git",
"reference": "domain_language_negotiation-3296976"
}
}
},
And then the following constraint:
"drupal/domain_language_negotiation": "dev-3296976-automated-drupal-10",