maxilein → created an issue. See original summary → .
maxilein → created an issue.
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.
maxilein → created an issue.
Could you please, please make a D11 version.
Thank you!
Autonumeric 4.10.9
https://github.com/autoNumeric/autoNumeric/releases/tag/v4.10.9
maxilein → created an issue.
maxilein → created an issue.
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 →
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 →
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.
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.
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, ..."
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
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.
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?
Could we please expand this article to make language selection work behind a proxy?
maxilein → created an issue.
Thank you all. I will read them asap.
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.
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.
maxilein → created an issue.
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.
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= '{}' \;
Please, make a new release that is D11 compatible.
Can you add this to the dev version please.
I be created a module, since I really needed that functionality for core number fields
https://www.drupal.org/project/formatted_number_input →
I be created a module, since I really needed that functionality for core number fields
https://www.drupal.org/project/formatted_number_input →
I be created a module, since I really needed that functionality for core number fields
https://www.drupal.org/project/formatted_number_input →
I be created a module, since I really needed that functionality for core number fields
https://www.drupal.org/project/formatted_number_input →
I be created a module, since I really needed that functionality for core number fields
https://www.drupal.org/project/formatted_number_input →
I be created a module, since I really needed that functionality for core number fields
https://www.drupal.org/project/formatted_number_input →
I be created a module, since I really needed that functionality for core number fields
https://www.drupal.org/project/formatted_number_input →
I be created a module, since I really needed that functionality
https://www.drupal.org/project/formatted_number_input →
I be created a module, since I really needed that functionality
https://www.drupal.org/project/formatted_number_input →
Try the formatted number input module
Please make a D11 version.
Thank you very much. I can confirm it looks perfectly now.
Thank you very much!
maxilein → created an issue.
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?
maxilein → created an issue.
The span is positioned with a padding top/bottom of 10px.
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.
maxilein → created an issue.
Sorry my error.
maxilein → created an issue.
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.
maxilein → created an issue.
maxilein → created an issue.
maxilein → created an issue.
maxilein → created an issue.
Thank you!
I did not know that existed. I will look into it.
maxilein → created an issue.
It also worked for me. D11.2.
Thanks everyone!
Thank you.
Thank you very much!
maxilein → created an issue.
It is working on D11.2 just fine. Please make a new release or add a co maintainer ...
Thank you!
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?
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.
Can you please make a Drupal 11 version.
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.
maxilein → created an issue.
Thank you. That fixed it.
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.
I will try this module and see if it can make a difference: https://www.drupal.org/project/modules_weight → and post back soon.
solo-utils.js is loaded after the solo-menu.js ...
maxilein → created an issue.
Thank you.
sorry for bothering you.
Further testing shows that the Fixed Search Block also works when there is something in the header.
Maybe it is important to know that I changed the order of the primary menu above the header.
Maybe it is important to know that I changed the order of the primary menu above the header.
maxilein → created an issue.
maxilein → created an issue.