🇨🇦Canada @xmacinfo

I prefer the original throbber (SVG rendered). It looks like a single-hand clock.

The main question being, though, can the themer change the throbber color or better yet, use her or his own SVG file?

I use statistics on its own for internal standalone metrics with views integration.

That's my use case as well.

Adding last comment reference to the Related issues.

@Collins405 It's sad to see you go away. But you are not the only one moving their large asset of Drupal 7 sites to another platform.

However, I really like starting new projects on Drupal 10.x.

Currently these two things are separate by design.

Why are those two sorts separated by design? I would expect the same sort results for both.

Please open a new ticket and relate this ticket to the new one.

I confirm that “SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;” works on Cpanel with MySQL 5.x.x with Drupal 10.2.

Thank you.

Please read this documentation:

https://www.drupal.org/docs/upgrading-drupal/drupal-8-and-higher#s-2-upg... →

@Martijn de Wit

Yes, I did. But that does not create a theme inheriting from a base theme.

Given the popularity of SDC, it not making it past experimental may also require escape hatches for the human(s) that 👎 it...

Experimental modules are not in a popularity game. Those Experimental modules exist to either try them out and make sure the whole stack work as expected or to use them, provided the site maintainers agrees to some risks and that they are willing to deal with those risks, if any arise. SDC is an exception, as, once stable, it will not be a module.

I am interested to know about the impacts of converting some Twig themes to SDC in Stable. Would that break existing themes using Stable 9 as a base theme? Or will SDC be transparent to any themes expanding upon Stable?

I see in our profiles that English is not the first language of either of us. I am interpreting the use of "should" here as "my preference is". Let me know if that is wrong.

The way I use “should” is to to indicate correctness, like in English. In French “should” = “must”, which misses some nuances between the two.

In other words, we, the Drupal community, should let developers use SDC or plain Twig templates. Thankfully, we can already do that. 😀

As a developer, and when chatting with other developers, we do not always want or need to use a components system; we create a bunch of templates and add CSS/JavaScript and that's it. However, most front-end devs (we can include themers) prefer using well define reusable components. That was, until now, hard to do in Drupal, and varied a lot between developers and themes teams. SDC helps standardizing components usage and their documentation and will push Drupal to new levels. I agree with that.

The core community wants standards and good documentation. I agree with that.

So the problem, which is not a problem, is, as a developer, do I create Twig templates as I did since Drupal 8 and use a few CSS files loaded through libraries, and be done with it, or I am forced to use the new SDC. This is not a problem as you told me. 😀

When building a custom them, we (the dev team on that project) will be able to use either SDC or plain old Twig templates.

Which leads to base themes. Can we use a base theme built on SDC (here I think about Olivero) and replace, let’s consider, component A and B and replace those with plain old Twig templates? If yes, then my problem is solved and I need not worry anymore.

I like Olivero so much that I use it as a base theme.

As I mentioned in another ticket, when using Olivero as a base theme, will we be able to remove some or all SDC components and replace those with regular Twig templates?

In general SDC components are welcome. But I still expect to use the current theme layer as is, even if I use Olivero as a base theme. We may still built themes with or without SDC components. But if Olivero is forcing us to use SDC, some of us will not be able to use Olivero as a base theme.

Overriding an SDC component with another one makes sense.

But, actually, my question is more like:

Can I override the need for a SDC component. In other words, override SDC altogether.

For example, I create a new theme based on Olivero, but I want to use regular templates instead on a component. Can this be done or will I be locked in SDC?

I am available to be a maintainer of this module and create a new release.

This is RTBC and we have an agreement.

Composer

@klausi I was proposing the creation of composer packages for the Drupal 7 security releases only because Gitlab has a top-notch built-in package manager. We only need to define a “.gitlab-ci.yml” file at to root of each project file. And then in each application built with Drupal 7, add a composer.json file in which we define the location of the package repo (gitlab).

I find that Composer is a good alternative to Drush to download a module.

One example is:

composer require D7Security/devel --prefer-source

… to download Devel with the included .git folder. With that module, work fixes, commit and push back to Gitlab.

Of course, I can simply do a “git clone https://gitlab.com/d7security/devel” to work on fixes, commit and push.

That being said, I can live without Composer on any Drupal 7 site.

Progress

The goal of this project is clear. Help generate security releases of Drupal 7 modules in use that this new team accepts to support.

I like the progress so far.

@Joseph

The goal of @klausi project is well-defined. The scope is documented. And the values are written.

That should not prevent you (or us, globally) from creating Drupal 7 post-EOL support in a NEW ticket, or new initiative. I will probably join you in that effort.

Please let's not mix the goal of the Security team (-> expand Drupal 7 security support) with the wider Drupal 7 (-> Classic) effort. That last effort is opened to many different expectations and hurdles.

Would you mind opening another ticket on d.o. or, better yet, on a Gitlab instance where we can discuss D7 life after EOL?

I encourage everyone interested to join the Gitlab project made by @klausi. There is now a wiki and code.

Well, Views is still maintained, so it is not a good example. But do we know about some Drupal 7 modules that need to be addressed by this project? Will that list be automatically generated or maintained?

@klausi Please add a wiki page or a Readme file to Gitlab and document the common set of values over there. I agree with those values and it makes very clear the direction you are taking is regards with security updates only. You should be able to edit those values regularly when needed.

Sadly, for numerous reasons, I do not use Slack. But that should not prevent you to use it.

From now to the official D7 EOL date, there will certainly be more discussions about forking Drupal 7 (or Classic) or adding new features to Drupal 7 (including full support for PHP 8.3 or newer versions), but all those discussions will not happen here and be redirected to other venues.

Also, in addition to Views, were you able to identify a first set of Drupal 7 module candidates for the d7security effort?

I like the idea to start on Gitlab.com and migrate away tp a self-hosted instance once ready (that migration feature is built-in).

Gitlab has its own ticketing system so that we already replace this ticket on d.o. with ticket(s) on Gitlab.

But we need a way to make this official and the initial reporter (@klausi) of this ticket could create the project on Gitlab and do the official announcement. He would then be able to set the project public and let people join and contribute.

There will be many things to setup on Gitlab and we can use the Gitlab ticketing system directly to document all the things needed to be set up. For example, document the proper namespace to host all Drupal 7 modules and create the composer packages (namespace/modulename) and other tasks.

xmacinfo → created an issue.

@markdorison you can install Gitlab Community Edition anywhere. When using your own server the "50,000 compute minutes" does not apply.

Of course, a server like the one proposed by @joseph.olstad is not free. But it is usually relatively cheap. Although backup instances should also be planned.

Some public projects are being hosted on Gitlab.com SAAS. While some others public/private projects are using their own Gitlab instances installed on their very own servers (VPW, metal boxes or cloud [including AWS]).

We need to define a governance first, and then define funding and all the technicalities, including any Gitlab instances, ownership and backups.

There should be no expectation that core committers or the Sec Team do anything but wontfix D7 issues, and every effort should be made to minimize the filing of such issues on d.o.

My biggest fear is Drupal.org itself. We all know it is still running on Drupal 7 and that the security team may deliberately choose not to fix any security issues in Drupal 7 core or any Drupal 7 contrib modules used by drupal.org. Or they may prefer to privatize the drupal.org codebase and not release any security fixes to core or contribs.

There is a Drupal Symfony version of Drupal.org in development, but will that version be ready before D7 EOL?

I prefer Github because more developers already have accounts there, lowering the bar of contributing.

I am not sure that this is true or that this is pertinent. Gitlab is easy to use and the bar is very low already.

On all Drupal project I worked with, 99 % are hosted on Gitlab and 1% on Github.

You'll still be free to use it or not.

If I build a theme based on the Olivero SDC variant, will I be able to override some or all SDC components included in Olivero once SDC is incorporated in Drupal (not a module anymore)?

xmacinfo → created an issue.

@almunnings Please open a new issue and put your patch there.

Even when SDC is marked as stable. SDC must be optional and not be forced into any existing core theme or core modules.

We still want to be able to install Drupal without enabling SDC.

As I mentioned in other SDC issues, SDC should always be optional and not enabled by default by any existing core theme or core modules.

I'd prefer that you create a clone of Olivero rather than force Olivero to use SDC.

Any dependency between Olivero and SDC must be optional so that a user is not obligated to enable SDC just to use Olivero or take Olivero as a base theme.

Any dependency between Olivero and SDC must be optional so that a user is not obligated to enable SDC just to use Olivero or take Olivero as a base theme.

Do you know any other platform that handles internationalization and localization on par with Drupal? I may try those out.

Like Damien says:

Drupal 10 has been out almost a year, this plan was announced well before that, there's no excuse to not be at least getting ready for the upgrade now.

Multiple D9 sites will not move to D10, at least in the short term. But for unknown reasons, multiple installations are stuck in D9 (I include myself, but I will eventually move all my sites to D10 when I have time, hoping the EOL for D9 will not bite me). I can only speculate on why the majority of D9 sites have not migrated yet to D10. If it is only a question of time, those sites will migrate to D10. If it is because of funds or team changes, there might be an additional delay before they finally move to D10.

Dependencies are hitting their own EOL

Yes, Drupal Symfony forces us to keep pace with Drupal latest versions and we should upgrade as soon as possible. That's the type of life that was chosen for Drupal Symfony since the beginning. It's just that for some teams, the cost of the regular upgrades to major versions is not always planned.

Drupal 7 does not suffer from that problem, having no dependencies. I am glad to see that after so many years it is still running finely and with great performance. But I am also sad to see it abandoned, even if I never use it to create new Drupal sites.

@freelylw What I see in the usage graph is that Drupal 10/11 has a better chance of disappearing than Drupal 7.

https://www.drupal.org/project/usage/drupal →

We have an EOL on Drupal 9.x while it is still the main driver before version 10.x. Although it is considerably easier to migrate from 9 to 10, it looks like a vast majority of sites may not have the ability to upgrade for one reason or another.

Instead of pushing too early for EOL, there should be some considerations taken to understand the roadblock that users are facing, preventing them from upgrading.

For Drupal 7 sites, if they are not upgraded to Drupal Symfony by 2025, those sites will probably continue to live as is for a few years more, until their owners either migrate to Drupal Symfony or migrate away on another platform.

For Drupal 9, the community should push back the EOL for at least one year and do a survey to understand the behaviours of the users of Drupal 9 to see if anything can be done to help them go to Drupal 10.

I have seen many instances of Drupal 7 or 9 sites that were funded for development, and maintenance. But the same sites are left without any funds to upgrade to the next major versions.

With all this said, the main solution is to push back EOL for both D7 and D9 sites.

Did you run that patch on an actual installation?

Although we need to fix coding standards, a patch must be tested by its authors.

I had to revert this because of a major error:

TypeError: Drupal\twig_backlink\TwigBacklinkTwigExtension::__construct(): Argument #1 ($language_manager) must be of type Drupal\Core\Language\LanguageManagerInterface, Drupal\Core\Routing\CurrentRouteMatch given, called in /Users/jrblier/web/Sites/portable.bd.livres/web/core/lib/Drupal/Component/DependencyInjection/Container.php on line 259 in Drupal\twig_backlink\TwigBacklinkTwigExtension->__construct() (line 59 of modules/contrib/twig_backlink/src/TwigBacklinkTwigExtension.php).

Of course, the merge request was not marked as RTBC, but the original poster should do a minimal installation.

I will accept a new MR or a patch for review.

xmacinfo → made their first commit to this issue’s fork.

Amazing! Thank you to everyone who worked on this issue.

Drupal 7 (Classic) and Drupal (8 to 10) Symfony now have both around 400,000 active installations.

Drupal Classic still sees a steady decline month over month, essentially by abandoning the platform or switching platforms. Most of the Drupal 7 sites that were planning to move to Drupal Symfony already made the move.

Dries, Acquia, the Drupal association do not want to invest in long-term Drupal Classic, even if Drupal Classic is a fully functional development platform that can still live on for multiple years and still get enhancements and compatibility fixes over and over to support newer PHP and MySQL versions.

Drupal Classic already has good maintainers to take care of it. But without a good infrastructure and funds to support Drupal Classic, the maintainers won’t be able, alone, to move Drupal Classic forward.

It is very sad to see a perfectly functional platform that does not need a ton of dependencies to be left to rot.

Anyone who wants to can for Drupal Classic, but can we reach a critical number of developers to form a viable community?

As for Backdrop CMS, a regular Drupal 7 site can be upgraded directly to Backdrop. But as Joseph mentions, there are many multilingual sites that cannot move over to Backdrop CMS. So Backdrop is not a solution for all Drupal 7 sites; it's only one option.

So, without a clear group of people who wants to fork Drupal Classic and maintain the required infrastructure, Drupal Classic will die.

A few people here are ready to fund Drupal Classic; there is still some hope.

Closing the issue early on.

The fix is already in the 2.1.x branch of this module. Marking this as a duplicate.

xmacinfo → created an issue. See original summary → .

Using Backup and Migrate to restore a file (related to issue https://www.drupal.org/project/backup_migrate/issues/3264580 🐛 MySQL collation complexities leads to backup incompatibilities Active ), I expected to see a confirmation message.

I did not see any message on the screen.

In searching for another confirmation I looked at the watchdog and I did not see any entry related to restore or any Backup and Migrate entries.

The only way I was able to confirm that the Backup and Migrated did the restore successfully was to look at the content and check for recent changes.

Previously, utf8mb4_general_ci was the default collation. Because the utf8mb4_0900_ai_ci collation is now the default, new tables have the ability to store characters outside the Basic Multilingual Plane by default. Emojis can now be stored by default.

— https://www.monolune.com/articles/what-is-the-utf8mb4_0900_ai_ci-collation

I got hit by this issue a couple of times and now I learn that utf8mb4_0900_ai_ci is the new default.

Backup and Migrate should not fail here and automatically convert default collation from utf8mb4_0900_ai_ci and utf8mb4_general_ci and vice versa. The implementation might not be simple. Automated conversion should be limited only to the former and new default MySQL collations.

MySQL snippets that may help

# For each database:
ALTER DATABASE database_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;
# For each table:
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
# For each column:
ALTER TABLE table_name CHANGE column_name column_name VARCHAR(191) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
# The above code is for 'VARCHAR' column. The exact statement depends on the column type, maximum length, and other properties.

Ther is also the possibility of doing a database backup directly to another collation using the --default-character-set flag.

Another solution is to remove the whole default.settings.php file altogether and document the default values in the README.md file.

But if we want to keep that file, we can rename it to default.settings.txt so that PHP will not try to execute it.

suggest supports only text and not version numbers. But at this point, a developer can install any version of Drush that support his Drupal installation and not a specific version.

But I feel we will quickly move to drupal-recommended as soon as we add code that needs Drush.

I agree 100% with #56 and #58.

Let’s get this move forward. Let’s add drush/drush to the drupal/recommended composer file.

For another issue discussion, though, which command will we register in the command-line?

$ drush for Drush
$ drupal for Drupal console (not maintained anymore)

Can we hijack $ drupal?

I think SDC should be optional.

I agree 100%. There are many D7 projects that can't be upgraded. I see many in the government.

Multiple organizations should be willing to fund Drupal Classic (or a new name). So that Drupal Classic should be able to survive and be maintained under the Drupal Classic name (of Dries approves) or under a new name.

Once things settle down, Drupal Classic (or a new name), will get new users and developers.

I am currently using the Darcula Drupal admin theme (1.0.0) and I find it quite accessible.

But I prefer the color palette proposed for this issue. And I like very much the mockup made in #12.

I think the goal of this issue is to finalize the color palette and background layers. Some mockups can be created to give us an overall view.

Areas of concern:

• We would not add any Drupal branding to the Dark version of Claro.
• Color contrasts should meet accessibility industry standards.
• Font weight may differ from Claro is some areas to improve readability.

Overall, switching from Claro light or Claro dark should use the same screen estate, same text size, etc.

And, of course, we won’t create a new dark theme based on Clare but instead support both light and dark in the same Claro theme files.

Any additional work, for example fixing a button accessibility code, should be done in a separate ticket.

composer update drupal/string_field_formatter will update only to the same branch, here only to 1.x.

To load a more recent branch (i.e. from 1.x to 2.x you need to use the require command:

composer require 'drupal/string_field_formatter:^2.0'

Actually waiting for this core issue to be resolved:

https://www.drupal.org/project/drupal/issues/2546212 🐛 Entity view/form mode formatter/widget settings have no translation UI Needs review

We can remove “orientation change” from the list I made.

But there is no clear consensus on that one. See #194 and #192.

Creating a good-looking and usable web page/web app in both orientations requires more work. But using responsive CSS code helps to build pages that adapt to most screen sizes.

Personally, on an iPad, for example, I want to be able to use a web page/web app in any orientation and not be left lock-out in one orientation.

Still, should it be?

  halt-on-fail: false

https://www.drupal.org/psa-2023-06-07 →

This will be the final extension.

I agree 100%. Don't block innovation over a missing space.

templates approach will lead to outdated files and more errors on updates because user's will forget to update files

I would expect Composer to scaffold the files inside templates. Thus all those files, managed by Composer scaffold, inside the template folder, will always be up-to-date.

I suggest to scaffold the default.settings.php file in sites/templates instead of sites/default. Same mechanism. So no outdated files.

Another solution:

Have Composer scaffold core/assets/defaults/default.settings.php to sites/templates/default.settings.php.

This new sites/templates folder would not be executable and contain only templates or examples files.

We could use examples instead, too. So either:

sites/templates/default.settings.php
sites/examples/default.settings.php

OK. I like that as well.

We let Drupal do its own hardening while we modify the Composer scaffold plugin to :

not apply the scaffolding for non-essential files, such as sites/default/default.* if file system permissions do not allow Composer to overwrite them.

.

Should the Composer scaffold plugin display a notice when it skips a file due to insufficient permissions?

The problem here is the main default folder permission, as in sites/default/default.services.yml.

We need to somehow let Composer deal with the permission of the default folder. For example, if I manually set sites/default to 777, Composer should be able to run and scaffold the files like default.services.yml or default.settings.php.

Please note that this issue summary mentions this in the historical context section:

If you've installed and run Drupal, the sites/default directory receives permission hardening. This can break the scaffolding plugin.

It's not recommended to run Composer as root. But is there a way to let Composer change the permission of the default folder temporarily, without introducing any security holes? Should Composer scaffolding be responsible for the permission hardening and let Drupal check only if the default folder is hardened?

Work done offline and push to commit 6efed104.

https://git.drupalcode.org/project/twig_backlink/-/commit/6efed104e9d7c0...

Please use an existing issue to comment about a patch.

Currently, this Twig extension does not support adding conditions to filter the referenced field.

Is the dark mode started somewhere?

I did not find the answer for this:

In Single Directory Components, where would we store SVG files in /components and how would we call those SVG files? Can we support both SVG files (file.svg) and inline SVG (

@bnjmnm: I agree with you. However, Drupal have experimental modules and SDC is targeted to be experimental. It's not all experimental that end up being popular, but at least it let the community gauge the usage of those experiments.

@acbramley: Thanks for the clarification. Let’s see if we can have usability and accessibility reviews.

@acbramley: I am a bit confused. Does this issue require more work or is it RTBC?

Yes, we need some way to refresh the calculation instead of deleting an order and recreating it. It could be a button available only to a user with a specific role.

In my use case, I created an order and forgot to add the billing information. I placed the order too quickly before checking if everything was fine.

I edited the order to add the correct billing information, but the taxes won't refresh.

@DamienMcKenna Using your patch in #15 solves the issue.

We have a lot of custom code. I will try to find which variable is passed as an argument (argument 7). But I am not sure how much time I will be able to allow for this.

I am hitting that error updating the Date module from 7.x-2.10 to 7.x-2.14.

TypeError: Argument 7 passed to date_formatter_process() must be of the type array, null given, called in /srv/www/………/sites/all/modules/date/date.field.inc on line 215 in date_formatter_process() (line 223 of /srv/www/………/sites/all/modules/date/date.module).

We have a lot of custom code.

Not sure if I will use the patch in #8 or if I will be able to investigate the piece of code that triggers that error.

Amazing!

I am looking forward to seeing a component that also loads its SVG files (or any image file format). For example, to help create buttons using SVG icons.