jan kellermann → created an issue.
For D10 I need these 3 patches:
Issue #3454939 (search_api):
-
https://www.drupal.org/files/issues/2024-06-17/3454939-search-api-solr-c... →
- https://git.drupalcode.org/project/search_api/-/merge_requests/148.diff (Commit #eb63433e4a229613836c24811d7aa82b37ff7db4)
Issue #3449292 (search_api_solr):
-
https://www.drupal.org/files/issues/2024-06-17/search-api-solr-fatal-err... →
For D10 I need these 3 patches:
Issue #3454939 (search_api):
-
https://www.drupal.org/files/issues/2024-06-17/3454939-search-api-solr-c... →
- https://git.drupalcode.org/project/search_api/-/merge_requests/148.diff (Commit #eb63433e4a229613836c24811d7aa82b37ff7db4)
Issue #3449292 (search_api_solr):
-
https://www.drupal.org/files/issues/2024-06-17/search-api-solr-fatal-err... →
And it looks good! Thank you very much!
❌ Current weighted contribution credit tier would qualify you for Silver Drupal Certified Partner if you were a part of the program.
Learn more about being a Drupal Certified Partner.
jan kellermann → created an issue.
The patch resolves the problem.
This seems a follow up from
https://www.drupal.org/project/tome/issues/3406138
🐛
The 'core_version_requirement' constraint (^9 || ^10) requires the 'core' key not be set
Needs review
jan kellermann → created an issue.
If you need this token you can use the attended patch.
jan kellermann → created an issue.
Works for me. Created MR for only change order in dev-tree.
jan kellermann → made their first commit to this issue’s fork.
Thank you, works for me.
This bug is fixed in https://www.drupal.org/project/panelizer/issues/3352704 🐛 Drupal 10 compatibility fixes follow up Fixed and already committed to 8.x-4.x-dev so we can close this ticket.
Big sorry, was a patch for a local patch. Closing ticket.
jan kellermann → created an issue.
Thank you for your work. This version works for us.
Thank you. Patch solved the problem. Works for me.
Problem fixes this issue. Adapted Code for D10 / 2.x-dev.
ky.
I tested the patch and it resolved the problem. Thank you for your work!
(I can reproduce with editing the content type "basic page". After saving the form i get a WPOD.)
It was only a quick check and I could not test the whole system so I do not set the status to "Reviewed".
@matslats the last commit for D10 wirh the "half fix" for this issue is only available in Tag 2.0.0-beta3 but not in 2.0.x-branch, so I dont open a merge request. If you merged the commit to 2.0.x I can crate a MR (or you patch this without MR). Best regards.
In version 2.0.0-beta3 this issue is partly patched in https://git.drupalcode.org/project/area_print/-/commit/cbdfbd4c06fb191c8...
The 2nd replacement I put in the patch #3.
Status stay on reviewed.
I was having issues with unconverted special characters and created a feature request for optional transliteration using transliteration from Drupal core.
Please check the patch in #3398948
https://www.drupal.org/project/search_api_glossary/issues/3398948
✨
Add Transliteration as option
Needs review
.
I think having a transliteration option is better than transliterating by default, so I can't set this issue to Reviewed status.
jan kellermann → created an issue.
Unfortunalety I cannot test against 2.x (only 3.x is available). So I created a MR of existing code.
The code is running on a complex drupal since several months without problems.
Many thanks to @andy_w
Fixed little bug if $field_configurations contains no key fields (for 2.x-dev).
Adding the ^4 constraint solves the problem.
jan kellermann → made their first commit to this issue’s fork.
jan kellermann → made their first commit to this issue’s fork.
We have the same problem with module alert_message on the same code position: calling an entity-query in handle() in the middleware.
We can reproduce after saving an entity (via structure menu) in the backend while alter_message is enabled.
I guess after clearing caches there is not the complete drupal code available for the middleware stack. And shield calls via `handle()` > `bypass()` > `basicAuthRequestAuthenticate()` the module `basic_auth` which calls an entity-query.
In alert_message is the same problem here: https://git.drupalcode.org/project/alert_message/-/blob/1.0.x/src/StackM...
So i think it could be more a conceptional problem with the middleware and core; or - if intended - the middleware must avoid entity queries.
jan kellermann → created an issue.
Thank you very much! I can confirm this patch also.
Notice for people who want to add this patch: Remove #3325442 before because it is included in this patch already.
I would like to support @gisle. To process the data you need an opt-in, not an opt-out. And you must inform about your privacy policy. And I'm not sure where the data is processed (India is not allowed and I didn't find miniorange or xecurify.com on https://www.dataprivacyframework.gov/).
So - please - remove this feature at all. Open source software is not the place to collect privacy data.
jan kellermann → created an issue.
Sorry, wrong -p-level in #26
tldr
Add 2 options to prevent information disclosure. The patch is a proof of concept with several todos.
a) email verification disabled
Dont show information that name or mail address are in use, just got to the front page and send an information mail to the account holder.
b) email verification enabled
Introducing a two-step registration.
- In 1st step only ask for mail address and consent to policy privacy. If mail address is in use you get a passwort reset link.
- In 2nd step after getting mail create your account.
Long version
I am not sure if this can be fixed without fundamental changes. The register-form is rudimentary. You have information disclosures, you have no consent for processing privacy data per default, you have no automatic routines for deletion unconfirmed users.
We can mitigate each single point - but everytime many custom solutions or contrib modules may break. And I think almost every page has a custom solution because the register form provides only basic functionality.
In an ideal world you have a two-step register process:
1) In the 1st step the user enter their mail address and consent to the privacy policy of the site. They get on the screen in any case: "Thank you for registration. We send you a mail to the given address." Then a mail with register-token or password-reset will be send. (In a real ideal world this double-opt-in would be a service in core and the data would be saved encrypted). Yes, we need a flood-protection. No user user entity will be created at this point (so we have no problem with no-deletion of orphaned users (privacy violation!).).
2) In the 2nd step the user can create their profile. If the site is working with user names (better use only mail address) you have to inform all users that they will be visible to other registered users (and they may use an anonymous nick name).
But this would break many (most?) existing solutions.
My proposal is to add a info-text and add 2 new options to the account settings formular.
The patch is a proof of concept to show the possible process.
Open todos:
- Account-Settings-Form: The states are not working correct - please click on and off to disable correctly.
- two-step: Encrypt / Decrypt data in keystore.
- two-step: No mail is sent after 1st step, you will be instead redirected to the generated URL to register
- two-step: Remove data form keystore.
- Send mail if registration fails in process without email verification.
The patch should apply to D10.1
Please take this as an offer for discussion.
jan kellermann → created an issue.
We have this problem when page_cache is deserializing a form because somewhere on the way the RequestStack is empty.
We use open social and memcache, so several parts of code can cause this bug. The form is the enroll-action-form embedded in a block.
The MR 3646 mitigated this problem.
TypeError: Drupal\Core\Routing\RequestContext::fromRequest(): Argument #1 ($request) must be of type Symfony\Component\HttpFoundation\Request, null given, [...]
Drupal\Core\Routing\RequestContext->fromRequest() (Line: 28)
Drupal\Core\Routing\RequestContext->fromRequestStack()
call_user_func_array() (Line: 276)
Drupal\Component\DependencyInjection\Container->createService() (Line: 177)
Drupal\Component\DependencyInjection\Container->get() (Line: 434)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters() (Line: 273)
Drupal\Component\DependencyInjection\Container->createService() (Line: 449)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters() (Line: 237)
Drupal\Component\DependencyInjection\Container->createService() (Line: 177)
Drupal\Component\DependencyInjection\Container->get() (Line: 434)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters() (Line: 237)
Drupal\Component\DependencyInjection\Container->createService() (Line: 177)
Drupal\Component\DependencyInjection\Container->get() (Line: 434)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters() (Line: 237)
Drupal\Component\DependencyInjection\Container->createService() (Line: 177)
Drupal\Component\DependencyInjection\Container->get() (Line: 89)
Drupal\Core\Form\FormBase->__wakeup()
Memcached->getMulti() (Line: 71)
Drupal\memcache\Driver\MemcachedDriver->getMulti() (Line: 144)
Drupal\memcache\MemcacheBackend->getMultiple() (Line: 136)
Drupal\memcache\MemcacheBackend->get() (Line: 306)
Drupal\page_cache\StackMiddleware\PageCache->get() (Line: 124)
Drupal\page_cache\StackMiddleware\PageCache->lookup() (Line: 82)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 23)
Stack\StackedHttpKernel->handle() (Line: 718)
Drupal\Core\DrupalKernel->handle() (Line: 19)
We may (optionally) consider sending an email when an account is suspended.
Then we have no information disclosure and the account is informed that someone tried something bad and can inform the administrator.
Works for us.
You cannot write "The account has been temporarily blocked." because then you say that this account exists and you have a privacy data breach!
But this means you have to count the password-requests for every mail address - regardless of whether this account exists or not. If you count only the requests for existing accounts a malicious robot can examine which user accounts exists or not. Imagine this e.g. for a HIV/AIDS Selfhelp portal!
Please be careful with such information to avoid an information disclosure and a privacy violation.
Patch #17 works for me. Fine!
Maybe you can choose $settings['memcache']['key_prefix']; as $settings['memcache']['persistent'] per default? In shared environment it could be great to have a pconnection for each drupal. Maybe this could be a hint in the README.
Thank you for your work.
jan kellermann → created an issue.
Sorry, fixed patch-file.
jan kellermann → created an issue.
The patch file in your composer.json did not appy for 9.4.13.
Please use https://www.drupal.org/files/issues/2023-04-06/2107455-84.patch → instead of https://www.drupal.org/files/issues/2022-06-24/2107455-75.patch →
thank you.
Reworks patch #74 for Drupal 9.4.13
@bnjmnm
> it may be possible to simply use localStorage and not have to use Cookies at all
Any change in the browser needs explicetly to opt in before the change is made. Changes in the browser means cookies, localStorage and every data saved in the browser.
See german law here: https://dsgvo-gesetz.de/ttdsg/25-ttdsg/
In Europe we have Data Protection Rights (GDPR) and in germany we have a law calles TTDSG for cookies. by this law the user has explicetly to opt in BEFORE a cookie is set - except it is absolutely needed to deliver service (like Session-Cookie). With this idea for additional cookies any Drupal Site in germany needs an additional opt-in for this cookie, because "reducing repaints" is not "absolutely needed to deliver service". Maybe you can do this optional in a theme. But please no unnecessary cookies in core.
From my view not a good idea.
For me the expected behaviour is, that links that are not accessable are not shown on my page. Therefore I think the apporach of the patch is correct. In every menu we have the same behaviour.
The problem is, that we mixed up an API call (getLanguageSwitchLinks()) and the block for languageswitcher.
I think, we need a 3rd parameter for getLanguageSwitchLinks() with checkAccess=TRUE. Then everyone can get all languageswitch-links via API and can write their own code and show what their want.
For the languageswitch-block I think the expected default behaviour is not to show unaccessable links. It could be a solution to add an option "show link to homepage for missing or unaccessable links". Than the sitebuilder can decide what to do with missing links. But to do this by default like in patch #10/16 seems to invasive for me.
To fix this for current installations I would prefer patch #2, so they can change inaccessable links by their own before access check. But in the long way we should differentiate between API-call and block - and they should write their own block.
Your patch is good for everyone who needs this functionality as soon as possible back! Thank you for this, I am sure the patch is a big help for them. But I dont think this should merged in core.
jan kellermann → created an issue.
At Drupal 9.5 we have this error:
Error: Class "Drupal\panelizer\Plugin\PanelsStorage\ContextDefinition" not found in Drupal\panelizer\Plugin\PanelsStorage\PanelizerDefaultPanelsStorage->getEntityContext() (line 128 of .../modules/contrib/panelizer/src/Plugin/PanelsStorage/PanelizerDefaultPanelsStorage.php).
We attached a new patch for Drupal 9.5 and panelizer 8.x-4.4