Rerolled existing patch code against current 8.x-2.x-dev, based on 2.0.0-beta16.
The patch in #6 is a good working solution for the described issue. Tested in version 3.0.3 of scheduler.
We have the exact same issue. Only our transitions still exist. It's some nodes that have an unpublish_state (from scheduler_content_moderation_integration) which contains NULL for an unknown reason. That results in many many revisions.
Whether or not this is reproducable, the issue remains that when -1 is returned in hook_scheduler_publish_process(), the entity is still saved. You can always test this issue by forcing the entity to have an unpublish_state with value NULL, for example setting that value in hook_node_presave() for every node.
Patch against 1.x-dev to fix deprecation notices.
Rerolled patch against 2.1.x-dev.
Rerolled patch against current 2.1.x-dev.
This is solely CSS theming. Adding a border radius and box shadow to the product teaser. A front end developer should be able to create this style of product card.
Thank you for reporting this. I released version 3.0.1 to address this issue.
No further issues. Setting status to Fixed.
No further issues. Setting status to Fixed.
Oh.. Totally my bad. I was mistaken indeed! Closing the issue.
I think this module can roll out a stable D11 version?
Drupal 11 support added in version 2 of this module. Keeping the issue open to allow the Project Update Bot to post additional Drupal 11 compatibility fixes as they become available in Drupal Rector.
Drupal 11 support added to version 3.x.x.
Drupal 9 support has been dropped.
Leaving this issue open as suggested by "Project Update Bot" for possible additional Drupal 11 compatibility fixes as they become available in Drupal Rector.
This long route makes this feature basically unusable. Fatal errors popping up all over the website due to this long route. Any updates on this?
It's hard to make a webmaster use base:... in all kinds of places on the website. However, thanks for this workaround.
Creation of dynamic properties is deprecated since PHP 8.2 and will throw a fatal error as from PHP 9.0.
You can let the class opt in by using the #[\AllowDynamicProperties] attribute as a temp fix.
The same notice is thrown for Drupal\facets\Result\Result::$termWeight.
This can be caused by misconfigured imagemagick executable path, see /admin/config/media/image-toolkit.
Issue still occurs when trying to use the batch update. Using version 8.x-2.0-beta12 and Drupal core 10.2.4.
Created patch from current MR and updated it so the form change listener is not initiated when manual checking is enabled. This way the change on the "focus keyword" is ignored. See comment #26. Feel free to add this to the MR.
Noting that this issue is already fixed in version 2 of this module. However this could still be merged into version 1.x.
Tested patch #7 and confirming it works.
RTBC +1
Can this be merged? The explanation is valid and the patch works.
RTBC +1
As the renderer service isn't actually used in this class, I removed it altogether. See patch.
I fixed the patch to work with the Paragraphs (stable) widget and Drupal 10. The latter can be tricky because this module supports multiple Drupal versions. However, the used hook hook_field_widget_complete_WIDGET_TYPE_form_alter is a new one for Drupal 10 only and replaces hook_field_widget_multivalue_WIDGET_TYPE_form_alter().
So if older Drupal versions need to be supported, the hook hook_field_widget_multivalue_WIDGET_TYPE_form_alter() needs to be added again as well, containing the same code.
Note that this patch was not written for the legacy paragraphs widget. I haven't tested that.
I can confirm patch #11 is not working when you use a modal (paragraphs stable widget) to add a paragraph.
I'm looking in to this. I think it sucks when an editor puts in all the effort to build up a page to see tons of errors when saving.
This should probably be handled in core at the point where constraints are processed and the error messages are set in the form.
Though, I made a patch where, for the time being (which could still be a long time), the constraint messages are also set as a message at the top of the page.
I think this is mostly an issue when editing pages that violate constraints which didn't exist before and are newly added to the field (for example limited paragraphs that weren't limited before).
Patch fixing the error.
Thank you for elaborating.
I had the same issue and even setting the permission right in the View, still didn't work.
Solution: there appeared to be 2 Views "Scheduled content" and "Scheduled content revisions" having the same path /admin/content/scheduled. The latter was still configured with the wrong access rule.
The patch in #155 🐛 Right click should not submit buttons with Ajax behaviors Needs work causes the following bug:
When using paragraphs and using the Modal in the widget to add new paragraphs, the modal closes "on click" when trying to hit a paragraph button to add. So before the button is clicked to trigger the ajax, the modal closes.
Found the issue. It was the core patch mentioned here: https://www.drupal.org/project/drupal/issues/2616184#comment-15402496 🐛 Right click should not submit buttons with Ajax behaviors Needs work
Thank you for the quick reply.
Closing this issue.
Thank you for trying it out. I figured so far that the modal is effectively closing on "click" (mouse down) before a button is actually hit. The buttons do work when I focus on them and hit Enter. I'm trying to find out what is happening.
I had to install a Fresh Drupal instance to figure out what core is using to establish a video_embed_field alternative. Older Drupal installations don't automatically have this "Remote video" media.
For anyone wondering how core works:
Core is using a plain text field type combined with the oEmbed URL field widget and oEmbed content field formatter. Also, this only works on Media entities of source type "Remote video".
So if you need to create a "core video embed field": create a new Media type with media source "Remote video" and add at least a plain text field for the video embed url with the mentioned field widget and formatter. Afterwards add a media reference field using "Remote video" media on the node type (or any other entity type) where the video_embed_field used to be.
(if I missed this obvious information, that would be my bad)
This would be incredibly useful. I second this.
For people encountering this problem: This can also be fixed without the patch and instead add a custom text format filter in your custom module.
my_module/src/Plugin/Filter/AnchorFilter.php
namespace Drupal\my_module\Plugin\Filter;
use Drupal\Component\Utility\Html;
use Drupal\filter\FilterProcessResult;
use Drupal\filter\Plugin\FilterBase;
/**
* Custom text format filter to fix anchor id's with spaces.
*
* This will:
* - Replace spaces in anchor link ID's by hyphens (-).
* - Add unique postfix when link IDs are duplicated on a page.
*
* @Filter(
* id = "filter_anchor",
* title = @Translation("Anchor Filter"),
* description = @Translation("Help this text format fix id's with spaces between"),
* type = Drupal\filter\Plugin\FilterInterface::TYPE_TRANSFORM_IRREVERSIBLE,
* )
*/
final class AnchorFilter extends FilterBase {
/**
* Creates unique ids for each anchor link.
*/
public function process($text, $langcode): FilterProcessResult {
$dom = Html::load($text);
$links = $dom->getElementsByTagName('a');
/** @var \DOMElement $link */
foreach ($links as $link) {
$this->cleanLinkId($link);
}
return new FilterProcessResult(Html::serialize($dom));
}
/**
* Cleanup given link DOM Element.
*
* This will clean the ID only when:
* - Link is not a normal link (with href).
* - Link has ID.
* - Unique ID will be generated from link ID.
*
* @param \DOMElement $link
* The link element.
*/
private function cleanLinkId(\DOMElement $link): void {
if (!empty($link->getAttribute('href'))) {
return;
}
$linkId = $link->getAttribute('id');
if (!$linkId) {
return;
}
$link->setAttribute(
'id',
Html::getUniqueId($linkId)
);
}
}
Enable this filter in your respective text formats.
Fernly → created an issue.
Reroll of patch 24 against current 8.x-2.x-dev version (should work on 8.x-2.10).
Thanks for the improvement. Merged.
Patch providing the composer.libraries.json file.
The latest MR version worked for me.
If anyone else encounters this. Using new TranslatableMarkup() instead of t() in your code fixes this issue as well.
Rerolled patch for Drupal 10
Updated patch since MR changes.
This patch introduces a new bug with D10. See this facets issue fixing the same bug: Drupal 10: InputBag::get() may no longer return an array in Symfony 6
Rerolling the patch against 1.x-dev.
I understand what you're saying and I can relate.
We just weren't sure the module was still maintained and were trying to get things done. Mission accomplished ;-).
Leaving it Postponed is perfect in that case.
Thanks for your time!
Understandable and no problem for me. Glad to see there is a stable D10 version. Thanks for that.
I don't have time at the moment to proof my worthiness, so this issue can be closed as far as I'm concerned.
Hopefully it doens't really take 2 years to get traction in the issue queue though ;-). But I understand there isn't always time to spare.
Kind regards,
Lennart
Isn't Visibility Groups → a solution for this and instantly fix this issue?
I requested co-maintainership in this issue 💬 Offering to co-maintain Condition Query Active .
For people blocked by this, take a look at Lenient → . It allows to break the version constraint of modules not yet released for Drupal 10. You can install the incompatible modules using composer and apply a Drupal 10 patch. It's a temporary solution until they get a stable D10 release.
For future reference: the path validation was added to Drupal 10.1.x in the following commit: https://git.drupalcode.org/project/drupal/-/commit/e47f5e759b92fb04156b2...
The validation has been extended in this module in order to fix this.
You're welcome. I couldn't bear the thought the module wasn't working properly anymore!
Apparently Drupal core added extra validation in the meanwhile which was too strict for this module.
Thank you for reporting. The issue is fixed in version 2.0.2.
Works like a charm. Setting to RTBC.
Fixed in version 2.0.1.
+1 on patch #28, fixes the problem.
Patch against 2.0.x branch.
Patch against 2.x dev branch.
Patch rerolled against 10.1.x.
@ TrevorBradley the patch struggle is real ;-)
For anyone wondering, patch #12 works against version 1.0.0-alpha3 (that is not latest dev, but the alpha3 version). I, for one, prefer alpha over dev.
RTBC +1
Rerolled patch against 2.1.x. Drupal 10 compatible.
Rerolled patch against 2.1.x. Drupal 10 compatible.
+ 1 for releasing D10 version.
I would recommend the maintainer to close this issue if confirmed that the fix is included in 6.x. The failing patch does not need to be merged anymore.
I am under the impression that the latest patch #31 to fix the notice is already included in 6.x. Setting this issue to RTBC. Perhaps others can confirm this before closing this issue.
If anyone says "thank you, it works", please also mention what patch you used on which version. Thanks!
RTBC +1, please merge and release the D10 stable version.
This has been fixed in Drupal 10, as you can see here.
This ticket can be closed soon.
Updated patch since MR changes.