Account created on 17 February 2011, over 13 years ago
#

Merge Requests

Recent comments

πŸ‡ΊπŸ‡ΈUnited States kerasai

I've come across this now on multiple instances. I've poked at it some, but am unable to determine the root cause. Adjusting the migration's dependencies in the YML doesn't seem to help.

Here's the error:

[error] Migration upgrade_d7_node_complete_webform did not meet the requirements. Missing migrations d7_file_plain_source_field:image, d7_file_plain_type:image, d7_file_plain_source_field_config:image, d7_file, d7_file_plain:image:public.

And that migration's dependencies:

migration_dependencies:
  required:
    - upgrade_d7_user
    - upgrade_d7_node_type
    - upgrade_d7_file_plain_image_public
  optional:
    - upgrade_d7_field_instance

I worked around it with a solution similar to #3194361-3: [migrate_upgrade] Migrate Upgrade, Migrate Tools and Migrate Commerce leads to dependency failure on media types β†’ .

Also, I'm confident that

πŸ‡ΊπŸ‡ΈUnited States kerasai

I'm curious as to what the issue is that this change is intended to fix.

Upgrading to the latest release (2.0.0-beta4) seems to work with core 10.1.8.

πŸ‡ΊπŸ‡ΈUnited States kerasai

Previous comment related the wrong issue, an old issue before the FileEntityDealer system was added.

Replaced with the intended related issue.

πŸ‡ΊπŸ‡ΈUnited States kerasai

Noting that this does in fact still seem to be an issue. I'm currently running into this.

Also found another recent report of the issue πŸ› Migrate Upgrade results in missing dependencies when running node_complete migrations Active , marked as related.

πŸ‡ΊπŸ‡ΈUnited States kerasai

kerasai β†’ made their first commit to this issue’s fork.

πŸ‡ΊπŸ‡ΈUnited States kerasai

The MR from #2 πŸ“Œ Drupal 10 Compatability - 2.x Branch Active allows this module to work as expected with Drupal 10.

Just a few code changes to address deprecated code, otherwise trivial changes to version restraints.

---

To add this via Composer:

    "repositories": [
        {
            "type": "vcs",
            "url": "https://git.drupalcode.org/issue/wistia-3436197.git"
        },
    ...
    ]

composer require drupal/wistia:dev-3436197-drupal-10-compatability

πŸ‡ΊπŸ‡ΈUnited States kerasai

kerasai β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States kerasai

Hi there, just curious if this is suspected to be an Acquia-only issue.

πŸ‡ΊπŸ‡ΈUnited States kerasai

Noting that this issue affects the 8.x-2.x branch (2.x version).

The same change (https://git.drupalcode.org/project/owl-carousel/-/commit/d575514541e9731...) applies to that branch and fixes the issue.

πŸ‡ΊπŸ‡ΈUnited States kerasai

This patch business is a bit baffling.

I'm running a Lando "drupal9" recipe on Ubuntu. The patch generated from the MR wouldn't apply to either the alpha2 or dev releases. No particular error or indication of what caused the issue, just "could not apply patch".

Assuming the composer patches use the underlying OS patch functionality, I am running the latest version of GNU patch 2.7.6. I've never had an issue such as this before.

Also note, the alpha2 and dev releases reference the same commit so I'd expect them to behave the same. If they do behave differently (for me they both failed) perhaps this is indicative of something going on with the Drupal.org packaging. Perhaps if adds a composer.json etc. to tagged releases and not for dev releases? I don't know that to be the case, just spitballing.

Solution

Not sure if there is a way to do this using the MR or some other functionality within the GitLab, but I ended up pulling the repo locally and made a patch from one of the previous commits.

git diff origin/8.x-1.x...42ca8c7e033607336b2cfcb1262815bfb1c06f99 > nodeviewcount-d10_compatibility.patch

πŸ‡ΊπŸ‡ΈUnited States kerasai

Just noting what we've done to make this work:

  • Updated Domain to D10 compatible version 2.x
  • We already have an installation of Group v1.x, so we're forced to update to 2.x.
  • Pulled in the not-yet-published D10/Groups 3 compatible branch for Domain Group
  • Aliased Group v2.2.1 as 3.0.0 in order to meet Domain Group's constraint

composer require 'drupal/group:2.2.1 as 3.0.0' 'drupal/domain:^2@beta' 'drupal/domain_group:3.x-dev' -W

After the most cursory of testing, things seem to work fine. I suspect we'll eventually need to include the patch from the MR in #7 πŸ› Requirement conflict when upgrading Group module to 2.0beta3 Active .

πŸ‡ΊπŸ‡ΈUnited States kerasai

Merged and release on 1.0.0.

πŸ‡ΊπŸ‡ΈUnited States kerasai

Noting that I could not get the patch from #3 to apply, but the patch from #2 worked with and without the patch linked in #2.

I'm using the latest release 2.0.0-beta1 (30 April 2020), perhaps #3 applies to the module in conjunction with a patch from yet another issue.

πŸ‡ΊπŸ‡ΈUnited States kerasai

Patch attached to add license info.

πŸ‡ΊπŸ‡ΈUnited States kerasai

Kicking the can down the road.

Fixes a typehint on a method.

πŸ‡ΊπŸ‡ΈUnited States kerasai

Upgrade status reports that the patch from #4 is D10 compatible.

Attached is a patch updating the core version requirement in the info.yml file.

πŸ‡ΊπŸ‡ΈUnited States kerasai

The patch from #2 isn't applying for me, presumably due to having the packaging info included in the diff.

Here is a patch that applies for me.

πŸ‡ΊπŸ‡ΈUnited States kerasai

Hello,

I've added you as a maintainer with full privileges for the project.

Please see the notes on ✨ Make the trigger type a configurable option Fixed for a couple changes before merging.

From there you should be able to roll a new release and it will get picked up on the module page and thru Composer management, etc.

Thanks!

πŸ‡ΊπŸ‡ΈUnited States kerasai

Hi there,

I've done a cursory review, and this seems mostly fine.

The one thing I've noticed, is that you've added the LICENSE.txt and changes to the module's .info.yml file. These are added to the Composer package/download automatically by Drupal's package handling system and shouldn't be included in the module's repo.

Otherwise, it's probably good to merge.

Thanks!

πŸ‡ΊπŸ‡ΈUnited States kerasai

I've reviewed the core services used in kerasai/drupal-cache-helper, and it looks like nothing's changed that affects that library. Rolled a new release, marked as compatible with D10.

I've merged the MR for this issue, to mark this module as D10 compatible, and additionally adjusted the version constraint to specify the necessary version of kerasai/drupal-cache-helper.

To update, you should be able to do something like:

composer update drupal/entity_agree kerasai/drupal-cache-helper

Regarding the error in #16 πŸ“Œ Automated Drupal 10 compatibility fixes Fixed , there looks an issue with getting the kerasai/drupal-cache-helper library installed. Perhaps a Composer issue, or the composer install/require command failed without the error being noticed.

πŸ‡ΊπŸ‡ΈUnited States kerasai

Updated patch for 9.5.x, we'll see if the test bot can apply it to 10.x.

Production build 0.69.0 2024