🇳🇱Netherlands @JoshaHubbers

Hm, I did add your suggestion to the module, but accidently committed it in the dev branch in stead of in the issue fork. If you want to test the implementation in the dev-branch, it would be great...

Did you use this in combination with workflows?

Hm, nice, I will have a look at inserting it in the module and write some tests for it.

This is a tricky one indeed. It is not very hard to intercept the form and prevent the published setting being set to false, but how will this behave in automated workflows? I have to think about this a little.

Fixed in the new release.

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

Excuse me... I just realize that I did not update to the latest version of 10.2. While updating to the latest version, this patch had to be removed again. Sorry for the confusion.

Patch with this change for 4.23. This fix is not in that release and my drush updb got stuck on this when upgrading to 10.2.
So no new development, just the patch file to use in composer.json.

Hi @HeikkiY.

Sorry for my absense. Had a very busy time lately. Switched work and also personally. I will look at your comments as soon as possible, but some quick responses:

* I run the tests with the ddev tooling
* git instructions are updated automatically on d.org normally as soon as one starts committing in the repo. Strange that it doesn't here.
* I agree that we can start a new major branch, and drop support for older Drupal versions. I would suggest only supporting the currently supported versions in the new branch

Maybe a good start to commit the fixes in this MR, because most of the issues are solved. And than we move to a new 2.x branch to start working on a new release?

Done:
* gitlab ci added
* composer.json added
* .gitignore added
* cspell words list added
* test fixted
* most phpstan fixes. Some phpstan errors are coming from hook-declarations that are inherited from core.

Done:
* gitlab ci added
* composer.json added
* .gitignore added
* cspell words list added
* test fixted

Todo:
* phpstan fixes

Oops, pushed the gitlab-ci.yml file directly to the 1.0.x branch. But fixes will be done in this MR.

JoshaHubbers → created an issue.

Added two co-maintainers. Welcome! Looking forward to your improvements.

* Added a catch to handle responses other than 200
* Added some catches to prevent php warnings for not sending a string into json_decode

JoshaHubbers → created an issue.

* Changed api_url type to uri
* Added api_key to schema

JoshaHubbers → created an issue.

JoshaHubbers → created an issue.

Sorry! I did not look good enough.

JoshaHubbers → created an issue.

JoshaHubbers → created an issue.

Created oldfashoned patch to include because .diff can change without notice.

This is the patch is the same as #118, but rerolled for 3.x-rc19.

This is caused by ✨ Support adding new entities when translating Needs review patch 116.

JoshaHubbers → created an issue.

When debugging the accessSelfOrAdmin function when accessing /user/x/security/tfa (tfa.overview), i notice that the error occurs on the route tfa.validation.setup. This is function also is the access check for this route, so it will be called when rendering the link to /user/x/security/tfa/tfa_trusted_browser.

Now I come to your scenario mentioned above:

I have only been able to reproduce this by Navigating to a user with TFA(at least the trusted browser plugin), clicking on the TFA tab, and than clicking on "Configure trusted browsers".

Apperantly on a clean install the access-check for tfa.validation.setup is not called when rendering the link. But in our setup the access check is also called when rendering the link.

So after this I think we can narrow the root problem down to the access check for the route tfa.validation.setup for login-plugins when $is_self is NOT true.

So I think this patch is valid because this breaks:

• access the tfa.validation.setup path
• for another user, not yourself
• for a login-plugin (currently only trusted_browser)

The question I cannot answer is: why is there no access check on rendering the links in the clean d10 setup? Because this is the cause of also breaking the tfa.overview route in our setup.

Hmm, I replayed the scenario in a clean d10 install, and I cannot reproduce it there. So we have to dig deeper in our setup and other authentication-related modules to find out what is causing this error.

Updated the patch in ✨ Edit_Advanced_Link+Editor_file: conflicting field attributes RTBC . Now editing is solved also. But still not a patch, so local module.

New day, new try.

Updated the function above, and added one to enable the editing dialog. Seems to be working ok now.

Editoradvancedlinkui:

  afterInit() {
    const { editor } = this;

    const drupalFileEditButton = editor.plugins.get('DrupalEditorFileUploadActionUi').fileEditButton;
    const linkUI = editor.plugins.get('LinkUI');
    let drupalFileEditExecuting = false;
    drupalFileEditButton.on(
      'execute',
      (evt) => {
        if (drupalFileEditExecuting) {
          drupalFileEditExecuting = false;
          return;
        }

        evt.stop();
        // Prevent infinite recursion by keeping records of when link command is
        // being executed by this function.
        drupalFileEditExecuting = true;
        const selectedLinkElement = linkUI._getSelectedLinkElement();

        if (!selectedLinkElement) {
          return;
        }

        // Add existingValues of DrupalUpload.
        const existingValues = selectedLinkElement.hasAttribute('data-entity-uuid') ? {
          'data-entity-uuid': selectedLinkElement.getAttribute('data-entity-uuid'),
          'data-entity-type': selectedLinkElement.getAttribute('data-entity-type'),
        } : {};

        // Add existingValues of advanced link.
        const { enabledModelNames } = editor.plugins.get(
          'EditorAdvancedLinkEditing',
        );
        enabledModelNames.reverse().forEach((modelName) => {
          let attributeName = additionalFormElements[modelName].viewAttribute;
          existingValues[attributeName] = selectedLinkElement.getAttribute(attributeName);
        });
        existingValues.target = selectedLinkElement.getAttribute('target');

        const options = editor.config.get('drupalFileUpload');
        const DrupalInsertFile = editor.plugins.get('DrupalInsertFile');

        drupalFileEditExecuting = false;
        DrupalInsertFile.openDialog(
          Drupal.url('editor_file/dialog/file/' + options.format),
          existingValues,
          ({attributes}) => {
            editor.execute('insertFileToEditor', attributes);
          }
        );
      },
      { priority: 'high' },
    );
  }

editoradvancedlinkediting.js

afterInit() {
    const { editor } = this;
    const drupalFileCommand = editor.commands.get('insertFileToEditor');
    let drupalFileCommandExecuting = false;
    drupalFileCommand.on(
      'execute',
      (evt, args) => {
        if (drupalFileCommandExecuting) {
          drupalFileCommandExecuting = false;
          return;
        }
        evt.stop();
        // Prevent infinite recursion by keeping records of when link command is
        // being executed by this function.
        drupalFileCommandExecuting = true;
        const attributes = args[0];
        const { model } = this.editor;
        const { selection } = model.document;

        model.change((writer) => {
          const attrMaps = {
            linkHref: 'href',
            fileDataEntityType: 'data-entity-type',
            fileDataEntityUuid: 'data-entity-uuid',
            target: 'target',
          };
          this.enabledModelNames.forEach((modelName) => {
            attrMaps[modelName] = additionalFormElements[modelName].viewAttribute;
          });

          // When selection is inside text with `linkHref` attribute.
          if (selection.hasAttribute('linkHref')) {
            // Editing existing file link.
            const position = selection.getFirstPosition();
            Object.entries(attrMaps).forEach(([attr, key]) => {
              const linkRange = findAttributeRange(position, attr, selection.getAttribute(attr), model);
              attr = attr === 'target' ? 'link0' : attr

              if (attributes[key]) {
                writer.setAttribute(attr, attributes[key], linkRange);
              }
              else {
                writer.removeAttribute(attr, linkRange);
              }
            });
          } else {
            // Check if text is selected.
            let selectedText;
            const range = selection.getFirstRange();

            // eslint-disable-next-line no-restricted-syntax
            for (const item of range.getItems()) {
              selectedText = item.data;
            }

            const linkAttrs = {};

            Object.entries(attrMaps).forEach(([attr, key]) => {
              linkAttrs[attr] = attributes[key];
            });
            linkAttrs.link0 = linkAttrs.target === '_blank';

            const text = !selectedText ? attributes.filename : selectedText;
            const linkedText = writer.createText(text, linkAttrs);

            model.insertContent(linkedText);

            if (linkedText.parent) {
              writer.setSelection(linkedText, 'on');
            }
          }
          drupalFileCommandExecuting = false;
        });
      },
      { priority: 'high' },
    );
  }

Changedfiles (including build) in attached zipfile.

I created a partial fix here. Works for adding new items, but the "edit" part is still broken.
✨ Edit_Advanced_Link+Editor_file: conflicting field attributes RTBC

I have been fighting with this one yesterday. I am not very good at these things but took a shot at it.

Issues in my case:
* editor_file is loaded after editor_advanced_link. Thus some of the JS in the init() function will not be applied to the editor_file functions.
* editor_file displays a custom dialog, and returns a different set of attributes. not the standard "link" object, but an array with the attributes of the a-element.
* setting the "target" was challanging. Finally found that the attribute "link0" with a value of "true" wil add "target=_blaink" to your link.

I don't know how to create a patch for the ck-editor plugin in this module. So I ended up moving the module to my "custom" folder. Not really the ideal way to go.

Open issues:
* link editing doesn't load the advanced-properties.

Modification to the file editoradvancedlinkediting.js:
Added this function after the "init"-function. The handling is mostly copied from the editor_file module.

afterInit() {
    const { editor } = this;
    // start
    const drupalFileCommand = editor.commands.get('insertFileToEditor');
    let drupalFileCommandExecuting = false;
    drupalFileCommand.on(
      'execute',
      (evt, args) => {
        if (drupalFileCommandExecuting) {
          drupalFileCommandExecuting = false;
          return;
        }

        evt.stop();
        // Prevent infinite recursion by keeping records of when link command is
        // being executed by this function.
        drupalFileCommandExecuting = true;
        const attributes = args[0];
        const { model } = this.editor;
        const { selection } = model.document;

        model.change((writer) => {
          const attrMaps = {
            linkHref: 'href',
            fileDataEntityType: 'data-entity-type',
            fileDataEntityUuid: 'data-entity-uuid',
            target: 'target',
          };
          this.enabledModelNames.forEach((modelName) => {
            attrMaps[modelName] = additionalFormElements[modelName].viewAttribute;
          });

          // When selection is inside text with `linkHref` attribute.
          if (selection.hasAttribute('linkHref')) {
            // Editing existing file link.
            const position = selection.getFirstPosition();

            Object.entries(attrMaps).forEach(([attr, key]) => {
              const linkRange = findAttributeRange(position, attr, selection.getAttribute(attr), model);
              writer.setAttribute(attr, attributes[key], linkRange);
            });
          } else {
            // Check if text is selected.
            let selectedText;
            const range = selection.getFirstRange();

            // eslint-disable-next-line no-restricted-syntax
            for (const item of range.getItems()) {
              selectedText = item.data;
            }

            const linkAttrs = {};

            Object.entries(attrMaps).forEach(([attr, key]) => {
              linkAttrs[attr] = attributes[key];
            });
            linkAttrs.link0 = linkAttrs.target === '_blank';

            const text = !selectedText ? attributes.filename : selectedText;
            const linkedText = writer.createText(text, linkAttrs);

            model.insertContent(linkedText);

            if (linkedText.parent) {
              writer.setSelection(linkedText, 'on');
            }
          }
        });
      },
      { priority: 'high' },
    );
  }

Than dont forget to run yarn to compile the js.

Hm, I get the error as soon as I click on the "TFA"-tab of a user with TFA enabled, and setup (TOTP). We do have patch #34 of this issue ✨ Force user to setup TFA when required and there are no remaining skips Needs work applied.

New message:

In Drupal < 10.2 the ByteSizeMarkup doesn't exsist. Version of the patch with the old format_size() function.

I totally agree with you that this was not the way to go. I attach a new patch and will open a MR for it too (we only use patches in our CI because the diff-contents of a mr can change without notice).

Also we should use dependency injection for the plugin manager, but that is beyond the scope of this bug.

JoshaHubbers → created an issue.

Ooops, test error.

JoshaHubbers → created an issue.

JoshaHubbers → created an issue.

JoshaHubbers → created an issue.

Added one extra check. Got an error in a form where private and encrypted files were mixed.

Added patch file of the diff because the diff can change.

Attatched patch implements the default webform zip export as suggested.

Hm, I'm getting this error with the patch applied:
Call to a member function id() on string in Drupal\webform_scheduled_tasks\WebformScheduledTaskListBuilder->getEntityIds() (line 93 of modules/contrib/webform_scheduled_tasks/src/WebformScheduledTaskListBuilder.php

This patch adds the check.

JoshaHubbers → created an issue.

I solved it by creating a custom views-filter.
1. create a view that loads all the points.
2. in the module file I load the drawn area from the node:

my_module_custom_views_pre_view(&$view, &$display_id, &$args){
  if($view->id() == 'test'){
    if($view->current_display == 'block_1'){
      $node = \Drupal::routeMatch()->getParameter('node');
      if ($node instanceof \Drupal\node\NodeInterface) {
        $focus_area = $node->field_adres->value;
        $args[0] = $focus_area;
        $view->setArguments($args);
      }
    }
  }
}

3. in the custom filter I add a join to the table, and the custom expression to select the points within the polygon:

     /** @var \Drupal\views\Plugin\views\query\Sql $query */
    $query = $this->query;
    $definition = [
      'table' => 'node__field_adres',
      'field' => 'entity_id',
      'left_table' => 'node_field_data',
      'left_field' => 'nid',
    ];
    $join = \Drupal::service('plugin.manager.views.join')->createInstance('standard', $definition);
    $query->addRelationship('adres_filter', $join, 'node__field_data');
    $expression = sprintf("st_Contains(st_GeomFromText('%s'), st_GeomFromText(\"adres_filter\".\"field_adres_value\"))", $this->view->args[0]);
    $query->addWhereExpression($this->options['group'], $expression);

Note: this is quick and dirty. Some basics like service injection must be fixed.

I am also trying to accomplish this. Did you solve it?

Drupal 7.98 update

Update core to 7.98

JoshaHubbers → created an issue.

JoshaHubbers → created an issue.

New patch.
* Change the description and label of the "Signature"-checkbox on the settings page.
* Assure the signature is at the end of the file.

Two versions of the patch, one for the main branch, one with all the patches applied as described in #11.

Well, we use ✨ Language preferred and Canonical settings missing Needs work AND 🐛 Acknowledgment should be Acknowledgments RTBC ... so again the same patch with these two applied before.

The same patch, but applicable if ✨ Language preferred and Canonical settings missing Needs work is applied before this one.

@ralph: I checked, and https://www.drupal.org/project/securitytxt/issues/3375231#comment-15195253 ✨ Language preferred and Canonical settings missing Needs work does not remove the "Signature"-item. It just fixes that it is not displayed twice or if the signature is not present. But the point is that the "Siganture" should not be present in the file at all. It is not in the specs.

This patch adds the signature the right way I think.

@ralph That is great. Then the file will pass the checks. But it does not fix the problem that the signing of the file doesn't work as it shoud imho. I will change the title and description of this issue.

Fixed it for the patch that applies after ✨ Language preferred and Canonical settings missing Needs work is applied.

Fixed it for the original patch.

This patch corrects the typo and adds an update hook to migrate the value to the new config key and remove the old config key.

JoshaHubbers → created an issue.

JoshaHubbers → created an issue. See original summary → .

Patch rerolled for alpha3.