firewaller → created an issue.
firewaller → created an issue.
I don't want to reopen this, but I did want to post the re-rolled patch for 3.3. I know the module maintainer doesn't want to support this and I understand why, but in case this is a blocking issue for anybody else I figured I'd upload it.
There was a regression found in the about code where expected URL params weren't being considered in the cache key.
The latest change has been verified, thanks!
The latest MR changes are working for us.
#41 works for me
FWIW this patch resolved the error for us and is still in use. Specifically with the Dynamic Entity Reference and Paragraphs module.
These latest changes work resolve the followup issue for us.
Patch #3 works for us
rp7 → credited firewaller → .
We've created and MR with the requested change that splits the query params into entry sets with a URL that supports wildcards.
firewaller → made their first commit to this issue’s fork.
At the very least the condition to check "external" should be considered in \Drupal\Core\Asset\CssCollectionOptimizerLazy::optimizeGroup calls
Patch #2 works for us
New option for Views page displays to use the admin theme ✨ New option for Views page displays to use the admin theme Fixed was merged to 10.1.x back in 2023.
I've added the config change to the module view against 3.3.x
Please note, if you've already exported the config locally you may need to make the same change to you config manually.
Fixed the related issue/tag.
This seems to be a duplicate of Unified layout(admin theme) in all tabs →
I agree actually. I don't want to cover the issue up. I just wanted to fix the partial reroll from #38, but I'm all ears for suggestions to identify these invalid modules/libraries.
I just realized that patch #38 wasn't a complete reroll of the previously working patch for #31. I've rerolled #31 for 10.3
This should just bypass the warning, but it doesn't resolve the underlying issue which I think should be addressed in this issue or a followup issue.
We've been seeing this issue for months since the upgrade. There is no indication of which module or library is being incorrectly called, so I agree with @eduardo-morales-alberti that the messaging needs to be updated or a separate log needs to be added. Is there any tool or mechanism for identifying the incorrect module or library?
The latest MR patch has been working for us for some time now.
My above rerolled patch for 9.1.1 is invalid. I've re-uploaded a working version.
Attached is a rerolled patch for 9.1.1 without the unnecessary composer change that causing a conflict.
firewaller → created an issue.
Rerolled for 9.1
Specifically, commenting out the code here so `$patternkit_blocks` is always an empty array: https://git.drupalcode.org/project/patternkit/-/blob/9.1.x/src/Plugin/De...
firewaller → created an issue.
firewaller → created an issue.
+1
+1
Patch #21 fixed the issues I was having. I would strongly request that this issue get reopened since the module is nearly unusable without this fix.
The patch from the MR looks good and resolves this issue for us.
Patch for 8.x-1.17 attached.
FYI this patch applies to 8.x-1.17 but introduces a regression when viewing the node's Translation Jobs tab:
Error: Class "Drupal\tmgmt\Entity\ListBuilder\Url" not found in Drupal\tmgmt\Entity\ListBuilder\JobListBuilder->getDefaultOperations() (line 41 of /opt/app-root/src/web/modules/contrib/tmgmt/src/Entity/ListBuilder/JobListBuilder.php).
I will reroll a new patch.
FYI this is a D10.3 compatibility issue. Please create a `/config/schema/MODULE_NAME.schema.yml` file similar to the ones implemented in these modules:
- https://www.drupal.org/project/token_filter/issues/3456459 🐛 'replace_empty' is not a supported key. Fixed
- https://www.drupal.org/project/responsivewrappers/issues/3479851 🐛 Config Schema for filter plugin Active
This is great! Some suggestions to make it more viable:
- Add an "Invert" checkbox to deny/allow the listed cache tags dynamically
- Add URL groups to deny/allow cache tags for specific pages
- Use wildcard character instead of "contains" functionality for more granular control
Patch #48 resolves the issue for us
Patch #2 works for us, but I agree updating from opt-out to opt-in is ideal.
Patch from #39 works for us
Patch from MR !12 works for us
Patch #2 works for us
+1
If there are different use-cases based on setup does it make sense to add config to optionally enable the reset functionality? I'd be concerned about relying on the provider itself since that may be up to the individual site instead.
slucero → credited firewaller → .
We're seeing this too. Its odd that it would skip "minified" but not "preprocess = false" here if the optimize function is just going to throw an exception for "preprocess = false": https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...
The hook introduced here ran on my site with 10.2.7 with no effect due to the condition. It won't run after I install 10.3 now, so will I have to remember to remove it manually?
This doesn't work without both "Provide Translated External Link" & "Translated Link" enabled for translation. The documentation should be changed to:
Include "Provide Translated External Link" & "Translated Link" to be translated.
FYI I was able to override this the core revert forms to enforce draft on new revisions by:
- Copying and renaming the "node.revision_revert_confirm" and "node.revision_revert_translation_confirm" routes from core's node.routing.yml to "MY_MODULE.node.revision_revert_confirm" and "MY_MODULE.node.revision_revert_translation_confirm"
- Creating a new file to extend the first class from the routes above here: /web/modules/custom/MY_MODULE/src/Form/NodeRevisionRevertForm.php
- Creating a new file to extend the second class from the routes above here: /web/modules/custom/MY_MODULE/src/Form/NodeRevisionRevertTranslationForm.php
- Overriding the route with the above new classes here: /web/modules/custom/MY_MODULE/src/Routing/RouteSubscriber.php
- Clearing caches
NodeRevisionArchiveForm.php:
<?php
namespace Drupal\MY_MODULE\Form;
use Drupal\Core\Form\FormStateInterface;
use Drupal\node\NodeInterface;
use Drupal\node\Form\NodeRevisionRevertForm as NodeRevisionRevertCoreForm;
/**
* Provides a form for reverting a node revision.
*
* @internal
*/
class NodeRevisionRevertForm extends NodeRevisionRevertCoreForm {
/**
* Prepares a revision to be reverted.
*
* @param \Drupal\node\NodeInterface $revision
* The revision to be reverted.
* @param \Drupal\Core\Form\FormStateInterface $form_state
* The current state of the form.
*
* @return \Drupal\node\NodeInterface
* The prepared revision ready to be stored.
*/
protected function prepareRevertedRevision(NodeInterface $revision, FormStateInterface $form_state) {
$revision = $this->enforceModerationState($revision, $form_state);
return parent::prepareRevertedRevision($revision, $form_state);
}
/**
* Enforce moderation state for a revision.
*
* @param \Drupal\node\NodeInterface $revision
* The revision to be reverted.
* @param \Drupal\Core\Form\FormStateInterface $form_state
* The current state of the form.
* @param string $state
* The moderation state to enforce.
*
* @return \Drupal\node\NodeInterface
* The prepared revision ready to be stored.
*/
public function enforceModerationState(NodeInterface $revision, FormStateInterface $form_state, string $state = 'draft'): NodeInterface {
if ($revision->hasField('moderation_state')) {
$revision->set('moderation_state', $state);
}
return $revision;
}
}
NodeRevisionRevertTranslationForm.php:
<?php
namespace Drupal\MY_MODULE\Form;
use Drupal\Core\Form\FormStateInterface;
use Drupal\node\NodeInterface;
use Drupal\node\Form\NodeRevisionRevertTranslationForm as NodeRevisionRevertTranslationCoreForm;
/**
* Provides a form for reverting a node revision for a single translation.
*
* @internal
*/
class NodeRevisionRevertTranslationForm extends NodeRevisionRevertTranslationCoreForm {
/**
* {@inheritdoc}
*/
protected function prepareRevertedRevision(NodeInterface $revision, FormStateInterface $form_state) {
$revision = $this->enforceModerationState($revision, $form_state);
return parent::prepareRevertedRevision($revision, $form_state);
}
/**
* Enforce moderation state for a revision.
*
* @param \Drupal\node\NodeInterface $revision
* The revision to be reverted.
* @param \Drupal\Core\Form\FormStateInterface $form_state
* The current state of the form.
* @param string $state
* The moderation state to enforce.
*
* @return \Drupal\node\NodeInterface
* The prepared revision ready to be stored.
*/
public function enforceModerationState(NodeInterface $revision, FormStateInterface $form_state, string $state = 'draft'): NodeInterface {
if ($revision->hasField('moderation_state')) {
$revision->set('moderation_state', $state);
}
return $revision;
}
}
RouteSubscriber.php:
<?php
namespace Drupal\MY_MODULE\Routing;
use Drupal\Core\Routing\RouteSubscriberBase;
use Symfony\Component\Routing\RouteCollection;
/**
* Route subscriber to subscribe to route event.
*/
class RouteSubscriber extends RouteSubscriberBase {
/**
* {@inheritDoc}
*/
protected function alterRoutes(RouteCollection $collection) {
// Altering the node revert form.
if ($route = $collection->get('node.revision_revert_confirm')) {
$route->setDefault('_form', '\Drupal\MY_MODULE\Form\NodeRevisionRevertForm');
}
// Altering the node translation revert form.
if ($route = $collection->get('node.revision_revert_translation_confirm')) {
$route->setDefault('_form', '\Drupal\MY_MODULE\Form\NodeRevisionRevertTranslationForm');
}
}
}
+1
The patch on #3037259 fixed an issue with infinite redirects because of a trailing question mark (?).
The patch on #3037259 fixed an issue with infinite redirects because of a trailing question mark (?).
#35 fixed an issue with infinite redirects because of a trailing question mark (?).
+1
Patch #59 works for us
Patch #13 (tmgmt-reset-finished-job-button-3094355-9.patch) works for us
Patch #2 (3359495-error-when-importing-01.patch) works for us
Patch #18 (tab_issues-3208439-15.patch) works for us
Patch #4 works for us
Patch #3 works for us.
Patch #6 works for us.
Rerolled against latest 10.2.x
slucero → credited firewaller → .
+1
#9 works for me
#6 works for me
#12 works for me
#8 works for me
#6 works for me
#21 works for me
#8 works for me
#9 works for me
#7 works for me, thank you!
Yeah, #4 doesn't work for me on a fresh migration.
FYI that message is getting logged here: https://git.drupalcode.org/project/webform/-/blob/6.2.x/src/WebformSubmi...
Based on that logic above, the only way to silence these messages in CLI was to disable the "results_disabled" setting in each form temporarily. However, now I'm seeing the error from here: https://git.drupalcode.org/project/webform/-/blob/6.2.x/src/Plugin/Webfo...
That's caused by this logic: https://git.drupalcode.org/project/webform/-/blob/6.2.x/src/Plugin/Webfo...
So I don't think that's a viable approach either.
I think what's happening is if any of the conditions fail then the tag won't show up (i.e. you can't use both a positive node and a term condition). This logic likely needs to be revisited: https://git.drupalcode.org/project/google_tag/-/blob/2.0.x/src/TagContai...
@william.thomas.cox can you post your patch that fixed this?
This was driving me crazy when exporting config! The patch from #2 fixes this issue for me.
+1
Thanks, having that "webform" process mapping helped!
+1
Patch attached for 9.1.0-beta8. This excludes the hook_update to prevent conflicts with future hook updates. Please run drush cset patternkit.settings patternkit_json_editor_token_clear false -y
when using this specific patch.
firewaller → created an issue.
firewaller → created an issue. See original summary → .
Does it make sense to relocate this change to `\Drupal\Core\Asset\CssCollectionOptimizerLazy::optimizeGroup` similar to the JS approach? https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...
Thanks for confirming. I have validated that it was an incompatibility with the module_filter module as mentioned previously:
- https://www.drupal.org/project/filter_perms/issues/3123289#comment-13800364 →
- https://www.drupal.org/project/filter_perms/issues/2997536#comment-13906269 →
It appears that the module_filter patch mentioned above has been merged into the stable version and simply needed a config change via:
drush config:set module_filter.settings enabled_filters.permissions false -y
I appreciate the support!
After upgrading to Drupal core 10.1, this patch seems to be unnecessary.
As to whether this entire module is obsolete due to the core changes, for the most part yes, however this module does introduce certain permissions that don't seem to be covered by core (i.e. revert block_content BLOCK_TYPE revisions, view block_content BLOCK_TYPE history, and view block_content BLOCK_TYPE revisions).
firewaller → created an issue.
I refactored the above for D10:
/**
* Implements hook_entity_presave().
*/
function MY_MODULE_entity_presave(EntityInterface $entity): void {
// Skip if not file.
if (!$entity instanceof FileInterface) {
return;
}
// Migrate epsa crop to focal point.
$fid = $entity->id();
$migrate_database = Database::getConnection('default', 'migrate');
$query = $migrate_database->select('epsacrop_files', 'e');
$query->innerJoin('file_metadata', 'fmw', "fmw.fid = e.fid AND fmw.name = 'width'");
$query->innerJoin('file_metadata', 'fmh', "fmh.fid = e.fid AND fmh.name = 'height'");
$query->addField('e', 'coords');
$query->addField('fmw', 'value', 'width');
$query->addField('fmh', 'value', 'height');
$query->condition('e.fid', $fid);
$query->range(0, 1);
$results = $query->execute();
if ($results) {
/** @var \Drupal\focal_point\FocalPointManagerInterface $focal_point_manager */
$focal_point_manager = \Drupal::service('focal_point.manager');
$crop_type = \Drupal::config('focal_point.settings')->get('crop_type');
$crop = $focal_point_manager->getCropEntity($entity, $crop_type);
while ($record = $results->fetchAssoc()) {
$coords = unserialize($record['coords']);
$coords = Json::decode($coords);
if (isset($coords[$fid])) {
// Get first image style.
$coords = reset($coords[$fid]);
$focal_point_x = $coords['x'] + round($coords['w'] / 2);
$focal_point_y = $coords['y'] + round($coords['h'] / 2);
$width = unserialize($record['width']);
$height = unserialize($record['height']);
// Skip if invalid.
if (
$focal_point_x > $width ||
$focal_point_y > $height
) {
continue;
}
$relative = $focal_point_manager->absoluteToRelative($focal_point_x, $focal_point_y, $width, $height);
$x = $relative['x'];
$y = $relative['y'];
$focal_point = implode(',', $relative);
if (
$focal_point_manager->validateFocalPoint($focal_point) &&
$width &&
$height
) {
$focal_point_manager->saveCropEntity($x, $y, $width, $height, $crop);
}
}
}
}
}
All good, thanks!