guardiola86 → created an issue.
Patch in 21 works with 4.2.6. It also hide the element "Selected X items"
guardiola86 → created an issue.
guardiola86 → created an issue.
guardiola86 → created an issue.
Using the module "Views Content Moderation Current State" worked for me.
I'm having the same issue, it always displays as published in a view.
guardiola86 → created an issue.
Patch in #22 works for me.
The issue happens when adding emojis in the meta description apparently. Not sure if that's fixed in version 2.x.
guardiola86 → created an issue.
guardiola86 → created an issue.
guardiola86 → created an issue.
I tried using Block Class module and didn't work for me. My issue was that I couldn't use the same validate and submit functions that were working in the block edit page, but not when using layout builder. I ended up using something like this:
/**
* Implements hook_entity_insert().
*/
function embeddocument_block_entity_insert(EntityInterface $entity) {
_embeddocument_block_entity_insert_or_update($entity);
}
/**
* Implements hook_entity_update().
*/
function embeddocument_block_entity_update(EntityInterface $entity) {
_embeddocument_block_entity_insert_or_update($entity);
}
/**
* Custom callback used by insert and update.
*
* @param $entity
* @throws \Drupal\Core\Entity\EntityStorageException
*/
function _embeddocument_block_entity_insert_or_update($entity) {
if (\Drupal::moduleHandler()->moduleExists('block_content')) {
$entity_langcode = $entity->get('langcode')->value;
if ($entity->bundle() == 'document') {
$entity_array = $entity->toArray();
if (isset($entity_array['field_documents'])) {
$mid = $entity_array['field_documents'][0]['target_id'];
if (!empty($mid) && !empty($entity_langcode)) {
$media = Media::load($mid);
// If translation doesn't exist, create it.
if (!$media->hasTranslation($entity_langcode)) {
$media->addTranslation($entity_langcode, $media->toArray());
}
$media->save();
}
}
}
}
}
I'm having the same issue but I still haven't found a solution
Tested and it's working fine
guardiola86 → created an issue.
guardiola86 → created an issue.
I had the setting "'Do nothing. Leave the old alias intact.'" enabled, yet it was creating new aliases when changing the title.
guardiola86 → created an issue.
@anneke_vde if I create a content, it generates an alias. If I edit again, the checkbox "Generate automatic URL alias" is checked, although it doesn't generate URLs with '-0' at the end. But if you change the title, the alias is updated.
In my case, I need the alias to stay the same, even if I change the title.
Sorry, just saw you published one patch anneke_vde, I'll give it a try.
This patch checks if there's an existing alias for the domain id. If there's already one, "Generate automatic URL" will be disabled.
Actually, that didn't work. I'm now using dev, pointing to commit d5b61749820c0838b5fec7605f402041421cf72e . That commit is the last one as well in 8.x-1.2, so it's a bit strange that the patch doesn't apply.
Neither the patch nor the merge request diff is working for me. I'm adding a new patch.
The latest merge request patch didn't work for me with version 5.2.3, so I'm using dev version with the latest commit for now.
This patch did not work for me, still says:
drupal/swiftmailer[dev-2.x, 2.4.0] require egulias/email-validator ^2.0||^3
This was for a Drupal 8 site that I'm still managing, in case it's useful for anyone. I had to restrict the "redirect when deleting an element from the cart" to a specific domain.
Important: when configuring the condition, use domain id, not domain name.
guardiola86 → created an issue.
Here's a patch updated for 1.x, I've replaced deprecated function drupal_get_path
actually it works, but it breaks this page on submit: /admin/config/content/entityprint
entity-print-2733781-export-word-72.patch isn't working for me, I get this error:
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "Array" plugin does not exist. Valid plugin IDs for Drupal\entity_print\Plugin\EntityPrintPluginManager are: tcpdfv1, phpwkhtmltopdf, dompdf, word_docx in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of /var/www/html/docroot/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).
It is not working for me, links still appear in all domains
It's been a while since I did the patch, but I think it doesn't need an update hook.
Actually, that happens if I try to create a normal view and add a relationship. If I create a new view, using the new type, it works.
guardiola86 → created an issue.
There is an issue with domains when using drush. I've been debugging and the urls are sometimes mixed, that's why sometimes in a sitemap appear base urls of other domains, not the current site one.
I've made a patch to at least stop that from happening, but probably there's a better fix for that.
I'm reopening this because I don't think it's a duplicate.
I'm having the same issue, works in the UI but not in drush
Saving the field didn't work for me
guardiola86 → created an issue.
guardiola86 → created an issue.
guardiola86 → created an issue.
Here's another patch but is not complete yet, I will probably use another module for now.
Currently I can only add one sitemap and I would need 2 in my case. It will also need to filter by domain when indexing.
I'm having the same issue, I have two domains and that's causing both domains to appear in sitemap.
Thanks TravisCarden!
This is not working for me, I'm using version 1.0-beta8 of the module.
guardiola86 → created an issue.
guardiola86 → created an issue.
guardiola86 → created an issue.
This seems to be related? https://www.drupal.org/project/password_policy/issues/3325587 ✨ Revenge of password_policy_update_8302 takes too long for a large amount of users Needs review
I can see this is now included in 4.0.x with some changes
I don't know exactly what causes the issue, but sometimes $this->getEntity($values) is null. I've created a patch that checks if it's null so at least the page can be accessed. In my case it's happening on admin/content
guardiola86 → made their first commit to this issue’s fork.
Better, thanks.
guardiola86 → created an issue.
Patch doesn't apply to 1.14.0, but it does to version 1.13.0
In this patch, I'm just updating the file description so the user knows the file name must be the same.
So this works, thanks, but I'm just wondering if we should add a message saying that the file name should be the same or it won't be replaced?
I ended up using this module: https://www.drupal.org/project/imageapi_optimize_webp → , which works like a charm with responsive image styles.
guardiola86 → created an issue.