🇦🇹Austria @maxilein

Account created on 10 November 2010, almost 15 years ago
#

Recent comments

🇦🇹Austria maxilein

maxilein created an issue.

🇦🇹Austria maxilein

Thank you! I am very sorry for mixing that up.

🇦🇹Austria maxilein

composer require 'drupal/eca_tamper:^2.0'
./composer.json has been updated
Running composer update drupal/eca_tamper
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

Problem 1
- Root composer.json requires drupal/eca_tamper ^2.0 -> satisfiable by drupal/eca_tamper[2.0.0, ..., 2.0.4].
- drupal/eca_tamper[2.0.0, ..., 2.0.2] require drupal/eca ^2.0 -> found drupal/eca[2.0.0, ..., 2.1.13] but it conflicts with your root composer.json require (^3.0).
- drupal/eca_tamper[2.0.3, ..., 2.0.4] require drupal/tamper ^1.0 -> found drupal/tamper[dev-1.x, 1.0.0-alpha1, ..., 1.x-dev (alias of dev-1.x)] but it does not match your minimum-stability.

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

🇦🇹Austria maxilein

Could you please, please make a D11 version.
Thank you!

🇦🇹Austria maxilein

See here: https://www.drupal.org/project/drupal/issues/2972483 🐛 Page Cache must respect Vary, otherwise it might serve mismatched responses. Active a module that might help in the meantime: https://www.drupal.org/project/page_cache_vary

🇦🇹Austria maxilein

See here: https://www.drupal.org/project/drupal/issues/2972483 🐛 Page Cache must respect Vary, otherwise it might serve mismatched responses. Active a module that might help in the meantime: https://www.drupal.org/project/page_cache_vary

🇦🇹Austria maxilein

Maybe we can get a patch to work with many variations as a first step - at least that important functionality works then.
Then we can optimize the many variation if we have a working version. But now we cannot even test it.
Thank you.

🇦🇹Austria maxilein

The latest merge is in conflict: https://git.drupalcode.org/project/drupal/-/merge_requests/6512/diffs
Conflict: This file was modified in both the source and target branches. Ask someone with write access to resolve it.

🇦🇹Austria maxilein

Re #217

So perhaps a site with en_EN and fr_FR. A browser comes along and tells the site "Hi i'm en-GB,en-US;q=0.9,en;q=0.8". The site would find out what this will end up as so

en-GB,en-US;q=0.9,en;q=0.8 magic => en_EN, we cache this and threat serve cache asif en_EN. This would mean (at least on the drupal side) only the records for inLang => outLang exist, which are pretty small and we dont end up with loads of difference permutations.

Not entirely sure how we would implement that, but feels like a way to have drupal cache be happy.

The little devil on my shoulder also has a voice though. Which does tell me this is kinda a. can of worms as this could also easily break caching on the caches in front of Drupal, be it varnisch or maybe smoething like cloudflare. That is kinda the scary part. Perhaps contrib is better to have this live, instead of trying to get this into core.

If you think of creating that can of worms, then at least make it configurable and for an admin to see which rules apply.
e.g.
field normalized language: "de" field permuting languages: "de-at,de-de, ..."

🇦🇹Austria maxilein

Well are some issues with the language detection and caching anyway ... see here https://www.drupal.org/project/drupal/issues/3221375 🐛 Wrong language field labels after `drush cr` because of Drush language negotiation Needs work

🇦🇹Austria maxilein

Sorry, I don't. Then I would have made a suggestion.
I think the "recommended version" shown on your site's update page is determined by a combination of factors managed by the Drupal.org packaging system.

This is what gemini told me. And I think the hint may be in the first paragraph.

How the "Recommended Version" is Determined
Essentially, the recommended version is the latest stable release of a module on Drupal.org that is compatible with your site's major Drupal core version.

Here's what the module maintainer does, and how your site gets the information:

Code is Updated: The maintainer updates the module's code to be compatible with a new version of Drupal (like Drupal 11).

info.yml is Key: They update the core_version_requirement in the module's *.info.yml file to reflect this new compatibility. For a module to be compatible with Drupal 11, this line must include a constraint that matches, for example: core_version_requirement: '^10 || ^11'.

A New Release is Created: The maintainer then creates a new, tagged release on Drupal.org (e.g., 8.x-2.5, 2.0.0, etc.). When creating this release, they associate it with a specific Drupal core version.

Drupal.org's Update Service: Drupal.org's system reads the info.yml file from this new tagged release and notes its core compatibility. It then flags this new version as the latest stable, "recommended" release for that line of compatibility.

Your Site Checks In: When the Update Manager on your site contacts the Drupal.org update service, it reports your current Drupal core version. Drupal.org then responds by saying, "For your version of Drupal, here is the latest stable release of that module we have on record."

So, to directly answer your question:

There is nothing extra you need to add to the info.yml file to show a recommended version.

The only thing that matters in the info.yml file is the core_version_requirement key. Having a new, stable release on Drupal.org with an updated core_version_requirement is what makes it the "recommended" version for sites that are compatible with it. The Drupal.org infrastructure handles the rest.

🇦🇹Austria maxilein

How do you address automatic browser detection upon session start and when the user changes language (e.g. using a language switcher) by url keep that?

🇦🇹Austria maxilein

Could we please expand this article to make language selection work behind a proxy?

🇦🇹Austria maxilein

Although I found a solution in the parent case I leave this case in order for someone to evaluate if there is something to be done about it.

🇦🇹Austria maxilein

I am not sure if this is correct but if it is, then token system has evolved and meta tag isn't using it:

1. The "Shortcut" Syntax (:social_share_jpeg:url)
This syntax is a holdover from the older, simpler token system. It was designed as a convenient shortcut for the most common use case: getting a URL for a styled image. It's a special-case syntax that is hardcoded to look for an image style and then a URL.

2. The "Explicit" Syntax (:entity:image_style:social_share_jpeg)
This syntax is a direct reflection of the modern, more powerful Entity API introduced in Drupal 8. In this system, everything is an "entity," and you can chain methods together to get data. The token system mirrors this.

...:field_media_image_1 gets you the field.

...:entity gets you the File entity that the field points to.

...:image_style:social_share_jpeg accesses the "image_style" property of that File entity and passes the "social_share_jpeg" argument.

🇦🇹Austria maxilein

In the documentation there is also an error:

The commands listed for making the files folders writeable are not recursive:
find ./*/files -type d -exec chmod ug=rwx,o= '{}' \;
find ./*/files -type f -exec chmod ug=rw,o= '{}' \;

They should be:
find web/sites/default/files -type d -exec chmod ug=rwx,o=rx '{}' \;
find web/sites/default/files -type f -exec chmod ug=rw,o=r '{}' \;

At least at an existing install.

🇦🇹Austria maxilein

Can someone check if these are the correct settings for the modern D11 folder structure:

/var/www/web - this is documented already.

The following folders need just read access for the www-data:
/var/www/vendor
/var/www/patches

The following folders need also write access for the www-data:
/var/www/private
/var/www/configsync
/var/www/recipes - I am not sure if D11 needs write access to this?

This would add the following commands to the documentation:

sudo chown -R deploy:www-data /var/www/vendor
find /var/www/vendor -type d -exec chmod u=rwx,g=rx,o= '{}' \;
find /var/www/vendor -type f -exec chmod u=rw,g=r,o= '{}' \;

sudo chown -R deploy:www-data /var/www/patches
find /var/www/patches -type d -exec chmod u=rwx,g=rx,o= '{}' \;
find /var/www/patches -type f -exec chmod u=rw,g=r,o= '{}' \;

sudo chown -R deploy:www-data /var/www/private 
find  /var/www/private -type d -exec chmod ug=rwx,o= '{}' \;
find  /var/www/private -type f -exec chmod ug=rw,o= '{}' \;

sudo chown -R deploy:www-data /var/www/configsync
find  /var/www/configsync -type d -exec chmod ug=rwx,o= '{}' \;
find  /var/www/configsync -type f -exec chmod ug=rw,o= '{}' \;

sudo chown -R deploy:www-data /var/www/recipes
find  /var/www/recipes -type d -exec chmod ug=rwx,o= '{}' \;
find  /var/www/recipes -type f -exec chmod ug=rw,o= '{}' \;

🇦🇹Austria maxilein

Please, make a new release that is D11 compatible.

🇦🇹Austria maxilein

Can you add this to the dev version please.

🇦🇹Austria maxilein

I be created a module, since I really needed that functionality for core number fields
https://www.drupal.org/project/formatted_number_input

🇦🇹Austria maxilein

I be created a module, since I really needed that functionality for core number fields
https://www.drupal.org/project/formatted_number_input

🇦🇹Austria maxilein

I be created a module, since I really needed that functionality for core number fields
https://www.drupal.org/project/formatted_number_input

🇦🇹Austria maxilein

I be created a module, since I really needed that functionality for core number fields
https://www.drupal.org/project/formatted_number_input

🇦🇹Austria maxilein

I be created a module, since I really needed that functionality for core number fields
https://www.drupal.org/project/formatted_number_input

🇦🇹Austria maxilein

I be created a module, since I really needed that functionality for core number fields
https://www.drupal.org/project/formatted_number_input

🇦🇹Austria maxilein

Thinking about it: I see that all settings regarding the menu are region based.

Would it be possible to make the primary menu settings - menu based in order to make menus work in any region?
For instance a checkbox that selects menus that should have the settings as in Primary menu region - but then they work like that in any region?

🇦🇹Austria maxilein

Thank you. Looks much better.
There remains just a little padding difference between an a tag inside a menu entry and only a span. Please screenshots.

🇦🇹Austria maxilein

Thank you Julien. That patch made the errors go away when upgrading.

More information on the Drupal CMS upgrade for vinodhini.e:

composer update
Loading composer repositories with package information
Updating dependencies
Lock file operations: 0 installs, 11 updates, 0 removals
  - Upgrading drupal/core (11.2.2 => 11.2.3)
  - Upgrading drupal/core-composer-scaffold (11.2.2 => 11.2.3)
  - Upgrading drupal/core-project-message (11.2.2 => 11.2.3)
  - Upgrading drupal/core-recommended (11.2.2 => 11.2.3)
  - Upgrading drupal/geofield (1.64.0 => 1.65.0)
  - Upgrading drupal/linkit (7.0.7 => 7.0.8)
  - Upgrading drupal/project_browser (2.1.0-beta2 => 2.1.0-beta3)
  - Upgrading drupal/solo (dev-1.0.x babe75b => dev-1.0.x 4b6e29e)
  - Upgrading drush/drush (13.6.1 => 13.6.2)
  - Upgrading nette/utils (v4.0.7 => v4.0.8)
  - Upgrading sebastian/diff (6.0.2 => 7.0.0)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 0 installs, 11 updates, 0 removals
  - Downloading sebastian/diff (7.0.0)
  - Downloading drupal/core (11.2.3)
  - Downloading drupal/linkit (7.0.8)
  - Downloading nette/utils (v4.0.8)
  - Downloading drupal/geofield (1.65.0)
  - Downloading drupal/project_browser (2.1.0-beta3)
  - Downloading drush/drush (13.6.2)
  - Syncing drupal/solo (dev-1.0.x 4b6e29e) into cache
  - Upgrading drupal/core-composer-scaffold (11.2.2 => 11.2.3): Extracting archive
  - Upgrading drupal/core-project-message (11.2.2 => 11.2.3): Extracting archive
  - Upgrading sebastian/diff (6.0.2 => 7.0.0): Extracting archive
  - Upgrading drupal/core (11.2.2 => 11.2.3): Extracting archive
  - Upgrading drupal/core-recommended (11.2.2 => 11.2.3)
  - Upgrading drupal/linkit (7.0.7 => 7.0.8): Extracting archive
  - Upgrading nette/utils (v4.0.7 => v4.0.8): Extracting archive
  - Upgrading drupal/geofield (1.64.0 => 1.65.0): Extracting archive
  - Upgrading drupal/project_browser (2.1.0-beta2 => 2.1.0-beta3): Extracting archive
  - Upgrading drush/drush (13.6.1 => 13.6.2): Extracting archive
  - Upgrading drupal/solo (dev-1.0.x babe75b => dev-1.0.x 4b6e29e): Checking out 4b6e29ea92 from cache
Generating optimized autoload files
54 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
No security vulnerability advisories found.

And the final working result with the patch included:

drush updb
 [warning] Drupal requires databases that support JSON storage.
 (Currently using Database support for JSON Available
)
 [warning] Package Manager is available for early testing. To install the module set the
value of 'testing_package_manager' to TRUE in your settings.php file.


 ┌ Requirements check reports errors. Do you wish to continue? ─┐
 │ Yes                                                          │
 └──────────────────────────────────────────────────────────────┘

 ----------------- --------------- ------------- ----------------------------
  Module            Update ID       Type          Description
 ----------------- --------------- ------------- ----------------------------
  project_browser   convert_enabl   post-update   Updates Project Browser
                    ed_sources_to                 settings to support
                    _arrays                       source-specific
                                                  configuration.
  project_browser   rebuild_conta   post-update   Clears the cache so that
                    iner_for_oo_h                 Project Browser's OO hooks
                    ooks                          are registered.
 ----------------- --------------- ------------- ----------------------------


 ┌ Do you wish to run the specified pending updates? ───────────┐
 │ Yes                                                          │
 └──────────────────────────────────────────────────────────────┘

>  [notice] Update started: project_browser_post_update_convert_enabled_sources_to_arrays
>  [notice] Update completed: project_browser_post_update_convert_enabled_sources_to_arrays
>  [notice] Update started: project_browser_post_update_rebuild_container_for_oo_hooks
>  [notice] Update completed: project_browser_post_update_rebuild_container_for_oo_hooks
 [success] Finished performing updates.


🇦🇹Austria maxilein

Thank you!
I did not know that existed. I will look into it.

🇦🇹Austria maxilein

It is working on D11.2 just fine. Please make a new release or add a co maintainer ...

🇦🇹Austria maxilein

Thank you that css works.
Is there a template that I can override in order to not force the remaining fields to be inside that layout-region-node-secondary?

🇦🇹Austria maxilein

This is the message on the /admin/reports/updates page:

Views Summarize 1.1.x-dev (2021-Feb-20)
Project not supported: This project is no longer supported, and is no longer available for download. Uninstalling everything included by this project is strongly recommended!
Includes: Views summarize

And that seems different from the module's homepage. Further I am using it on Drupal 11.2 with no problems at all.

🇦🇹Austria maxilein

I completely agree with you on this: The Drupal site builder/developer needs to attend to these Views, and fix them, regardless if it's 1 or 100.

But it should always be the developers decision on how to approach that.
If I want to get stuff out of a site immediately (for whatever reason) - it is my decision on how to deal with the fallout.
That's why transparency is key.

And since the current warning already lists impacted nodes it cannot be too difficult to provide some more meta information from inside that same routine.

🇦🇹Austria maxilein

There are more scenarios we should take into consideration and it should always be the admin's responsibility how he wants to proceed.
Why? Because the approach of blocking the uninstall of a module is doable if you have a few views that you can adapt quickly. But if you have very many views and entity types on a large site the invalidation of them can be the approach with lesser pain and cost.
There are two problems:
Finding out which items are affected.
Fixing them.

Also in a dev environment you sometimes realize too late (once you have built lots of stuff with it) that a certain module is faulty or breaking some other much more important functionality so you have to be able to remove it easily.
Then invalidating items (views, entity fields,..) is the better approach, because it may break the site to some extend, but you can still access the configuration of the views and fix it. Invalidation just breaks parts of the site. While a faulty module that cannot be uninstalled can break everything.
If we offer an approach where the admin or dev can make the judgement regarding the path with the lesser pain - would be best in my opinion.

We need to be better in these things at least:
a) Show a warning: just listing the nodes in the gui before deletion is not good enough. If you have many views (100+) you cannot properly take notes for each of them. So also add one single(!) log message that lists all nodes including links to get there and if possible the particular information of configuration changes that will be made - if the admin procedes. This log message can be used as a task list for fixing things - even if the admin/dev does not procede and cancels deletion.
b) Create a log message the admin/dev can work with. see a) and create a very informative task list. Ideally something where I can derive a judgement of which effects the uninstall will have (e.g. is it just views, is it the display of entities, will widgets go missing, ...). We have all this information in the database, right?
c) let the admin/dev decide if he wants to delete OR invalidate affected entities - depending on his knowledge of the site.

🇦🇹Austria maxilein

I will try this module and see if it can make a difference: https://www.drupal.org/project/modules_weight and post back soon.

🇦🇹Austria maxilein

solo-utils.js is loaded after the solo-menu.js ...

🇦🇹Austria maxilein

sorry for bothering you.

🇦🇹Austria maxilein

Further testing shows that the Fixed Search Block also works when there is something in the header.

🇦🇹Austria maxilein

Maybe it is important to know that I changed the order of the primary menu above the header.

🇦🇹Austria maxilein

Maybe it is important to know that I changed the order of the primary menu above the header.

Production build 0.71.5 2024