🇺🇸United States @charginghawk

Been a minute, re-running tests to see if the existing ones are working yet.

This is a great improvement! I couldn't figure out why the locale source text search was broken, and then I found that it was a default submit issue ("choosing the TMGMT source" is the default when you hit enter because it's first), and that led me here. Marking major since the current experience is a trip-up.

I made an update to potx to support TMGMT here:

https://www.drupal.org/project/potx/issues/361615 ✨ Provide option to record untranslated strings in database Needs review

This is an old issue, but I wanted to extract translatable strings from the codebase and save them to locales_source, so here we are. Here's what the MR does:

1. Adds a new database table, potx_locales_filesystem_location, you can join with locales_source, that saves the locale id, the module / theme name, the filepath within the module/theme, and the filepath to the module/theme.
2. Adds a function, _potx_write_to_locales_source(), that adds strings to locales_source if they aren't there already, and updates the table mentioned above. This function is called from _potx_build_files().
3. Adds support for TMGMT, a source plugin viewable at /admin/tmgmt/sources/potx_locale/default, where you can see the extracted strings if they have info in potx_locales_filesystem_location, and filter by path and name.
4. It doesn't work for drush. It only works if you use the UI to extract strings /admin/config/regional/translate/extract. That probably should be fixed.

charginghawk → made their first commit to this issue’s fork.

FWIW, I don't use this module, but right now I'm debugging an issue where using \

 in logging causes our log manager to break each line out into its own message, introducing a ton of noise and making it very hard to connect the thread between all the entries. This is using Acquia and Sumo Logic.

Upgrading to major just because hitting an artificially low limit is a real annoyance.

If anybody else is banging their head against this issue, here was my quick fix, assuming that you only want unidirectional updates from English to other languages:

/**
 * Implements hook_ENTITY_presave().
 *
 * @param \Drupal\Core\Entity\EntityInterface $entity
 *
 * @throws \Exception
 */
function my_module_node_presave(EntityInterface $entity) {
  // Don't let non-english content disrupt any other languages.
  $active_langcode = $entity->language()->getId();
  if ($entity instanceof NodeInterface
    && $entity->isTranslatable()
    && !$entity->isNew()
    && ($active_langcode !== 'en')
  ) {
    $translations = $entity->getTranslationLanguages();
    foreach ($translations as $translation_langcode => $translation_language) {
      if ($translation_langcode !== $active_langcode) {
        $translation = $entity->getTranslation($translation_language->getId());
        $translation->setRevisionTranslationAffected(FALSE);
      }
    }
  }
}

Works for me! Fixes a very annoying issue with config differences interfering with deployments.

charginghawk → created an issue.

I updated the #4 patch so that the fields are optional and use the Global values if they aren't entered:

https://git.drupalcode.org/issue/tmgmt_microsoft-3372842/-/compare/8.x-1...

I can't make an MR of it, not sure why.

charginghawk → made their first commit to this issue’s fork.

FYI, if you're API key isn't valid, it's probably because you missed this very easily missed message when creating the translator in Azure:

"Please choose the Global region unless your business or application requires a specific region. Applications that do not offer a region selection use the Global region."

It doesn't help that "Global" is towards the end of the dropdown. If you have a region set, it will only work with the patch from this issue:

https://www.drupal.org/project/tmgmt_microsoft/issues/3372842 🐛 Needed option to change token issue URL RTBC

But really it's easier to delete the translator and create it anew with the Global region.

Works for me!

charginghawk → created an issue.

Seeing the same, do we know if this breaks anything, or is it safe to ignore?

charginghawk → created an issue. See original summary → .

cool cool

If anybody's looking for a fix that doesn't involve patching core, I had success with this:

I had a lot of items that were failing import, so I created a directory to run a partial import from (partial-080323), and copied one of the config files there. It was a very normal config item, xmlsitemap.settings.yml, that probably wasn't breaking anything. I ran drush config:import --partial --source=../partial-080323/ and got a long string of "Missing required data for configuration:" notices, with this strange kicker:

The import failed due to the following reasons:
Deleted and replaced configuration "xmlsitemap.settings"

For whatever reason, after that, there weren't any config differences anymore and config import worked fine.

@dynamdilshan This ticket deals with limiting the X-Drupal-Cache-Tags and X-Drupal-Cache-Contexts headers. With http.response.debug_cacheability_headers set to false, these should not be an issue anyway. You can use xdebug or other debugging tools to step through the code in the patch and confirm whether or not those headers are limited or even need limiting.

I will note that other headers (including from the fastly and pantheon_advanced_page_cache modules) can get out of control and the patch doesn't account for them (though you could maybe argue it should). That's based on recent comments on this Docksal issue:

https://github.com/docksal/docksal/issues/1110#issuecomment-1216488250

The most recent MR/patch is still mxr576's, !1943, from 8 March 2022.

https://git.drupalcode.org/project/drupal/-/merge_requests/1943

It is reviewed by the community (#62, #63) but it needs tests (#64).

Great discussion about patches, but let's please, out of respect for the 87 people following this issue, stop talking about patches here, and do not even reply to say "I agree" or "I understand" or something. We're done talking about patches! Thank you! Direct any further patch discussion here:

https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupa... →
https://www.drupal.org/node/1399218/discuss →

Regarding settings.local.php and development.services.yml (which, rgpublic is correct, should not be enabled on production environments!), please refer to the files themselves and you can discuss it on the "Disable caching" page:

https://git.drupalcode.org/project/drupal/-/blob/10.1.x/sites/example.se...
https://git.drupalcode.org/project/drupal/-/blob/10.1.x/sites/developmen...
https://www.drupal.org/docs/develop/development-tools/disable-caching →
https://www.drupal.org/node/3340861/discuss →

You can also always go to Forums, drupal.stackexchange.com, Slack to get answers to your questions:

https://www.drupal.org/community/contributor-guide/reference-information... →

My next comment here is going to summarize the state of this ticket and hopefully get us back on track.

It's somewhat alarming patch #15 would stop working if you updated, and then you'd start sending mails unexpectedly. That's for sure critical for symfony mailer users, and symfony mailer has a respectable 6500+ installs at this point, so marking critical.

Merged and released, thanks all!

Here's a link to the MR:

https://git.drupalcode.org/project/drupal/-/merge_requests/1943

And here's a direct link to the patch:

https://git.drupalcode.org/project/drupal/-/merge_requests/1943.diff

I believe, security-wise, it's best practice to download the diff and use it a local patch file than reference this link, because attackers could update this MR to introduce vulnerabilities, and then you'd just automatically pull them in.

FYI, this can happen with the API rate limit too. If you somehow go over the rate limit by a couple of items, it gets stuck and you get messages like "diagnostics: ERROR: CloudFlare - Api Rate limit check.: Exceeded Api limit of 1203/1200 limit purges/day" or "diagnostics: ERROR: CloudFlare - Api Rate limit check.: Exceeded Api limit of 1202/1200 limit purges/day." You can get these errors for every page load if late runtime processor is enabled. (Also there's a typo, it should say "1200 limit purges/5 min".) You can run this to reset the API rate:

drush eval '\Drupal::service("cloudflare.state")->incrementApiRateCount();'

@coaston Not sure, there's supposed to be more information, per this bit:

$messenger->addError("{$parent->parent_type}.{$parent->parent_field_name} update failed, corrupt paragraphs: $numFailed")

I would check your logs, or try again after setting system.logging error_level to verbose.

It's the ruby:3.1 image, just because that's Gitlab's default container image:

https://about.gitlab.com/blog/2022/12/13/new-default-container-image-git...

That apt-get line does look weird, I copied it from another pipeline, but it works! Apparently redirections can appear anywhere in the command (I've changed it in my comment above anyway):

https://unix.stackexchange.com/a/670206/164453

For anybody coming across this looking for an example .gitlab-ci.yml, check this out, it's based on the lakedrops pipeline above but works standalone:

collect-config:
  stage: deploy
  before_script:
    - git config --global user.email $GITLAB_USER_EMAIL
    - git config --global user.name "${GITLAB_USER_NAME}"
    - |
      apt-get update >/dev/null
      apt-get -y --no-install-recommends install >/dev/null rsync openssh-client
  script:
    # Setup SSH identity with artifact repo access.
    - eval $(ssh-agent -s)
    # https://stackoverflow.com/a/57774253/1483861
    - cat "$SERVER_PRIVATE_KEY" | ssh-add - > /dev/null
    - mkdir -p ~/.ssh
    - chmod 0700 ~/.ssh
    - echo -e "HOST *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    # Copy exported config from server.
    - rsync -r -e ssh user@site.com:/tmp/cae/ /tmp/cc-${CI_JOB_ID}
    # https://stackoverflow.com/a/50163888/1483861
    - git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/company/site/project.git
    - cd project
    - git checkout -b cc-${CI_JOB_ID} HEAD
    # https://gitlab.lakedrops.com/gitlab-ci-cd/drupal/-/blob/main/data-handling-ng.yml
    - |
      function collectDir() {
        CURRENT=$(pwd)
        mkdir -p $1
        cd $1
        find . -type d -exec mkdir -p "$1/{}" \;
        find . -type f -name '.*' -delete -exec sh -c "echo {}|sed -r 's!./.!$2/!g'|xargs rm" \;
        find . -type f -exec cp "$1/{}" "$2/{}" \;
        cd "${CURRENT}"
        rm -rf $1
      }
    - CURRENT=$(pwd)
    - collectDir "/tmp/cc-${CI_JOB_ID}/config_split" "${CURRENT}/config/override"
    - collectDir "/tmp/cc-${CI_JOB_ID}/language" "${CURRENT}/config/default/sync/language"
    - collectDir "/tmp/cc-${CI_JOB_ID}" "${CURRENT}/config/sync"
    - git status > /tmp/gitstatus.log
    - EC=0
    - grep "nothing to commit, working tree clean" /tmp/gitstatus.log || EC=$?
    - if [[ $EC -eq 0 ]]; then exit 0; fi
    - git add config/*
    - git commit -am "Config change on server."
    # https://stackoverflow.com/a/73394648/1483861
    - git remote set-url --push origin "https://oauth2:$ACCESS_TOKEN@gitlab.com/company/site/project.git"
    # https://stackoverflow.com/a/58327480/1483861
    - git push -o ci.skip -o merge_request.create -o merge_request.target=main origin cc-${CI_JOB_ID}
  cache: {}
  only:
    refs:
      - triggers