🇯🇵Japan @ptmkenny

Drupal 7 is end of life and no further development will happen.

Drupal 7 is end of life and no further development will happen.

Drupal 7 is end of life and no further development will happen.

Drupal 7 is end of life and no further development will happen.

Drupal 7 is end of life and no further development will happen.

Drupal 7 is end of life and no further development will happen.

Duplicate, please ignore.

Thanks for reporting this. As a maintainer, I'm happy to review an MR that contains a fix for this and a test, but I don't have the time to work on the code myself.

I also didn't start maintaining this module until a few years after that code was committed, so I'm not able to explain why it is written the way it is.

Reducing priority to "normal" because the main issue was fixed in the Address module. This change will need to go into 4.x now, since that is the dev branch.

ptmkenny → created an issue.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Feature requests now need to target 4.x.

See the discussion here: https://www.drupal.org/project/field_encrypt/issues/2155339 🐛 Encrypted fields do not work with Views exposed filter(s) Active

I'm closing this as there was no follow-up in over six months. Feel free to re-open if you are still having the same issue.

No instructions on how to reproduce in over three months, so I'm closing. Feel free to create a new issue with reproducible steps.

There was no follow-up so I'm closing this.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed. D8+ version does support batching of encrypt/decrypt.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

However, discussion continues in this issue: 🐛 Encrypted fields do not work with Views exposed filter(s) Active

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed. If this is still an issue with the Drupal 8+ versions of the module, feel free to open a new issue.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed. Also Lockr no longer is available.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

AFAIK titles can be encrypted in Drupal 8; please open a new issue if you have trouble.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

In Drupal 8 you can do this through config so it's easy to implement.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed. I'm pretty sure you can encrypt complex fields with the D8 version; feel free to open a new issue if you are having trouble encrypting something.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed. Also SimpleTest is no longer being used.

Drupal 7 is EOL (end of life) so 7.x issues are now being closed.

Thank you! You were getting errors on the 4.x branch because it was broken :/

But, it is now fixed, and so this builds cleanly! This is a great feature; thanks for contributing.

Attribute support is in 11.1, so this can be added to 4.x now.

alexpott → credited ptmkenny → .

Ok, the keyValue approach seems to be the right one, as all tests are passing (except 11.2 phpstan, but I think that's due to deprecations-- 11.1 is completely passing).

Another option is the one outlined by nicxvan in #7 📌 Support OOP hooks Active ; I started this long series of MRs with the approach described in #9 instead, because at the time it seemed cleaner to me, and it was more like the old approach (we would dynamically create hooks for each entity type). However, given the trouble I have had making it work, maybe it would be better to start over with #7 and see where that leads.

Ok, the problem is caused when $container->get('state') gets called in alter() during update:

  public function alter(ContainerBuilder $container): void {
    $map = $container->getParameter('hook_implementations_map');
    if (is_array($map)) {
      $definition = $container->findDefinition('field_encrypt.process_entities');
      $class = $definition->getClass();
      $container_state = $container->get('state');

Not sure how to fix this; will ask in Slack.

@elkaro Well, the good news is that the error "Call to a member function insert() on null" is the same error identified in the Unit tests, so we already have test coverage for this:

    Field Encrypt Update Path (Drupal\Tests\field_encrypt\Functional\FieldEncryptUpdatePath)
     ✘ Update
       ┐
       ├ Exception: Error: Call to a member function insert() on null
       ├ Drupal\Core\Lock\DatabaseLockBackend->acquire()() (Line: 71)

Now to fix the tests...

@elkaro Thanks for the response. Did you have Field Encrypt enabled for any entities?

@elkaro If you delete src/FieldEncryptServiceProvider.php, field encryption and decryption will no longer work. It'd be great if you could provide more info about what is going wrong.

I'm moving this issue to 4.x so it doesn't get closed with the 7.x issues.

After some thought, I'm going to close this in favor of the parent issue 📌 Support OOP hooks Active .

I originally spun off this issue because I thought there would be a way to support both 10 and 11.1+, but as pointed out in #9, because of the changes to the handling of eval(), there's really no good way to do this. So all work on hooks will go forward in the parent issue, and we will leave the 3.x branch with the conventional hooks.

Previews for 4.x should use Drupal 11, not Drupal 10, as 4.x is likely to require Drupal 11.1+.

Thanks, this is an interesting approach.

I will try to do a full review later, but the first issue I noticed:

1. Install the module and change the admin path. The views get renamed.
2. Uninstall the module.
3. The views did not get renamed because the module config was not saved.

So I think this needs an uninstall hook as well.

Thanks, I somehow missed this one when I changed the others :/

I'll make a new release shortly.

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

Please submit an MR, not a patch. Patches are no longer tested by CI, so we need an MR to run the CI tests.

I'm going to mark this as fixed. Feel free to re-open if you're still having issues.

Some additional documentation in comments #8 and #9 on this issue 💬 Multilanguage CSV Import possible? Active .

I tried to follow @marksmith's instructions, but my experience was a little different, so I'm going to write down what I did here.

I'm using the latest dev version of Feeds on Drupal 11.1.

I have a site with a default language of English and an additional language of Japanese.

I have a custom entity type Dinner with two translated fields, Apples and Oranges, and a third non-translated field, Broccoli.

First, I created a Feed Type "Dinner English". On the settings page, under "Processor" -> "Language", I selected English. Then, on the mappings, for the fields Apples and Oranges, which can be translated, I set the language to "English". Then I created a feed of this feed type and tested import; everything worked as expected.

Next, I created a Feed Type "Dinner Japanese". On the settings page, under "Processor" -> "Language", I selected Japanese. Then, on the mappings, for the fields Apples and Oranges, which can be translated, I set the language to "Japanese". Then I created a feed of this feed type and tested import; everything worked as expected.

Differences from what @marksmith reported:

• I could use the same Feeds GUID for both the default language (English) and my other language (Japanese).
• I used "Insert new content items" for both the default language and the other language.

I would be happy to make a docs page about this, but first I'd like to know why @marksmith and I needed different settings.

Added a link to the change record that is causing this.

I think this definitely needs a change record because this MR changes timezone behavior.

As far as I know, the code in #2 is ready to go, but there's a bigger question that needs to be answered, which is "Is flag going to provide code examples for 4.x like it did for previous versions?" or will people be referred to the API docs instead.

This is something for the maintainer to decide.

Also, while the examples in #2 are ready to go, it doesn't cover the same scope as the docs for 3.x.

@ressa I've reverted your changes to the IS. If you want to create a meta issue, please create a new issue and link to this one.

ptmkenny → changed the visibility of the branch 3157623-provide-documentation-for to hidden.

@ressa How can this be "Needs review" when you turned it into a meta issue? If an issue has multiple tasks, it can't be "needs review" until all the tasks are completed. Further, your MR ignores all the comments that have already been written. It seems like you should've opened a separate issue instead of adding to this one.

Changes look good to me and CI is now running properly, so marking RTBC. It's important to get this in so that other MRs can run the tests, like 🐛 UpdateUsernameAction::access() Implicitly marking parameter $account as nullable is deprecated Active .

Thanks for reporting this. Could you please create an MR instead of a patch so that the CI tests can be run?

@sabrina.liman Please do not change the version or the category. Core development is currently on 11.x.

@nicxvan Ah, I see it was proposed as an enum but got changed to a class. Thanks for the clarification.

Some of the discussion concerned whether this should be made internal or available to contrib/custom code; absolutely these constants need to be available for contrib + custom code.

One of the key uses of these constants is to enable JSON:API filtering in custom entities. For example:

  /**
   * Implements hook_jsonapi_ENTITY_TYPE_filter_access() for entity_type.
   */
  #[Hook('jsonapi_entity_type_filter_access')]
  public function jsonapiEntityTypeFilterAccess(EntityTypeInterface $entity_type, AccountInterface $account) : array {
    return [\JSONAPI_FILTER_AMONG_ALL => AccessResult::allowed()];
  }

With the MR, this would become:

    return [JsonApiFilter::JSONAPI_FILTER_AMONG_ALL => AccessResult::allowed()];

And everything would continue to work as before, which is great.

However, I wonder if there is a policy for naming these enum cases. With JsonApiFilter::JSONAPI_FILTER_AMONG_ALL, we have JsonApiFilter as the enum name and JSONAPI_FILTER as part of the case name. We could eliminate the repetition by renaming it something like JsonApiFilter::AMONG_ALL.

Also, core uses all caps for constants like JSONAPI_FILTER_AMONG_ALL, but is this appropriate/the policy for enums?

ptmkenny → changed the visibility of the branch 3504702-depreciationerror to hidden.

@uttam You can confirm that the tests are already broken on the module page: https://www.drupal.org/project/email_registration → . So that's why you're seeing that error.

For some reason it's not letting me create an MR off the branch at the moment, but I'm setting this to "Needs review" because the change is fixed in the php84deprecation branch.

ptmkenny → changed the visibility of the branch fix_php8.4_deprecation to hidden.

ptmkenny → created an issue.

Awesome, thank you!

@daniel korte Thanks for keeping the MR up-to-date.

As stated in #8, I think this issue needs to ultimately be fixed in 🐛 Initial request shows complete response on an included field, consecutive request shows incomplete response (/jsonapi/user/user) Active , but it's good to have a workaround available here.

I'm elevating this to major because this issue is breaking the JSON:API Include module; see 🐛 Didn't support jsonapi_default Active .

There are multiple people in that issue trying to find a workaround for an issue that seems to be caused by the JSON:API Defaults submodule.

Thank you for searching for a test. It's quite possible that there is no test.

A little background may be helpful here: at some point in the Drupal 8? development cycle, it was decided that new commits to core require test coverage, so it is the responsibility of new commits to add test coverage if there isn't any already. That's why this issue is stuck.

The reason for requiring tests is to ensure that "fixed" things don't get broken again.

If you want to debate the rationale for this policy, please don't do it in this issue; a better place would probably be the #contrib channel in the Drupal Slack.

Hopefully someone else better informed than me can describe what kind of test should be written for this.