🇨🇦Canada @xmacinfo

Drupal Core to adopt Gin Admin theme, which has a dark mode.

https://www.drupal.org/about/core/blog/drupal-core-will-adopt-gin-admin-... →

xmacinfo → created an issue.

A new version of the top bar is enable in Drupal 11.2. I will revisit this issue.

xmacinfo → created an issue.

The Commerce Invoice module encounters this bug.

Looks like the Copy button works on a prod environment. Investigating on my side.

Note that I did not test the Copy button in Chrome.

xmacinfo → created an issue.

xmacinfo → created an issue.

xmacinfo → created an issue.

xmacinfo → created an issue.

Added support to the Blackstone colour scheme.

xmacinfo → created an issue.

Thanks for the reopen.

Can you identify which div (with or without an id) that contains the official start of the content?

The fix works, but semantically, we should fix the underlying page HTML.

The <div id="content" class="content__area clearfix"> wraps the whole page, including the header, the main menu. The only thing it excludes is the footer.

So, the skip link does nothing, since the id="content" wraps everything in.

To fix this we need to add a main-content id where the actual content starts.

So, there two things we can do going forward:

1. Remove the skip link
2. Keep the fix link, but fix the target to something like id="main-content", where the actual content starts.

I cannot reopen the ticket, so we will need to create a new ticket.

Instead of disabling temporarily a module, like in Drupal 7, in Drupal 11 or 12 we should expand the uninstall functionality to offer exporting to one or more YML files the configuration(s) owned by that module.

The exported configuration would not be used to perform a complete restore, as in most cases, the exported configs would not cover everything related to that module. For example, disabling a field formatter module, following this, should be able to export its own config but not the field formatter settings of a field, if the “export the module config” checkbox enabled.

A site owner would then be able to reinstall the module and use config import to load one or more config files to recover the module own configs. Here, again taking the example of a field formatter, the recovering of the module’s config would not recover the settings of each field formatter.

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.