Apparently, the page's original author was composing the text with the mindset of migrating "from non-Drupal to Drupal" use case. This way, the name of our CMS, "Drupal," was used to distinguish in many instances. However, this leads to confusion when migrating "from Drupal to Drupal", because the reader cannot safely distinguish which one the author meant. Therefore, such occurrences are now fixed to use the "source" and "destination" terms exclusively instead.
For anyone stumbling here in search of a solution using this OpenID Connect module together with AWS Cognito, I posted some screenshots → about how I managed to make it work.
Regarding the status of this ticket: the error message posted tells about a type error in PHP. I have not checked the mentioned part of the code, but out of experience, I'm doubtful whether it would be explicitly related to one single IdP provider, such as AWS Cognito.
Unfortunately, currently I'm in rush having no time for a properly composed written guide, but at least here are some screenshots how I managed to made it work.
Stumbled upon the same issue after running $ ddev drush pmu password_policy command
- password_policy: 4.0.3
- Drupal Core: 10.4.7
- PHP: 8.3.23
Leaving the ticket status unchanged until I manage to dig up some further info on the issue's background.
Copy over the list of recommended extensions from the legacy page.
Recomposed the text of recommendation of 'mtbdata.vscode-phpsab-docker' extension to fit more coherently to the overall guide. Plus some minor fixes.
Just as future reference for anyone landing here: the linked documentation page went under a complete rewrite during July 2025. It can happen that the question initially asked might have been answered by the newer revision.
Adding a section about Drupal-specific extensions.
Finishing Docblock section + minor content fixes
Segment long page content into sections with titles based on Darvanen → 's suggestion via Slack.
Fix annoying style ignorance in IS.
Copy over "Special cases" section from legacy content
Complete rewrite with much more explanations to help the Reader understand the background of all these frontend development tools.
Improve formatting of commands within the code snippets.
Start section about frontend (JavaScript + Twig) development
Start merging legacy content into the newly added sections.
Extending DDEV section + finishing PHPStan section
Hi All! Do you think adding this <link rel="preconnect" href="https://www.googletagmanager.com"/> HTML element is necessary or beneficial to the 2.x version of this module as well?
Continue experimenting with various PHP CS extensions.
Add a section at the beginning about assumed project structure.
Adding an extra tip about instant changes of settings.json file.
Linking images to themselves for easier opening
Thanks
@olegiv →
for the hint. For those who use DDEV: in my .ddev/config.yaml I changed this line:
webimage_extra_packages: [php8.1-psr]
to this:
webimage_extra_packages: []
Closing feature comparison section, adding upcoming sections.
Adding extra image about the vscode.php built-in extension.
Start functionality comparison of PHP parser extensions.
Clarifying the section about configuration management.
Replace incorrect screenshot + Extend section of text
Adding links to other builds and forks and an image of default setting options.
Adding an extra tip to access extensions' settings.
Add section about configuring the absolute path of the globally installed binary of PHP parser.
Continuous work on a fully revamped and extended revision.
Extend the introduction to better explain how the Drupal ecosystem utilizes Composer package management.
Extending the "Obtain the software" section with extra information and links
This is why I did not find any occurrences, because the name of the setting is concatenated:
https://git.drupalcode.org/project/menu_breadcrumb/-/blob/2.0.x/src/Menu...
baluertl → created an issue.
Adding a sentence of hint from personal experience about when to enable this requirement on custom routes.
Now tested on a vanilla D11 installation with Simplytest․me, for me the module seems to work as expected.
- consent_popup: 1.0.5
- Core: 11.1.5
- PHP: 8.4.5
- Theme: Olivero
Thank you for you time Claudiu for fixing this.
Code changes of the MR !20 at commt db67d6c7 now tested with Simplytest.me on Drupal core 10.4.3 and works as expected. +1 RTBC
I think we should also soft-redirect everyone landing here by the search engines to the following documentation pages:
C'mon, folks, a decade has passed with no progress around such a minor issue. We always try to play democracy at its best; we listen to every voice. But why can it happen that 1 single person vetoes against seven others 📌 Bring back contextual links for admin views Active ? I agree that UX is a significant profession, but why can one not feel convinced and give up their viewpoint against others for such a minor issue?
Meanwhile, during the last 10 years, can you imagine how many occasions our product has missed to let our users switch over quickly to the configuration page of a View? Yes, imagine because we don't have usage data (yet…). Therefore, referring to any numbers or percentages in any arguments in this discussion, I don't feel quite convincing.
Just stumbled upon this here arrived from the Meta issue. I'm asking all the previous commenters on this thread: a decade has passed, and a lot has been changed in and out of the Drupal core. Can anyone recall why this ticket was opened originally?
If no one has memories, I suggest closing this ticket as “Won't fix”.
baluertl → created an issue.
“This will only display if form elements are correctly setup with #config_target keys, and if that target is overridden.”
This module can be useful until the mentioned render array attribute gets widely used in the contrib space. Otherwise, the core's warning will not appear if #config_target is not communicated by the ConfigForm instance.
As an avid documentation person, I support the idea that such a sophisticated software ecosystem as Drupal must embrace and promote a more modern markup format for writing all our valuable documentation.
I can imagine even some automated tools to implement for converting current .txt files into .md files. And of course, the CommonMark initiative is the best option to promote for our community, I believe.
Re-roll patch for the latest D9-supported version of this module 3.1.34.
I cannot tell whether the solution proposed for fixing is good or bad, but I share my concerns about how caching API responses was implemented back then. For example, I can't recall any evidence of how these cache objects got invalidated. During testing on my local instance, I regularly hit $ drush cr to get the results from API calls as expected. It can be seen as my limitation, but I believe the entire caching logic of the module could be revised and eventually improved if time allows. One possible option can be to rely on Widen's recently introduced Webhooks and initiating purging our caches based upon receiving a call from their side.