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

EntityDisplayBase::init() should use ::setComponent() for extra fields

March 26, 2018, 2:19 pm
$
0
0

Problem/Motivation

During __construct(), EntityDisplayBase ensures that all extra fields are correctly added as components.
However, it does so by directly manipulating internal variables, bypassing ::setComponent().

Any subclasses, such as the one added in #2922033: Use the Layout Builder for EntityViewDisplays, needs to be able to track the components as they are added.
Using the API will allow this.

See #2925657: EntityDisplayBase::init() should use ::setComponent() for fields and #2953656: No ability to control "extra fields" with Layout Builder

Proposed resolution

Use ::setComponent() correctly

Remaining tasks

N/A

User interface changes

N/A

API changes

N/A

Data model changes

N/A

↧
Search

Allow Layout Builder sections to be reordered

March 26, 2018, 2:39 pm
$
0
0

Problem/Motivation

Allow sections to be reordered within the Layout Builder UI

Proposed resolution

TBD

Remaining tasks

Designs
Implementation
Tests

User interface changes

Yes

API changes

Ideally no

Data model changes

No

↧
↧

[policy, no patch] Extend security support to cover the previous minor version of Drupal

September 18, 2017, 7:33 am
$
0
0

Problem/Motivation

The upgrade model in Drupal 8 includes the policy that the previous minor version is unsupported. So if you want to have security support for your production site running Drupal 8, you must upgrade immediately, or at least be prepared to upgrade immediately if a patch release with a security fix comes out.

There can be many different causes for breakage or inability to upgrade when a new minor version has been released. Some real examples of different causes:

  • There is a new experimental module replacing a contrib module, and the original contrib module is not supported in the new minor release. Also other contrib projects depending on this module might not have the resources to support two modules (original contrib module and the new core module). This happened with Layout Plugin and Layout Discovery when Drupal 8.3 was released.
  • The new minor Drupal release might introduce major version updates for dependencies. Drupal 8.4 introduces Symfony 3.2 and jQuery 3. While this is not a breaking change in Drupal itself, it is reasonable to expect that some contrib projects also use Drupal dependencies, especially something like Symfony and jQuery. These dependency updates in 8.4 have caused contrib modules to break.
  • Some changes in core are not considered BC breaking. This includes things like changing plugin constructors. For example it is reasonable to expect that some contrib projects extend core plugins and use ContainerFactoryPluginInterface for dependency injection, requiring the use of __construct(). This has happened with 8.4 and a constructor change to SystemMenuBlock.

The time window for testing the new minor release and contrib modules from the first Release Candidate to the end of the grace period after the release is about two months. This is not a very long time, especially considering that many smaller organizations maintaining their own sites probably won't even try out Release Candidates.

The short time window to fix possible problems puts a lot of pressure on contrib and people maintaining their own sites. The worst case scenario is that production sites won't be upgraded to the latest minor version due to breakage, and there is a serious security issue, leaving these sites vulnerable to attacks.

Proposed resolution

Extend security support to cover the previous minor version of Drupal. This would give more time to sort out and resolve possible problems.

↧

LegacyMessenger::deleteByType does not delete anything

March 13, 2018, 10:31 am
$
0
0

Appears to be a very small and simple mistake:

LegacyMessenger::deleteByType calls MessengerInterface::messagesByType() instead of MessengerInterface::deleteByType().

↧

Cannot save theme settings form for themes without logo or favicon features

March 21, 2018, 5:50 am
$
0
0

If a theme does not have both logo and favicon features, then saving the theme settings for that theme will produce the error:

Recoverable fatal error: Argument 1 passed to _file_save_upload_from_form() must be of the type array, null given, called in ...\core\modules\system\src\Form\ThemeSettingsForm.php on line 392 and defined in _file_save_upload_from_form() (line 761 of core\modules\file\file.module).

Example theme.info.yml:

name: Test
type: theme
core: 8.x
features:
  - logo

This is because of lines 383:
$file = _file_save_upload_from_form($form['logo']['settings']['logo_upload'], $form_state, 0);
and 392:
$file = _file_save_upload_from_form($form['favicon']['settings']['favicon_upload'], $form_state, 0);
in ThemeSettingsForm.php not checking the existence of those form elements first.

↧
↧

Display 'required' validation errors for form elements that do not provide a #title

September 4, 2015, 5:12 am
$
0
0

Problem/Motivation

If "required" validation on a field without a #title fails, we don't display any error message.

Submitting as critical because we just silently fail on a form submission which can give the impression the submission was successful to the end user.

An example is when you have a contact form and a required views exposed form on the same page, and submission of the contact form fails.

Proposed resolution

Display the ID of the form element as opposed to displaying nothing so it is clear that validation failed to developers (and end users - if developers don't find this bug in their own testing)

Remaining tasks

Commit

User interface changes

An error message now appears when validation fails:

validation message for a field without title

API changes

N/A

Data model changes

N/A

↧

D7 and D6 taxonomy term fields are not migrated with allowed vocabularies

July 10, 2016, 4:32 am
$
0
0

Problem/Motivation

On migration from D7, the taxonomy term fields get migrated fine, but they are set to allow all vocabularies, even though that wasn't the case in source.

Proposed resolution

In D7, the allowed vocabularies is a part of field settings which is not available in instance migration, which is where it needs to be in D8. We should add the settings first and then process it during migration.

Remaining tasks

Patch, review, commit.

User interface changes

None

API changes

None

Data model changes

None

↧

Error using Thumbnail styles in core image field when webprofiler is enabled

March 19, 2018, 8:29 am
$
0
0

I'm not at all sure if this should be considered a core issue or a devel issue, but it has been reported by other users in both the devel project and the video_embed_field project. Long story short, when trying to use the thumbnail style for image entities (and apparently video entities, though I didn't try that myself), while the Webprofiler module is enabled, an error like the following occurs:

Recoverable fatal error: Argument 9 passed to Drupal\\media\\Plugin\\Field\\FieldFormatter\\MediaThumbnailFormatter::__construct() must implement interface Drupal\\image\\ImageStyleStorageInterface, instance of Drupal\\webprofiler\\Entity\\Decorators\\Config\\ConfigEntityStorageDecorator given, called in /Users/foo/Sites/devdesktop/bar-dev/docroot/core/modules/media/src/Plugin/Field/FieldFormatter/MediaThumbnailFormatter.php on line 81 and defined in /Users/foo/Sites/devdesktop/bar-dev/docroot/core/modules/media/src/Plugin/Field/FieldFormatter/MediaThumbnailFormatter.php on line 61 #0 /Users/foo/Sites/devdesktop/bar-dev/docroot/core/includes/bootstrap.inc(582): _drupal_error_handler_real(4096, 'Argument 9 pass...', '/Users/foo/S...', 61, Array), referer: https://bar.dd:8443/node/add/page

As it happens, duplicating the fix used for video_embed_field does also fix the problem for the core image field. I'll provide a patch shortly -- but as I said, I'm not sure if this is the appropriate place to fix it.

↧
Search

Media configuration included with Standard needs to include inherited dependencies

January 7, 2018, 10:35 am
$
0
0

Problem/Motivation

Over in #2934962-8: Ship local audio and video media types in Standard, @xjm pointed out that the config Media ships in Standard is missing certain things that it should rightfully inherit from Standard's other modules after installation (dependencies, third party settings, etc.)

Proposed resolution

Install Media as part of Standard (not after the fact), then re-export all of Media's configuration. The difference between the shipped config and the exported config is the patch that should be filed in this issue.

Remaining tasks

Do the thing I just said. Then commit the patch.

User interface changes

None.

API changes

None.

Data model changes

Nil.

↧
↧

Throw exception for destination plugins without a destination_module property

November 15, 2017, 10:38 am
$
0
0

This issue is spun off from #2908282: Throw exception for source plugins without a source_module property.

Problem/Motivation

There are several implicitily required properties to destination, source and process plugins. Rather than waiting for someone to WSOD when they miss one of these implicit requirements, we should throw a loud exception.

The MigrateDestination annotation defines a destination_module property which needs to identify the system which will contain the processed, migrated data. In Migrate Drupal's case, this property is used to identify the D8 module which will "own" the migrated data.

When providing a strong API, it's important to tell consumers when they are doing something wrong. For Migrate Drupal's purposes (our main use case), this property is required in order to inform users whether their D6/D7 data will be migrated into Drupal 8. Therefore, this blocks the completion of the core migration path to Drupal 8, and is Migrate-critical.

Proposed resolution

↧

Canonical taxonomy term link for forum vocabulary is broken

June 2, 2013, 4:49 am
$
0
0

Problem/Motivation

Currently rendering of canonical taxonomy term link for forum vocabulary is broken and have no test coverage.

To be more consistent with the object-oriented architecture need to implement Drupal\Core\Entity\EntityInterface::uri() method and drop taxonomy_term_uri() function and clean-up Term annotation uri_callback.

Proposed resolution

Implement a path processor outbound service to make this work again and add test. Remove taxonomy_term_uri() and forum_uri() functions as useless because entity templates are takes precedence.

Remaining tasks

Contributor tasks needed
TaskNovice task?Contributor instructionsComplete?
We have manually tested the patch and confirmed that it has not been rolled.NoviceInstructionsYes
Reroll the patch.InstructionsYes
Draft a change record for the API changesInstructionsYes
Profiling (see comment #49)Yes

User interface changes

API changes

Original report by @andypost

Part of #2010184: [meta] convert ‘uri_callback’ entities param to EntityInterface::uri() method

Needs to implement Plugin\Entity\Term.php uri() method and drop taxonomy_term_uri() function replacing it's calls to $term->uri() and clean-up Term annotation uri_callback

↧

[D7] Remove all assert('string') calls from Drupal core because deprecated in PHP 7.2

March 6, 2018, 8:38 am
↧

Fully support PHP 7.2 in Drupal 7

February 25, 2018, 12:44 pm
↧
↧

Update README.txt to drupal preferred format

March 19, 2018, 12:49 pm
↧

ajax-progress-fullscreen $('body').after(this.progress.element) Not Valid HTML

March 21, 2018, 10:21 am
$
0
0

The fullscreen version of the ajax-progress loader is inserted after the body.

Drupal.Ajax.prototype.setProgressIndicatorFullscreen = function () {
    this.progress.element = $('<div class="ajax-progress ajax-progress-fullscreen">&nbsp;</div>');
    $('body').after(this.progress.element);
};

You should not insert html elements after the body, it is not valid HTML and will fail W3C. Try testing this, which is what Drupal generates.

<!DOCTYPE html>
<html>
<head>
<title>TEST</title>
</head>
<body></body>
<div></div>
</html>

$('body').after() should be replaced with $('body').append()

↧
Search

PSR-7 middleware support

May 30, 2015, 2:08 pm
$
0
0

Follow-up to #2492955: [meta] PSR-7 support

There is not, yet, a StackPHP equivalent for PSR-7. From talking with Beau Simensen of Stack PHP there likely will be an HttpKernel-like middleware for PSR-7 but it's still in discussion how/where to do it.

That is, projects like us would be able to do:

PSR7Request->(Psr7Middleware(Psr7Middleware(BridgeLibrary(HttpKernelMiddleware(HttpKernel(Drupal))))))->PSR7Response

This is a placeholder issue for once such a standard emerges. We should evaluate at that time how to support it fully. Until then, the child issues of #2492955: [meta] PSR-7 support will suffice.

↧

Remove empty and default views exposed filter values from url GET arguments

August 27, 2017, 2:20 am
$
0
0

When I use views exposed filter with pager, each pager link contains all arguments, used in exposed filter, so even if I don't touch any exposed filter values - pager url contains many garbage empty and default arguments, for example:

http://example.com/catalog?manufacturer=All&price[min]=&price[max]=&power[min]=&power[max]=&width[min]=&width[max]=&height[min]=&height[max]=&depth[min]=&depth[max]=&sort_by=field_price_value&sort_order=DESC&page=2

instead of clean way:
http://example.com/catalog?page=2

Same problem if I use exposed filter and change only one field value, URL contains all values, including empty and default:
http://example.com/catalog?manufacturer=Hypnotoad&price[min]=&price[max]=&power[min]=&power[max]=&width[min]=&width[max]=&height[min]=&height[max]=&depth[min]=&depth[max]=&sort_by=field_price_value&sort_order=DESC

This give many problems with search engine indexing of Views filter results - URL contains many unnecessary values, and if we add new field to exposed filter or reorder fields - each old URL filter will be changed, so search engines will see many new urls and will reindex it, and exclude them as duplicated content.

Best solution for this problem is compare current exposed filter values with default, remove empty and default values and leave only actual used defined values.

↧
↧

Allow themes to declare dependencies on modules

May 27, 2009, 2:07 pm
$
0
0

Problem/Motivation

Parsing .info files for dependency information is already implemented on the modules administration page. Adding support for the same dependencies in theme.info files, and implementing the same behavior on the admin/build/themes page, would allow designers building heavily customized themes to make safer assumptions about their target sites.

A theme might require the existence of imagecache to auto-generate variations of a header image. This would be a nice compromise between systems like Wordpress and Joomla!, which give themes much greater control over the functionality of the site, and Drupal's module-centric approach.

It also creates following new UX requirements and non UI, API requirements

  1. Represent the list of dependent modules in themes list page. Display of missing/disabled dependent modules.
  2. Extension in Drush to download and enable modules dependent on themse.

Proposed resolution

  • Allow themes to add the dependencies to .info.yml files
  • Show these dependencies on /admin/appearance and make it impossible to install without the requirements
  • Install dependencies automatically on API level.

Original report by [eaton]

Issue Summary
Parsing .info files for dependency information is already implemented on the modules administration page. Adding support for the same dependencies in theme.info files, and implementing the same behavior on the admin/build/themes page, would allow designers building heavily customized themes to make safer assumptions about their target sites.

A theme might require the existence of imagecache to auto-generate variations of a header image. This would be a nice compromise between systems like Wordpress and Joomla!, which give themes much greater control over the functionality of the site, and Drupal's module-centric approach.

↧

Issue with block display

March 27, 2018, 12:59 am
$
0
0

When using views to generate multiple blocks for a specific content type, you are unable to customise the block items to be displayed. Ie display 3 or 5 items depending on the block. Previous Drupal versions allowed you to make this change to the number of items been displayed.

↧

Umami support for Internet Explorer 11

February 7, 2018, 7:14 pm
$
0
0

Problem:

Umami theme has lots of display issues in Internet Explorer.

  1. main menu links are not displayed - major usability bug
  2. logo image is stretched vertically
  3. Text in banner is at top of image, rather than midway down
  4. Promoted Articles heights are equal but not correct
  5. Frontpage view flexbox is not working (probably just need to add in a prefix ms-flex
  6. Articles listing page - flexbox is not working
  7. Article node - is sidebar working
  8. Recipe node - same issue with sidebar
  9. Recipe node - icons and text are squashed on top of each other
  10. Recipe node - ingredients and instructions flexbox is not working
  11. Taxonomy term page - flexbox not working
  12. Search block - icon missing

Internet Explorer 11 is one of the supported browsers for D8.

↧
Viewing all 297868 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>