🇨🇦Canada @xmacinfo

xmacinfo → created an issue.

Thanks for the quick resposte, daffie.

Let's plan to implement this:

Database support for JSON
Available
Drupal requires databases that support JSON storage.

or

Database support for JSON
Not available
Drupal requires databases that support JSON storage.

That last one, hopefully, mostly not visible ot users.

@debrup Please check the Devel Github issue queue to see if this is already reported. If not, open a new ticket over there:

https://gitlab.com/drupalspoons/devel/-/issues

It looks like that Drupal can be installed without JSON supportL

if (!Database::getConnection()->hasJson()) {
  $requirements['database_support_json']['value'] = t('Not available');
  $requirements['database_support_json']['severity'] = REQUIREMENT_ERROR;
}

So the status report will display either:

Database support for JSON
Available
Is required in Drupal 10.0.

Note that I did not try to install Drupal on top of a database without JSON support. But by ready the code, installing Drupal without JSON support is possible, unless the installer halts early on, displaying a missing requirement error message.

or

Database support for JSON
Not available
Is required in Drupal 10.0.

Based on that information, we should simplify to:

Database support for JSON
Available

or

Database support for JSON
Not available

Looking again at at the status page, we have:

Database support for JSON
Available
Is required in Drupal 10.0.

To be consistent with other requirements status we can simplify to:

Database support for JSON
Available

However, since this JSON support is “Required” for Drupal 10 and 11, we might prefer:

Database support for JSON
Enabled

As for the correct solution to implement (change of text) or the removal of the confirmation status, I would defer to the database product manager.

Who is the database product manager?

On the MySQL side, Drupal 11 requires “MySQL/Percona 8.0”.

https://www.drupal.org/docs/getting-started/system-requirements/database... →

If MySQL 8.x supports JSON by default, I tend to agree with longwage.

Devel is also working on exposing their menu in the Navigation. See the Github issue linked above.

Before going further, we may need to check with them the best course of action.

I did not try your code yet, though.

Devel integration to Navigation ticket:

https://gitlab.com/drupalspoons/devel/-/issues/530#note_2206580745

Actually, Devel itself should expose it's menu directly in the new Navigation menu. But I would find it more convenient to see the Devel menu injected directly in the Tools (managed by Navigation Extra Tools) menu.

I would expect to see the user image in the expanded panel, at the top (above or below the user name), inside or near the div toolbar-popover__header.

As for the main navigation, I consider that consistency is better. So in short, for the main navigation menu footer, I prefer the statu quo; using the current icon/text.

xmacinfo → created an issue.

Fixed the “white space appears above the Navigation footer and the main Navigation links” part.

Leaving this issue as “Needs review” for the “Notice the white “Expand sidebar” banner at the top” part. Not sure yet if xNavigation needs to style the white “Expand sidebar” banner or use a colour defined in the colour schemes.

xmacinfo → created an issue. See original summary → .

xmacinfo → created an issue.

“Expand toolbar” is too generic, and not clearly linked to the new Navigation toolbar. It would be best to write “Display admin menu”. That way, no need to add a logo.

I prefer “Display admin menu”, but “Expand admin menu” also work.

xmacinfo → created an issue.

Added additional colour schemes, including one called Core.

xmacinfo → created an issue.

xmacinfo → created an issue.

An unrelated test fails. Leaving the status as Needs review for now.

/core/modules/system/tests/src/Functional/System/StatusTest.php fails.

There's also seckit which also can set the CSP headers.

Can we set the CSP heasers on both public and private served files? Is Seckit able to add CSP headers on files?

@nmangold Thanks for all the clarifications. I try to summarize the issue with assumptions and what needs to be done.

So:

• The node $links are already styled (but not shown to respect design decision).
• There is no need to add a theme settings.
• We currently need to create a sub-theme and we want to avoid this.
• Existing config can be used.
• Make Olivero hide (not exclude) the node Links field by default in the content type teaser
• Support already installed sites with a hook post update to hide by default the node links field

Once fixed the user stories would be:

"As a product manager for Olivero, I want the node Links field to be hidden by defautl."
"As a site builder, I want to set the node Links field to be visible via the content type teaser configuration."

I think the correct plan is:

1. Add a setting in Olivero with “Hide 'Read more' link in teasers.”, which would be enabled by default.
2. Change the teaser template to respect the setting.
3. Style Olivero to support the display of $link when the setting is set to show links.

That way, user do not need to create a sub-theme based on Olivero.

I like the way the discussion is moving to. But the main question are:

Do we plan to implement the change in Olivero without the need to have a sub-theme?

Or, to display the links, we need to create a new sub-theme based on Olivero?

In short, a single theme (Oiivero) or two themes (Olivero and the sub-theme)?

sites will likely already have a template override

Having template overrides also mean working in another theme based on Olivero. This requires templating or hooks overrides knowledge.

Another option to expose this decision more clearly is to have a theme setting which ultimately drives the Link field display configuration, e.g. "Hide the node 'Read more' link in teasers.", which would be enabled by default.

I think this is the best solutions for Olivero users who do not need to create a sub-theme based on Olivero. With an option (on or off), a user does not need to know about templating or hooks.

However, if the settings is off or hidden by default, when switched on, will it be styled correctly? If switching it to display the the visual is not on par with the rest of Olivero, the user will be forced to create a sub-theme.

But, based on previous conversation, we might not see a styled version of the $links when a user set the setting to “Display the node 'Read more' link in teasers”.

The previous error may be due to having the contrib version of Navigation loaded on an old install of Navigation Extra Tools, which fixed the dependency in a never beta release.

xmacinfo → created an issue.

OK. It works out of the box. Thanks.

I see. I'll try to see if I can install it later.

I think that rebuilding the theme registry should be done in the install file in a hook_update; a one time rebuild at installation or when updating to a newer version.

xmacinfo → created an issue.

Logo reviews are appreciated.

Left this issue as “Needs work” to create the branch and commit.

Planned logo for this project.

xmacinfo → created an issue.

Actually no. It:s not the way the module was built to support.

Composer must also automatically fetch https://github.com/ariutta/svg-pan-zoom/. Once you test this, you also need to update the READMe.md file.

xmacinfo → created an issue.

I am not able to replicate this issue.

xmacinfo → created an issue.

xmacinfo → created an issue.

This change was made directly in the Gitlab IDE.

xmacinfo → changed the visibility of the branch 3480276-permission-restricting-access to hidden.

Merged. Marking as fixed.

xmacinfo → created an issue.

Marking as “Needs review” for now.

xmacinfo → created an issue.

xmacinfo → created an issue.

xmacinfo → created an issue.

xmacinfo → created an issue.

Please confirm that we have enough information captured (IS and comments) in this ticket to mark it as fixed.

Cleaning up the Issue Summary might help discover this issue, though.

Nice work @ajab natshah!

Adding your comments to the IS. Feel free to update it at your convenience.

Agreed. Issue summary updated.

This is plainly an issue about the conflict between nice and flat design, mostly emerging from Photoshop/Figma mindset and the flexibility of a full CMS where plenty of overrides exist in settings.

1. The design (photoshop/figma) does not take into account multilingual sites, whereas Drupal is a multilingual site: hence, there are no designs for the language switcher.
2. The design (photoshop/figma) does not take into node display extensions, mostly going in the $links, for example Statistics (more modules put their information there), whereas Drupal is a multilingual site: hence, there are no designs for $links or setting to show/hide $links in the theme.
3. The design (photoshop/figma) does not take into account site Slogan, whereas Drupal offers site Title and site Slogan: hence, there are no design for site Slogan.
4. The might be other examples.

Fortunately, Olivero can evolve to be more user-friendly. For example, from D10 to D11, Olivero added support to colour change with a setting. We can evolve more Olivero by creating a setting for $links and other enhancements.

However, Drupal still support base themes. So instead of using Olivero as the main theme and using its limited features, we can create a new theme and use Olivero as a base theme.

For some sites, I would prefer using Olivero directly as its setting for colour change is quite good for those sites. But currently, I still need to create a theme to complement the missing features in Olivero, especially the Language Switcher bloc.

Tested the dev branch successfully.

composer require 'drupal/fakeobjects:1.x-dev@dev'
./composer.json has been updated
Running composer update drupal/fakeobjects
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies
Lock file operations: 2 installs, 0 updates, 0 removals
  - Locking drupal-ckeditor-libraries-group/fakeobjects (4.22.1)
  - Locking drupal/fakeobjects (dev-1.x 31878af)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 2 installs, 0 updates, 0 removals
  - Syncing drupal/fakeobjects (dev-1.x 31878af) into cache
  - Installing drupal-ckeditor-libraries-group/fakeobjects (4.22.1): Extracting archive
  - Installing drupal/fakeobjects (dev-1.x 31878af): Cloning 31878af419 from cache

$ libraries ls
fakeobjects

After enabling the module, the Status Reports displays:

FakeObjects Plugin detected

I was not able to try this to check if the package was downloaded to the library folder instead of the vendor folder before doing the commit. I faced a catch-22. Information on proper testing that type of composer.json changes would be appreciated.

However, this change looks a straightforward change so I did the commit.