joachim namyslo → credited pasqualle → .
By default Gin theme should only care about core functionality. Everything else should be easily configurable or extendable.
In this case you can do this as:
/**
* Implements hook_gin_content_form_routes().
*/
function mymodule_gin_content_form_routes() {
return [
'entity.commerce_product.add_form',
'entity.commerce_product.edit_form',
'entity.commerce_product_variation.add_form',
'entity.commerce_product_variation.edit_form',
'entity.commerce_product.content_translation_add',
'entity.commerce_product_variation.content_translation_add',
];
}
or move the issue to commerce to make sure all commerce forms work correctly with Gin theme.
Pasqualle → created an issue.
outdated
outdated
outdated
outdated
Drupal 11 compatibility resolved in 5.0.x branch
https://git.drupalcode.org/project/box/-/commit/2ec87bc9a381c95a82d1e0c0...
Fixed 🐛 Same item added to the queue multiple times Active
Pasqualle → created an issue.
Fixed same field name in different entity types
It should NOT be at module install, and it should only be done for enabled fields (by entity_reference_purger).
1. check the field table for missing references
2. tell entity_reference_purger that those references are deleted
3. show how many items were removed and/or how many added to a queue
example:
1. Query like this needs to be done using field and database api (for all enabled fields)
"
SELECT DISTINCT(field_my_media_items_target_id)
FROM `node__field_my_media_items`
WHERE field_my_media_items_target_id not in
(select mid from media);"
2. call function entity_reference_purger_purge_by_entity_properties('media', $entity_id) where entity_id is a missing media id
see
📌
refactor entity_reference_purger_entity_delete() for readability
Needs review
Fixed wrong entity_type_id
- moved the functionality to get list of field definitions into a separate function
- created new api functions entity_reference_purger_purge_by_entity(), entity_reference_purger_purge_by_entity_properties(), which can be used to remove existing orphaned references
- created function entity_reference_purger_purge_items, to remove code duplication
- added hook hook_post_entity_reference_purge to be able to act on purged references
- improved code style regarding boolean handling
Same problem when the first item is moved/reordered. The item[0] is highlighted as required even it is not the first on the list.
Pasqualle → made their first commit to this issue’s fork.
Pasqualle → created an issue.
Why this is "won't fix". Should not it be in the postponed state until paragraphs supports Drupal 11?
Pasqualle → created an issue.
Ok, found the source of the problem.
<* style> vs <* style="width height">
This check here:
FundamentalCompatibilityConstraintValidator.php#L158
creates a diff between
$provided->elements[*][style] = TRUE
$allowed->elements[*][style][width => TRUE, height => TRUE]and shows the error
🐛
FilterHtml accepts <*> but does not support it, resulting in inaccurate ::getHtmlRestrictions() return value
Needs work
seems a bit related, but does not solve the <* style> error.
Need reroll for 10.2
The problem is not related to multilingual.
The problem is that the <* style> element is not part of the generated allowed html values.
Enabling the extended html filter (with this patch) on a multilingual site:
Error message
The current CKEditor 5 build requires the following elements and attributes:
<br> <p> <* style dir="ltr rtl" lang>
The following elements are missing:
<* style>Not sure why this ticket was created, but it is a duplicate of 📌 Automated Drupal 10 compatibility fixes Needs review
I am a bit confused. The project page says: "HTML email can be sent by adding Drupal Symfony Mailer". If it works with symfony mailer why do we have this issue open?
Pasqualle → created an issue.
Dropping D8 support and versioning is not the same issue.
Who is still using Drupal 8, do not need any updates of this module. They need a Drupal core update.
Pasqualle → created an issue.
Pasqualle → made their first commit to this issue’s fork.
Pasqualle → created an issue.
Just use https://github.com/mglaman/composer-drupal-lenient composer plugin to install any Drupal 9 module under Drupal 10. Then use https://github.com/cweagans/composer-patches to install the necessary patch or MR.
Both plugins are on packagist, so they can be installed with a simple composer require command.
The issue was originally created because of admin confusion seeing TFA.
Is it worth replacing TFA with 2FA in a module whose machine name is tfa?
Is it worth renaming the module to fix the displayed text?
I am trying to understand this change. As I understand from the tests, on a multilingual site the config can be only edited in the source language.
So if the site default language is Hungarian, then the developer will have to edit the configs in Hungarian, even if he does not speak Hungarian. Maybe I should test the patch, as that can't be true.
Wide text is harder to read.
I would like to see a code comment example where this is true.
Pasqualle → created an issue.
Pasqualle → created an issue.
The composer.json file needs to be updated also. The "symfony/dependency-injection" package version constraint is outdated.
Should entity_embed work with the "Limit allowed HTML tags and correct faulty HTML" filter? The embedded entity is not displayed when I have that filter enabled.
Pasqualle → created an issue.
The argument should have been made optional to avoid any upgrade issue.
In groups.services.yml add an extra "?" to the group_permission.calculator service argument, like:
group_permission.calculator:
class: 'Drupal\group\Access\GroupPermissionCalculator'
arguments: ['@?flexible_permissions.chain_calculator']
see: https://symfony.com/doc/current/service_container/optional_dependencies....
This should allow to enable flexible_permissions module while having this error.
Pasqualle → created an issue.
Pasqualle → created an issue.
Pasqualle → created an issue.
I am thinking of simple square brackets for using a class instead of style color in field widget.
for example:
info|Info/[has-background-info]
success|Success/[has-background-success]
warning|Warning/[has-background-warning]
danger|Error/[has-background-danger]
Pasqualle → made their first commit to this issue’s fork.
Pasqualle → created an issue.
Duplicate of 🐛 $this used inside static function Fixed
Pasqualle → created an issue.
Pasqualle → created an issue.
Pasqualle → created an issue.
It seems implementing hook_gin_content_form_routes() solves the problem.
Please register all the new routes with this hook.
As a quick workaround, the hook can be used in a custom module as:
function mymodule_gin_content_form_routes() {
return [
'entity.node.edit_form.myformmode',
];
}
Pasqualle → created an issue.
Pasqualle → created an issue.
I have a question about entity collection listing: Is there a guideline, policy or d.o issue about where the entity list should go in the admin menu?
something like:
- if you extend the ContentEntity class, then your entity listing should be under admin/content/my-entity-plural
- if you extend the ConfigEntity class, then your entity listing should be under admin/structure/my-entity-plural
Some of the examples where this "guideline" does not apply:
Shortcuts (ContentEntity from core) listing is under /admin/config/user-interface/shortcut
Taxonomy terms (ContentEntity from core) listing is under /admin/structure/taxonomy/manage/%vocabulary%/overview
Image styles (ConfigEntity from core) listing is under admin/config/media/image-styles
Workflows (ConfigEntity from core) listing is under admin/config/workflow/workflows
Languages (ConfigEntity from core) listing is under admin/config/regional/language
Entity Browsers (ConfigEntity from entity_browser module) listing is under admin/config/content/entity_browser
Newsletters (ConfigEntity from simplenews module) listing is under /admin/config/services/simplenews
QRCodes (ContentEntity from qrcode module) listing is under /admin/config/services/qrcode
Pasqualle → created an issue.
Pasqualle → created an issue.
thank you
Pasqualle → created an issue.
Pasqualle → created an issue.
The button background introduced a problem in Gin theme
🐛
Dropbutton style issue after Claro update
Fixed
Pasqualle → created an issue.
reroll
Not necessarily.
By default, the config listing should use the language which makes more sense for the site. The current behaviour "without override" or the new "with override" option. If the current language does not work for some users, then those users should have the option to change the current language with the language switcher.
Not sure about your use case, but if there is a need for more granular setting, then I would prefer the option to be "per list". Like most of the config lists can be displayed with override, but the date formats are displayed without override (as that was the original issue when the config listing behaviour was changed).
Maybe there could be a switch to on every config listing to show the list with or without overrides.
The solution described on the lullabot website does not work with Drupal 10.
#2768219: Per-table prefixes deprecated →
D.o still uses bakery, but will be replaced at the upgrade.
#3338978: Replace Bakery with KeyCloak SSO & social sign on →
The patch does not apply
The patch does not apply to latest 2.x-dev.
Pasqualle → created an issue.
Hi, I have checked the patch, and compared with #3143065: Default config hash is not generated for imported configuration (config_provider) →
In Configuration Provider module → the default config hash is only set when it has no value, see addDefaultConfigHash() function.
In this patch we always set the "_core" and the "default_config_hash" properties.
I am not sure if the default_config_hash should be updated at import/revert, this needs to be discussed.
The "_core" property should not be overwritten, as it might have other properties (in the future).
related read:
https://www.drupal.org/node/2653358 →
https://www.drupal.org/project/drupal/issues/2656370
📌
Create a method to discover if configuration matches the shipped configuration
Needs work
I see one issue with this change. Bug reports filed against the "main" version are not really helpful. If the reporter does not specify a version, then it needs extra work to figure out which versions might be affected by the bug.
I guess you need to create the dev release first, which should be available here:
https://www.drupal.org/node/add/project-release/2864947 →
Pasqualle → created an issue.
Yes, you are right on both cases. The major can be 0 and the pre-release tag can be almost anything.
But,
- some automated tools do not recommend using 0 as major, you might have problems with those.
And the real life issue with that: https://www.youtube.com/watch?v=tc2UgG5L7WM&t=412s
- in semver2 the pre-release tag order is specified as
Precedence for two pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier from left to right until a difference is found as follows:
- Identifiers consisting of only digits are compared numerically.
- Identifiers with letters or hyphens are compared lexically in ASCII sort order.
...
That means in semver2: 1.0.0-beta9 > 1.0.0-beta10. Our current pre-release tag order is wrong by semver2.
I have run into an error when using $entity->original in hook_node_presave() with this patch ("Edit form" option).
Pasqualle → created an issue.