Quantcast
Channel: Issues for Drupal core
Viewing all 300835 articles
Browse latest View live

Refactor Claro's fieldset stylesheet

$
0
0

Problem/Motivation

This is part of the CSS modernization initiative.

Steps to reproduce

The stylesheet at https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/claro/css/components/fieldset.pcss.css needs to be refactored to make use of modern CSS and Drupal core's PostCSS tooling.

Proposed resolution

Use CSS Logical Properties where appropriate
Use CSS nesting where appropriate

Remaining tasks

We need two patches. One for Drupal 9.5.x and one for Drupal 10.0.x
We need a followup issue to refactor this component in Drupal 10.0.x to make use of component-level CSS custom properties and remove IE specific style definitions.

User interface changes

None. There should be no visual differences.


Update module should send notifications on Thursdays

$
0
0

I recently set up update status notifications on a D6 site, and realised I was getting the notifications on Tuesdays. Since SAs go out on Wednesdays this means it could be a full week between the SA and the notification.

Currently you can specify the interval for checks/notifications, but not the day of the week (unless you manually change the tracking variable to a timestamp on the day you want).

Seems like it would make more sense to allow choosing the day(s) of the week to get notifications on, as well as forcing a refresh of the data just before sending the notification.

Provide for additional identifying fields in IP Address Blocking

$
0
0

It would be nice to have additional fields that admin could fill-in for each IP Address that is blocked in order to keep track of which user (or which entity) is being blocked. At a minimum, the username would be helpful, but perhaps other identifying fields might be useful.

[Meta] Discuss how to merge new modules into core

$
0
0

This summer I'm likely going to be working on #229568: Pathauto in Core and I'm seeing several options for how I can propose merging Pathauto (or other potential modules) into core.

  1. Lieutenant model: This is my preferred option. Pathauto would continue to "live" in contrib and would be "bundled" in the core repository from the 8.x-1.x branch. Is this possible it all (maybe using git sub-modules)? If so what changes would we need to make to have this possible? It was brought up at Dries' core conversation in Denver but it hasn't really been discussed since then.
  2. Normal merge: When we merge modules into core there can be two different ways it can be done.
    1. Enhancement: Merge into an existing core module, for example, merge Pathauto with path.module. How does this work if someone wants to turn off automatic aliasing (or whatever feature the merged module adds)?
    2. Add as-is: This would copy/paste all of Pathauto's files into core/modules/pathauto and if approved enable Pathauto as part of the standard install.

I would first just like to really discuss if the Lieutenant model is possible, feasible, and something that Dries/catch would agree to doing because that is highly my preferred option. I just don't want to waste my time attempting to merge in Pathauto if it's not going to be a plan that I don't agree with.

Regardless of how it is merged in, we would continue to probably use a core fork sandbox and provide patches based on diffs of that sandbox compared to 8.x.

[META] Decouple layouts from themes

$
0
0

Problem/motivation

Drupal themes just ship with hardwired layouts. If users want to apply different layouts to different pages, the theme code needs to be modified. There are solutions working around this whole system by overriding the page rendering and swapping out built-in regions and blocks altogether.

Solution proposal

We should support this use case much better by declaring layouts (and regions per layouts) explicitly within the theme. Then that should allow users to identify which layout to use per page and would need to shift blocks to relate to layouts instead of themes. The proposal is to:

  1. #1787846: Themes should declare their layouts - Identify layouts from themes either via .info file properties or plugin definitions or .yml config files or an automatic tpl.php discovery mechanism. Possibly also make themes define regions for each layout (although we can probably assume the same regions across all layouts in a theme for now).
  2. #1839278: Add layout template demonstration - Demonstration of layout templates defined by modules and themes for user review.
  3. #1841584: Add and configure master displays - Edit master layouts with global blocks
  4. #1840500: Add simple blank page creation capability - Introduce simple page creation feature with fixed path and block placement.

[META] Add editable responsive layouts to Drupal core

$
0
0

This is a tracking (meta) issue to organize issues around adding editable responsive layouts to Drupal 8 core. These modules have been actively worked on in contrib for both Drupal 7 and 8, so some are readily ported to Drupal 8 and needs reviews while others need more work.

First and foremost there is considerable abstraction work going on to introduce layouts as their own concept in Drupal 8 core. Some of the work is in core, but there is mo to do, see #1787634: [META] Decouple layouts from themes for the tracking issue for that.

The responsive layout builder was originally built for Spark in Drupal 7 contrib to be proposed for Drupal 8 core and is readily testable with a Panels integration in the Drupal 7 Spark distribution: http://drupal.org/project/spark (Drupal 8 versions also available with up to date patches and modules). The responsive layout builder consists of the following pieces:

  1. A module to manage a dynamic list of regions. This is needed because editable layouts support adding any number of regions naturally. This is implemented in the http://drupal.org/project/region module. Core patch for Drupal 8 inclusion at #1813910: Add region module to Drupal core (for editable responsive layouts)
  2. Breakpoints to be able to have different layouts for different presentation sizes. The Drupal 7 implementation for this was in http://drupal.org/project/layout and a temporary Drupal 8 implementation exists at http://drupal.org/project/bunnypoint, but a much more mature breakpoint API module is in core now (#1734642: Move breakpoint module into core). The layouts and grids depend on this now.
  3. Grids to serve as snapping guides for easier and best practice layout creation. Grids are individually created but can be assigned to breakpoints so that layouts can relate region placement to the grid columns for each breakpoint. The existing Drupal 7/8 implementation for this is in http://drupal.org/project/gridbuilder. Issue to add into core at #1816650: Add swappable (dynamic) grid systems to core
  4. Responsive layouts themselves, which relate a list of ordered regions to grid columns for each breakpoint applicable to the layout. This is the most extensive user interface element proposed and would map into the standard set of layouts as recognized by the core layout system. See #1787846: Themes should declare their layouts and its related changelogs for more details. Issue proposing addition of responsive layout builder in core: #1822950: Add responsive layout builder to core

Unclear menu terminology while creating a menu link from a page

$
0
0

Participants of the usability study at the university of Minnesota 2011 were tripped with the drop down menu options when creating a menu from a page.

Participants were trying to create a page and make it accessible from the main menu (during the study we did not use the word "main menu"). Participants created a page and found the "Add a menu link" (with some struggle). After that, they were confused with the options under the drop down menu. Although it has only two options: Main Menu and Home, it was enough to confuse them. Some participants selected "home" instead because they wanted to add the menu to the home page. Participants who did this, made their menu link not appear at all and made them question as to what went wrong.

Possible ways to tackle this:
- Have a clear parent item terminology
- Cater to the audience by visual means. Making the menu placement visual could be an alternative, however we need to be considerate with respect to adhering to accessibility standards
- Have only one link by default i.e. "Main Menu"

Check the database schemas for common issues to improve portability

$
0
0

The SQLite driver doesn't respond well to compound primary keys, if one of the columns is a serial. Example from a module:

'fields' => array(
      'id'  => array(
        'type' => 'serial',
        'not null' => TRUE,
        'description' => 'Entity id',
      ),
      'path'  => array(
        'type' => 'varchar',
        'length' => 255,
        'not null' => TRUE,
        'description' => 'The path of the page to apply meta tags to',
      ),
      'lang'  => array(
        'type' => 'varchar',
        'length' => 8,
        'not null' => TRUE,
        'description' => 'Language code',
      ),
    ),
  'primary key' => array('id', 'path', 'lang'),

While the usefulness of the above primary key is up for discussion, it is valid, and will work fine in MySOL. However, when SQLite generates the CREATE TABLE, it adds PRIMARY KEY to the field definition in createFieldSql, and removes it from the set. After that, if the primary key set is not empty, it adds a PRIMARY KEY definition to the CREATE TABLE, using the left over columns, causing SQLite to complain 'PDOException: SQLSTATE[HY000]: General error: 1 table "metatags_quick_path_based" has more than one primary key'.

While it's possible to work around, it does break the consistency of the Database API.

I discovered this problem with metatags_quick 2.4, but a quick search tells me that other modules have run into the same bug.


Low memory schema cache (info hook) rebuilds

$
0
0

This is based on #402896: Introduce DrupalCacheArray and use it for drupal_get_schema() and also struggling with memory usage/race conditions/cache stampedes in #853864: views_get_default_view() - race conditions and memory usage.

CacheArray for the schema cache only optimizes the behaviour of that cache item on runtime. If you get a cache miss, then you still have to rebuild the entire schema, alter it, then cache it in a big lump. This is very memory intensive - both the cost of loading every .install file for every module - even if you have APC enabled .install files may well not be cached, as well as creating a very large array in memory, then writing the very large cache item is also not great, especially if it won't fit in a cache backend. Similarly, if we swapped that single cache item for lots of little ones, then you could be potentially writing 400+ cache items from that one request, which is also going to be time-consuming.

We can improve this by doing the following:

- Change hook_schema_alter() so that it only gets schema arrays at the scope of a module (or even table but that might be going a bit far), not the entire site.

- when there is a cache miss for an individual table, only rebuild the schema enough to find the definition of that table and cache it, then just don't bother looking for the rest.

- given that, we might be able to additional optimize that so that if you're looking for the 'node' table, it checks the 'node' module first, not all db tables are namespaced by module name, but lots are.

- the 'full schema' will need to be converted to a class that implement Iterator - then you can foreach over the entire schema, but we don't have to hold it in memory the whole time.

Add weight field to node type and sorting for admin/structure/types

Simplify and automate the creation of an RTL language for development and testing

$
0
0

For #665790-53: Redesign the status report page I created a custom language "RTL" with language code "rtl", in order to just get the RTL behavior and nothing else.

That's really helpful for testing RTL stuff.

I wonder we could do anything to simplify and automate this in any way?

E.g., a baked-in hard-coded (non-standard) "rtl" language code, which always exists when Language module is enabled?

Update help.help_topic_search to remove mention of Help Topics module

$
0
0

Problem/Motivation

In #3037230: Finalize the merge of Help Topics into Help, we have a sub-task to ensure that Help Topics module isn't mentioned in any other topic. It is mentioned in the help.help_topic_search topic:

Verify that the Search, Help, Help Topics, and Block modules are installed (or install them if they are not already installed).

The problem is that in #3087499: Merge Help Topics classes into Help with BC layer, we are moving all of Help Topics' help topics to the core Help module. So, to avoid a patch or MR that applies to a moved file and inaccurate instructions, let's postpone this change until Help Topics' merge into Help has been completed.

Steps to reproduce

Open the file core/modules/help/help_topics/help.help_topic_search.html.twig (assuming the move is complete, otherwise, look in core/modules/help_topics/help_topics), and see that this topic mentions "Help Topics" (the module).

Proposed resolution

In core/modules/help/help.help_topic_search.html.twig,

Update the following text:

Verify that the Search, Help, Help Topics, and Block modules are installed (or install them if they are not already installed).

To:

Verify that the Search, Help, and Block modules are installed (or install them if they are not already installed).

Remaining tasks

- Wait for #3087499: Merge Help Topics classes into Help with BC layer to be fixed, which moves this help topic to its new location in core/modules/help/help_topics.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Help Topics (which has been an experimental module in Drupal core) has been merged with the core Help module. The instructions for configuring Help search have been updated to no longer require the installation of Help Topics (as it no longer exists as a separate module, but has been merged with Help module).

Add separate 'Save' and 'Save and add fields' to Add Content, Comment, Media and Block Type Forms

$
0
0

Problem/Motivation

When creating a new Content type, the button text is: 'Save and manage fields'
When creating a new Comment, Media or Block types, the button text is: 'Save'

Page URL Button Text Action after saving
Add content type /admin/structure/types/add Save and manage fields Directs to manage fields page
Add comment type /admin/structure/comment/types/add Save Direct to Comment types overview page
Add media type /admin/structure/media/add Save Directs to Media types overview page
Add custom block type /admin/structure/block/block-content/types/add Save Directs to Block types overview page

Proposed resolution

Proposing that we have two separate buttons on each entity type add form:
#1 'Save', which directs users back to the entity type overview page
'#2 Save and add fields', which directs to the Manage fields page

Page URL Button 1 Text Button 1 Action Button 2 Text Button 2 Action
Add content type /admin/structure/types/add Save Directs to Content types overview page Save and manage fields Directs to manage fields page
Add comment type /admin/structure/comment/types/add Save Directs to Comment types overview page Save and manage fields Directs to manage fields page
Add media type /admin/structure/media/add Save Directs to Media types overview page Save and manage fields Directs to manage fields page
Add custom block type /admin/structure/block/block-content/types/add Save Directs to Block types overview page Save and manage fields Directs to manage fields page

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Grouped filters with a value of zero do not show when editing the filter.

$
0
0

Problem/Motivation

Grouped filters with a value of zero do not show when editing the filter. This is probably because '0' is an "empty" value according to PHP.

Steps to reproduce

  1. Create a view with a grouped filter (e.g. on user ID).
  2. Have one of the groupings use "Is equal to" or "Is not equal to", and a value of "0".
  3. Save the view.
  4. Then, edit the grouped filter, and where you entered "0", the HTML input is now empty, and the UI complains that you have not entered a required value.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Deprecate system_check_directory()

$
0
0

Problem/Motivation

system_check_directory() is only used in one place in core, in locale_form_system_file_system_settings_alter(), but its loaded on every request.

http://codcontrib.hank.vps-private.net/search?text=system_check_director...

Proposed resolution

Deprecated it without replacement because there's only 8 usages found in contrib

Remaining tasks

- patch/review
- update CR
- commit

User interface changes

no

API changes

The system_check_directory() is deprecated

Data model changes

no

Release notes snippet

no


Fix PHPStan L1 errors "Variable $foo might not be defined." caused by non-exhaustive switch statements

$
0
0

Problem/Motivation

Amongst the current suppressions found in the PHPStan level 1 baseline is: Variable $foo might not be defined..

This issue exists to fix all of those caused by non-exhaustive switch statements. See https://github.com/phpstan/phpstan/issues/7521#issuecomment-1164581820

Steps to reproduce

- Run PHPStan on level 1 and see the above issue amongst all others.

Proposed resolution

- Solve all of the reported issues for the above mentioned.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Update Maintainers for the Help module

$
0
0

Problem/Motivation

Part of #3037230: Finalize the merge of Help Topics into Help

As help topics are merged let's move maintainers to help module

Proposed resolution

Move maintainers of help topics to help module

Remaining tasks

agree/patch/commit

User interface changes

API changes

Data model changes

Release notes snippet

Card Sorting survey

$
0
0

Motivation/problem

We need to collect data around how users categorize options in the Administration User Interface main navigation.

The purpose of this issue is to request participation in a card sorting survey. The survey is anonymous and will take approximately 5-10 minutes to complete. Your feedback will help us make decisions about restructuring the admin toolbar based on your mental models, rather than our assumptions.

Link to the Card Sorting survey: [Card Sort closed]

After you have completed the survey, add a comment to this issue if you'd like to get credit for participating and helping us with your answers.

Feel free to add any kind of feedback on the comments, as well.

Option for the Toolbar *not* to auto-open the "Manage" sub-menu?

$
0
0

I'm posting this as a support request, because I'm not sure if it's implemented already or not. If it's a 8.3.x/feature request, feel free to change this issue Title/Category/Version/Priority.

I really like the toolbar, and I like it when it's at the top of the page. However, when I'm working on my mobile sites, having the manage submenu (Content/Structure/Appearance) pop over to the left side of the page can really mess up development on my mobile sites. A lot of elements rely on page width and it messes everything up. I find I need to log out to view the page more conveniently, or continuously close the menu by clicking "Manage" on every page reload.

Interestingly, when the toolbar is loaded on a very narrow page (~<575px width), the toolbar doesn't auto-popup.

I understand why it's there, but I'm constantly having to close the manage auto-popup to view my page correctly.

Is there a way to configure Toolbar to change the default behaviour so that the Manage submenu doesn't pop up by default? I want the option to have to click on Manage to make the menu come up.

Add a vendor:// stream wrapper

$
0
0

Blocked by: #2873160: Implement core management of 3rd-party FE libraries

Drupal 8 integration with composer has been excellent for managing 3rd party PHP libraries with Drupal, as the libraries can be called using PSR-4 namespaces to load the libraries, regardless of the location of the vendor folder. Being able to call these files regardless of the location of the vendor folder is important, as the vendor library folder location is dynamic. Many installations have the vendor folder installed in the webroot, however it is a best practice to place the vendor folder outside the webroot, a practice followed by the Drupal Composer template,

The problem comes with CSS and JS libraries. These can be included using composer, but when the vendor file is outside the webroot, any CSS and JS are unusable, as they are not web-accessible and therefore cannot be included in *.libraries.yml files.

For contributed module developers, this has led to two separate methods of managing 3rd party libraries with Drupal 8. PHP libraries can and are managed with Composer, and module developers can use composer.json files to manage their dependencies. However, modules that use 3rd party CSS/JS libraries have to either use D7 methods of creating a libraries folder, and have users manage the dependencies on their own to place the library in a web-accessible location, or use Composer to manage the dependency, then have users copy the CSS and JS files to a web accessible location. An example of this is the jQuery Colorpicker module, which as of the time of writing of this post requires users to manage the library on their own, downloading it to a /libraries folder, linking to the CSS and JS files using:

library:
  version: 1.0.1
  css:
    theme:
      /libraries/jquery_colorpicker/css/colorpicker.css: {}
  js:
    /libraries/jquery_colorpicker/js/colorpicker.js: {}
  dependencies:
    - core/jquery

As you can see, the CSS and JS files are linked to from the /libraries folder. In order to ensure system integrity, hook_requirements() has been implemented, informing users of the requirement of downloading the library and providing instructions on how to do so. This is not ideal. The ideal would be to Include a dependency on the library through Composer, managing the 3rd party library in the same manner as PHP libraries are managed.

The solution to the issue of managing 3rd party CSS and JS libraries with Composer is to use the Vendor Stream Wrapper module. This module is essentially a clone of the private stream wrapper functionality of core, but working with the vendor directory rather than the private files directory. It sets up a vendor:// stream wrapper, and adds parsing to *.libraries.yml files, so that the above jquery_colorpicker.libraries.yml file could be converted to this:

library:
  version: 1.0.1
  css:
    theme:
      vendor://jaypan/jquery_colorpicker/css/colorpicker.css: {}
  js:
    vendor://jaypan/jquery_colorpicker/js/colorpicker.js: {}
  dependencies:
    - core/jquery

The module looks for the vendor folder first in the webroot, then one folder above the webroot. If the vendor folder is in any other location, the location can be set in settings.php.

I think this module should be included into core, to allow for Drupal modules to manage CSS and JS libraries using Composer, unifying 3rd party library management into a single API, rather than having to use D8 methodology for PHP libraries, and D7 methodology for managing CSS and JS libraries. Currently it is a bug that CSS and JS files in a vendor folder that exists outside the webroot are unable to be linked to, and it becomes a security risk if one of the files that is part of the 3rd party library is found to have a security vulnerability. This security vulnerability would not exist for users who have placed their library in a vendor folder that is outside the webroot.

Viewing all 300835 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>