🇨🇦Canada @xmacinfo

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?

Be careful on coding standards:

A space is required before “{”.

xmacinfo → created an issue.

xmacinfo → created an issue.

Duplicate.

Tested the field formatter on a date field successfully using Drupal 11.1.

Thank you.

Note that Drupal 7 EOL is today. That may explain the rush to switch to the new home and the marketing pages to Drupal 10.

I prefer an unfinished home page running on Drupal 10 than a home page still advertising running on Drupal 7.

Let's hope that other parts or Drupal.org that are still running on Drupal 7 will switch to Drupal 10 or 11 very soon. Changing only the font for H1 to Hx tags is not sufficient.

Proposed logo.

“Skip to links” targets are missing:

<div id="skip-link" tabindex="-1">
  <a href="#main-content" class="visually-hidden focusable">
    Skip to main content
  </a>
  <a href="#search-block-form" class="visually-hidden focusable skip-link-search">
    Skip to search
  </a>
</div>

Since the design does not have a search form, the “Skip to search” link should be removed.

The “Skip to main content” link should instead target “#block-bluecheese-content” as “#main-content”. Or, alternatively, the “#block-bluecheese-content” div should be renamed to “#main-content”.

Still on Drupal 7

https://jobs.drupal.org will not be secure after January 5th, 2025.

<meta name="Generator" content="Drupal 7 (http://drupal.org)">

Secure

https://api.drupal.org/

Drupal.org not secure after January 5, 2025

It was written in the sky. The most important pages of Drupal.org will not be secure after January 5th, 2025.

Drupal.org pages related to modules and accounts are still using Drupal 7:

If the security teams abandons support for Drupal 7 January 5th, we should not trust using Drupal.org, even tough the login process migrated away from Drupal 7. The most important pages of Drupal are still on Drupal 7, including user profiles.

If the Drupal 7 used on Drupal.org gets security fixes, those fixes should be offered for free and a new version of Drupal 7 should be released.

New.Drupal.org

Note that this does not affect the new pages built for the https://new.drupal.org running on Drupal 10. Those pages are mostly hosting a new site running on Drupal 10 with many redirections to the Drupal 7 site.

In other words, a new frontend built on Drupal 10 with a new theme with a not secure Drupal 7 backend.

Currently, only a few pages have been created (not migrated) on Drupal 10 and they are visible with the “new” prefix:

https://new.drupal.org/

All the main functionalities of Drupal.org are still on Drupal 7.

<meta name="generator" content="Drupal 7 (https://www.drupal.org)" />

This means that the most important pages of Drupal.org will not be secure after January 5th, 2025.

xmacinfo → created an issue.

xmacinfo → created an issue.

xmacinfo → created an issue.

xmacinfo → created an issue.

Marking this issue as a duplicate.

@rahul17 Let's split the gitlab-ci in another ticket. Also, if there are no code change, we will keep Drupal 8 support.

What I can do is merge !8, not !7.

Your patch does not work.

@w01f: Thanks for trying out xClaro. But note that in xClaro I am not using the same dark colours as we can see in the draft mock-up displayed in comment #12. The official dark colours of Claro should be defined by the Claro maintainers, and, hopefully, developed and release before we hit Drupal 12.

xmacinfo → created an issue.

xmacinfo → created an issue.

xmacinfo → created an issue.

I like very much seeing all the new drupal.org look running on top of Drupal 10 and that all those pages are displaying up-to-date information, including the launch date of Drupal CMS.

Keep up the good work!

@ressa Thank you for raising the issue about Slack. I agree with you all the way. And the points you raised are the reason I never install Slack on any of my computers or devices.

Forum links should direct to a real forum.

@fkelly12054@gmail.com I agree. As soon as the forum was removed from Drupal home page a long time ago, I stopped going over there to answer questions.

The home page needs to display that there is a live community and exposing a forum block would display that.

But at minimum a link to the forum is needed.

I love very much the new design and all the displayed information. But the design is static and will always display the same information. Not sure newbies or regular users will revisit the home page regularly.

I like very much the new home page.

But, is there work to personalize to some extend the home page for a logged in user?

More work is required to support the activation of the Navigation Top Bar module correctly.

Currently, the Navigation Top Bar is visible only on small breakpoints.

Leaving as “Needs review” for now.

The “Expand sidebar” text is now dealt with in ✨ Replace the mobile horizontal sidebar with a corner widget Active , in which the actual display of the label is hidden.

The “Expand sidebar” banner styling is now dealt with in ✨ Replace the mobile horizontal sidebar with a corner widget Active .

xmacinfo → created an issue.

xmacinfo → created an issue.

Why do you require Devel in the Composer file require-dev section? In your code, your code already checks if devel is installed.

if ($this->moduleHandler->moduleExists('devel')) {

Even if it is in require-dev, I try not to impose dependencies, even the most popular ones.

Text changed to match the subsystem maintainer review.

Thank you!

Thank you!

xmacinfo → created an issue.