🇨🇦Canada @xmacinfo

xmacinfo → created an issue.

xmacinfo → created an issue.

xmacinfo → created an issue.

Yes, but I do not see a fallback to WEBP.

$supported = function_exists('imageavif') && imageavif(imagecreatetruecolor(1, 1), $tempFile, 0, 10) && fstat($tempFile)['size'] > 0;
fclose($tempFile);

return $supported;

Are we returning FALSE instead of falling back to WEBP?

@noored: AI will replace you. :-)

My development stack does will not support AVIF for the foreseeable future. Fortunately, the production stack supports AVIF.

AVIF Support enabled

So, we need to make sure the fallback to WEBP works on all user create/edit paths:

admin/people/create
/user/edit
or
/user/1/edit

@grimreaper

Indeed, now I see the status message error message:

bundled (2.1.0 compatible)

    - Supported image file formats: GIF, JPEG, PNG, WEBP.
    - Unsupported image file format: AVIF.
      Check the PHP GD installation documentation if you want to add support.
    - AVIF is not supported, likely because of PHP missing a codec for encoding images. See the change record for more information.

Not sure why I was not seeing this yesterday.

Yes, indeed, we only need to touch presentation.

In the database (or result of calculation, eg. sales tax) me may have a value of “1.131416”. When presenting that value, the display would be transformed to:

Decimals and thousands separators:

Typical English localization:
1.131,416

Typical French localization:
1,131 416

Typical English localization:
10 123.13

Typical French localization:
10 123,13

Currency sign formatter:

Typical English localization:
$10 123.13

Typical French localization:
10 123,13 $

etc.

For measurements units, the database must also store the default measurement unit, most probably loaded from a config. So, if the config for the site is set to imperial units, we can still use a single value in the database and load the unit config at display time.

Example of a Canadian number with a measurement unit coming from default:

Typical Canadian English localization:
1.5L

Typical French localization:
1,5 L

Not sure if core should offers tool to convert unit of measures or use a vendor.

But the UI, if enabled, should let users convert unit of measures easily.

@ishani patel The bug affect only Drupal 11.2.x, not Drupal 11.1.x.

I tried clearing the cache a few times to no luck.

PHPStorm find the GD file with the proper function:

/Applications/PhpStorm.app/Contents/plugins/php-impl/lib/php.jar!/stubs/gd/gd.php

Using PHP Version 8.4.6 or PHP 8.3.16, Drupal Status Report PHP info has:

GD Support enabled
GD Version bundled (2.1.0 compatible)

It also affects user creation.

xmacinfo → created an issue.

xmacinfo → created an issue.

Actually, the best location for locations goes in the Regional settings page:

/admin/config/regional/settings

…inside the Locale fieldset.

At this point, the site is already set up and, even if the site is in English, regional localization can be applied.

USA - English - Imperial measurements
Canada - English - Metric measurements.

So language settings != localization settings.

See the macOS screenshot attached for inspiration.

Finally, detaching language from localization givers more flexibility to the site owner. He may want to use a different set of number separators than what we would expect for his region.

andrewozone: Following your lead, I created a standalone issue for the “Skip to” links. Feel free to update it if something is missing.

I am not setup to submit code changes directly. So I hope the maintainers of the Modern Drupal site will pick this up.

xmacinfo → created an issue. See original summary → .

xmacinfo → created an issue.

xmacinfo → created an issue.

Waiting the Navigation Top Bar module to be available again:

https://www.drupal.org/project/drupal/issues/3486198 📌 Hide the navigation top bar in 11.1.x and 10.4.x Active

@noored Look at the code changes:

https://git.drupalcode.org/project/gin_login/-/merge_requests/39/diffs#n...

is this patch included in latest version ?

No.

xmacinfo → created an issue.

One less critical.

I did update the Issue Summary Current workaround section.

Here is the composer output when using #3091285-131: Composer scaffolding fails when permissions on default.settings.yml or default.settings.php is not writable. → :

…
Scaffolding files for drupal/core:
  - Copy [web-root]/sites/default/default.services.yml from assets/scaffold/files/default.services.yml
> chmod 555 web/sites/default
> DrupalProject\composer\ScriptHandler::createRequiredFiles
…

@bluegeek9 Please note that Drupal.org (not the new parts) is still running on Drupal 7.

Make sure to prioritize Drupal.org Drupal 7 upgrade to new Drupal.

Confirmed.

User profile invoices are using that type of link.

http://www.example/user/user%40domain.tld/invoices/51

which is:

http://www.example/user/user@domain.tld/invoices/51

Using only those two modules:

• Commerce 3.0.1
• Commerce Invoice 2.0

Thank you everyone!

Can we do a clean-up of the Issue tags? I think some of the tags are not relevant anymore.

Well…

NW — If we want to modify the Core composer file or any related scaffold files.
Close (won’t fix) — If we only want to document how to use that Drupal Composer scaffold command #131.

Personally, I suggest to document this in .

xmacinfo → created an issue.

xmacinfo → created an issue.

Thank you for opening this issue.

I think we already have two proposals:

1. “Users with sufficient access rights will be able to override these options. The Promoted to front page and Sticky at top of lists fields are hidden by default, they can be enabled on the Manage form display page.”
2. No text at all.

Not changing the IS until we start the discussions.

Nice work!

I am also recommending to remove the description from the node edit page.

Yes, but if we remove the checkboxes on new install, we do not need to worry about the checkbox being unchecked.

Based on #29338: Hide Promoted/Sticky fields by default in Form display → , we should be marking this ticket as “Outdated” or “Duplicate”.

I think this ticket and your MR will make 📌 "Promoted to front page" for new content types should default to Un-Checked Needs work outdated.

Marking as Needs work; some tests are failings.

xmacinfo → created an issue.

Drupal 11 we can easily disable the Promoted field via manage form display and we have a somewhat hidden API with base field overrides to change the label per content type.

Goal changed over time

The goal of this ticket has changed over time. Now we only need to change the default behaviour, which would be to hide the “Promoted to front page” flag (and most probably hide the "Sticky” flag as well).

We need backward compatibility for existing sites and for developers who want to enable one of those flags. And for new users, make the defaults less complex.

Issue title and summary

Before changing the issue title and summary, let's get more comments.

Same comment here.

To get more developers on Drupal, some "Drupalism" needs to go.

Developers are typically giving a name to the things they create.

- Name of the block
- Name of the variable
- Name of the function
- Name of the field

A label is a tag attached to an item.

So either we continue putting Drupal in a corner with its "Drupalism" or we adopt more generalized standards.

To get more developers on Drupal, some "Drupalism" needs to go.

Developers are typically giving a name to the things they create.

- Name of the block
- Name of the variable
- Name of the function
- Name of the field

A label is a tag attached to an item.

So either we continue putting Drupal in a corner with its "Drupalism" or we adopt more generalized standards.

I think we can add the dependencies through Composer.

You are into something! Thanks!

So core would not need any changes. But the user, with that solution, can change his root composer.json file to fix this issue.

We may need to do additional ajustements for other Dashboard blocks. But we can close this ticket.

Given how websites and uses of Drupal have evolved.

Do you have some data about this?

We should hide those flags for new sites. But leave those discoverable to any developers who are asked to implement the sticky and promoted flags.

…test if we could dynamically delete these from new sites.

Will a new site developer still be able to add the flags (or one at a time) back?

We are now using the 2.x branch.

Fixed. Thank you.

Thanks. I will commit this later.

xmacinfo → created an issue.

Good idea.

xmacinfo → created an issue.

Marking as duplicate.

Move code to the main ticket 🐛 Adjust browse projects page Active .

Let’s merge 🐛 Adjust recipes browser page Active and this ticket together. Both are using the Project Browser module.

🐛 Adjust recipes browser page Active will be marked as fixed.

The module names (links) are displayed dark on dark, so, they are not visible.

Rebased and fixed.

Thank you.

xmacinfo → created an issue.

Pour le fichier CSS à part, tu peux le faire ou me laisser le travail.

Pour activer le fichier CSS uniquement si le module Coffee est activée, il y a un exemple du code ici :

https://www.drupal.org/project/xclaro/issues/3500407 🐛 Adjust dashboard colours Active

Dans tous les cas, je peux faire le travail, mais comme le billet est assigné à ton nom, je vais attendre. Mais si tu ne travaille plus sur ce billet, remplace ton nom par « unassigned ».

@rayand: C'est meilleur que ce que j’aurais fait moi-même. C’est excellent!

Cependant il faut faire un peu plus de travail concernant la gestion des fichiers CSS par Drupal. C'est préférable de ne charger certaines déclarations CSS que lorsque nécessaire. Donc, ici, on demande à Drupal de charger le CSS de la partie Coffee uniquement si le module Coffee est activé.

J’ai documenté ces nouveaux requis dans la description du ticket.

Je vois que ce ticket est encore assigné à ton nom. Tu nous laisseras savoir si tu désires t'occuper de ces nouveaux requis.

Updated the IS with additional requirements.

Bonjour rayand,

Oui, je parle du champs et des résultats de ce champs.

xmacinfo → created an issue.

Fixed. I am using a greening colour as the “field-plugin-settings-editing” class shows that there changes displayed that are not saved.

xmacinfo → created an issue.

xmacinfo → created an issue.

xmacinfo → created an issue.

xmacinfo → created an issue.

xmacinfo → created an issue.

@hestenet We know the priorities are to finish the new home and “marketing” pages running on Drupal 10 and fix the various issues along with launching the pages for Drupal CMS tomorrow.

But what is the official word on the pages that are still running on Drupal 7?

D7 : https://www.drupal.org/about →
D7 : https://www.drupal.org/node/3060 →
D7 : https://jobs.drupal.org/home

Drupal 7 is not supported anymore but the core pages of drupal.org are still on Drupal 7. Can we consider Drupal.org being secure, now?