🇺🇸United States @charginghawk

Can we add an agenda item to talk about a groups.drupal.org 2.0? I'd like to propose/volunteer for building a successor, that would be a more direct alternative to Meetup. It could have a subscription model, and while initially catering to Drupal groups ported from groups.drupal.org, we could look towards opening it up to any folks who want to migrate away from Meetup.

I believe the market is ready for non-profit/public benefit alternatives to legacy social companies, as indicated by the recent success of Bluesky. Given Meetup's acquisition by "private equity hipsters" and subsequent price increases, an alternative managed by the Drupal Association could benefit from goodwill and become a tidy profit center.

seantwalsh → credited charginghawk → .

Rerolling #14 for 10.3.x. Also adding the "setSyncing(TRUE)" described above to setOutdated on the current revision instead of creating a new one.

@luksak The update was merged a while ago, and I just cut release 8.x-1.4, so we should be good to go.

I didn't cut a release initially because there might be a conflict with Twig dependencies. This module uses ajgl/breakpoint-twig-extension 0.3.4:

https://git.drupalcode.org/project/twig_xdebug/-/blob/8.x-1.x/composer.j...

Which doesn't support Twig 3 (which Drupal 11 uses). But, 0.3.5 does, so we should be good to go.

https://packagist.org/packages/ajgl/breakpoint-twig-extension#0.3.4
https://packagist.org/packages/ajgl/breakpoint-twig-extension#0.3.5

At some point we should update to 0.4 version of ajgl/breakpoint-twig-extension, but I don't know what work that will require.

Clean up and consolidate explanations of Twig debug mode. Direct developers to enable Twig debug mode in development.services.yml and discourage enabling it in the primary services.yml file, which can more easily end up in production.

charginghawk → created an issue.

Without getting into whether the approach makes sense (in our case we wanted a separate UI from the original), we found an easier way to accomplish this without the patch:

  public function overviewFormSubmit(array $form, FormStateInterface $form_state, $type) {
    $current_plugin_id = $this->pluginId;
    $this->pluginId = 'content';

    parent::overviewFormSubmit($form, $form_state, $type);

    $this->pluginId = $current_plugin_id;
  }

This would be a useful feature (and feasible since TMGMT knows what it will and won't translate), and in any case a stakeholder requested it (based on similar functionality in Lingotek), so here's a first pass (only tested with nodes):

https://git.drupalcode.org/project/tmgmt/-/merge_requests/74

Apologies for reviving a closed ticket. We can of course close again if we really don't want to support this use case.

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

Unable to test 10.3 right now, but it seems like the outdated option should still be unavailable since the logic hiding it is still there:

https://git.drupalcode.org/project/drupal/-/blob/11.0.4/core/modules/con...

In any case that code should be removed. Also, we should have steps to reproduce.

Additionally, as a commenter noted, "Why does a new revision need to be created to mark it as outdated?" It doesn't. The condition at the end of markRevisionTranslationsOutdated() should use setSyncing(TRUE) to mark the latest translation affected revision as outdated:

      $revision_id = $storage->getLatestTranslationAffectedRevisionId($entity_id, $langcode);
      if (!$revision_id) {
        continue;
      }

      /** @var \Drupal\Core\Entity\ContentEntityInterface $revision */
      $revision = $storage->loadRevision($revision_id);
      $revision_translation = $revision->getTranslation($langcode);
      $metadata = $this->manager->getTranslationMetadata($revision_translation);
      if (!$metadata->isOutdated()) {
        $metadata->setOutdated(TRUE);
        $revision_translation->setSyncing(TRUE);
        $storage->save($revision_translation);
      }

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

charginghawk → created an issue.

charginghawk → created an issue.

I do not think this is an API module issue, I think it is expected behavior that @see can encompass multiple lines. In the 8.x-1.x version of the API module, the regex that picks out @see docblock stopped at the end of the line (\n):

https://git.drupalcode.org/project/api/-/blob/8.x-1.x/api.parser.inc#L1131

In the 2.x version of the module, they updated it so that all parsing uses the same regex, which can span multiple lines (until it encounters another @tag or reaches the end of the code comment):

https://git.drupalcode.org/project/api/-/blob/2.0.0/src/Parser.php?ref_t...
https://git.drupalcode.org/project/api/-/blob/2.0.0/src/Parser.php?ref_t...

So, (1) the original formatting never followed best practice in the first place. You should not intersperse @see's with content but instead put them at the end. Even with the 8.x-1.x behavior, there's no reason to intersperse them with content because they would automatically be moved to the end.

(2) The @see usage was probably mistaken, since the classes are most useful to readers in context. You read the paragraph about revisions, and at the end it points to the revision classes, then you read the paragraph about translations, and at the end it points to the translation classes, finally you read the paragraph about revision translations, and it points to the revision translation classes. That's helpful. Linking to classes at the end of a paragraph is done in many places throughout the API documentation. Dumping all the classes into the "See more" section at the bottom of the bottom outside of context is less helpful.

(3) The API's current behavior is expected and the documentation should be updated to cohere to it. Multi-line @see statements make sense. The formatting of this documentation in question just does not make sense, any way you cut it. There is no reason to expect the API module to revert to single line @see statements for this specific use case, nor should it.

I think my MR is the cleanest fix to everything here.

MR: https://git.drupalcode.org/project/tmgmt/-/merge_requests/73

charginghawk → created an issue.

IMO, the classes should be in context within the section, I genuinely believe that was how it was meant to be read, and my MR makes it a reality. As far as I can tell, @see is usually put at the bottom of the respective section (because it is by definition an afterthought), whereas here it is interspersed with the content. You could argue the behavior in the latest Drupal vs Drupal 9 is expected, to allow putting multiple lines in an @see statement.

Either the @see statements should be moved to the end of the section, or we should use my approach of "See \Drupal\ThisClass and \Drupal\ThatClass." that is also common. I think the latter makes more sense, but the current formatting doesn't make sense either way.

The current formatting is failing because the the way the section comes out is just broken. The content is written to be one section:

https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

But because of the mistaken "@see" usage it gets truncated and the remainder ends up in the "See also" section at the bottom:

https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Entity!entity.api...

I made an update to my MR not use "See these:" and instead put the classes inline into the sentence, eg "See\Drupal\Core\Entity\RevisionableInterface and \Drupal\Core\Entity\RevisionableStorageInterface."

I see similar formatting in core.api.php:

https://git.drupalcode.org/project/drupal/-/blob/11.x/core/core.api.php#...

https://api.drupal.org/api/drupal/core%21core.api.php/group/cache/11.x

seantwalsh → credited charginghawk → .

Created MR to fix the issue. Also fixed "entity_characteristics"/"entity_type_characteristics" mixup from 📌 Add an API docs topic to cover entity characteristics in general and how they work Fixed .

charginghawk → created an issue.

FYI we addressed this use case using ✨ Allow to reset finished job to active state RTBC . Reset the job and pull translations again.

charginghawk → created an issue.

Thank you for this! I opened an MR with the #13 patch. I also wanted the option to be available in more places, so I added it to more spots as well as job items.

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

The original MR has gotten pretty messy (configuring default values in config is a nice idea, but should have its own ticket, and needs support in MemsourceTranslatorUi::buildConfigurationForm()). I've created a new MR that does two specific things:

- Doesn't erase settings willy nilly (copied from https://www.drupal.org/project/tmgmt_memsource/issues/3243687 → )
- Loads existing values as defaults

https://git.drupalcode.org/project/tmgmt_memsource/-/merge_requests/9

Moving to major since this is pretty broken if you use continuous translation.

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

MR from 💬 Translate more than 20 content sources at a time Closed: duplicate that lets you set the item count on the form itself:

https://git.drupalcode.org/project/tmgmt/-/merge_requests/18

Duplicate of #1905486: select all entities in case of pagination → .

ini_set('syslog.filter', 'raw'); did end up resolving the issue for us.

charginghawk → created an issue.

Works great! Moving to major priority because automating updates is majorly important.

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