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

Dispatch some event after sending email to allow logging and further actions

$
0
0

Problem/Motivation

Currently it seems that to log send emails and perform further processing, like tracking opening and clickrates for marketing purposes, we need to implement an own MailManager Plugin extending the core one and dispatching an event. There are modules like MailSystem that facilitate altering the Mail and Theme Plugins used to send email, but they rely on the core mail sending. Therefore from my point of view, it would make sense to change the core MailManager mail or doMail function and to dispatch an event that contains the send mail (instead of doing this in a contributed module).

By doing so it would be much easier for contributed modules to keep track of send emails, implement retry on send failure, log all outoing emails and implement further processing like tracking openings and clicks on email links as well as implementing per email auto login facilities.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


Progress throbber position is incorrect

$
0
0

Problem/Motivation
Progress throbber position and styling are incorrect while viewing in table display as compared with other displays.

Steps to replicate
Example:
1. Go to admin/structure/block and click on place block to check the throbber effect.
2. After that click on the place block button from place block modal popup form and check the throbber effect.

See the below screenshots
progress throbber
progress throbber

Add Hostname and Referrer to Recent log messages

$
0
0

It would be nice to be able to see the Hostname and Referrer in the list on the Recent log messages page (admin/reports/dblog).

Hostname and Referrer in dblog list

Media and media library

$
0
0

This issue is to plan the redesign for Media. Needs definition, so far this is a placeholder where we'll add designs and child issues to work on. No patches are expected here.

  • To start, we need screenshots of all the pages/worflow. Done in #7 and #8
  • We have Seven screenshots, we need Claro screenshots to know current status.
  • Create a list of all Media components and pages to be designed
  • Fix all child issues

Strange problems with ajax in a custom views filter plugin

$
0
0

I'm not sure if this is a bug or I'm just doing something wrong so I've tagged it as support for now.

I'm trying to make a custom views filter plugin that uses ajax in the form. It's a multi-vocabulary term select - the user selects a vocabulary then selects a term from that vocabulary from an ajax-populated list.

However, I'm encountering several bizarre issues while trying to set it up. If I provide the ajax callback as [$this, 'updateTerms'] it gives me this ajax error in preview:

A fatal error occurred: Recursion detected

Ajax never even runs in the full view. In this case the widget is not rendered at all and the error occurs even on the first load of the widget.

If I provide the ajax callback as either '::updateTerms' or 'Drupal\de_vocabulary_level_views_filter\Plugin\views\filter::updateTerms' it gives me this error in the views preview:

A fatal error occurred: The specified #ajax callback is empty or not callable.

and, inexplicably, this error on the full view:

An unrecoverable error occurred. The uploaded file likely exceeded the maximum file size (8 MB) that this server supports.

This issue occurs even on a fresh minimal install of Drupal 8 core with no extra modules or configuration besides enabling taxonomy, views, views_ui and the custom module itself and adding the filter to a view.

The form is pretty simple and works outside of views.

The form is provided in the valueForm function (though I've had the same results inside buildExposedForm) which is overridden like so:

  /**
   * {@inheritdoc}
   */
  protected function valueForm(&$form, FormStateInterface $form_state) {
    $vocabularies = $this->vocabularyStorage->loadMultiple();
    $vocab_options = array();

    foreach ($vocabularies as $voc) {
      $vocab_options[$voc->id()] = $voc->label();
    }

    $form['value'] = [
      'vocab' => [
        '#title' => $this->t('Vocabulary'),
        '#type' => 'select',
        '#options' => $vocab_options,
        '#empty_option' => $this->t('- Any -'),
        '#empty_value' => NULL,
        '#default_value' => !empty($form_state->get('vocab')) ? $form_state->get('vocab') : NULL,
        '#ajax' => [
          'event' => 'change',
          'callback' => 'Drupal\de_vocabulary_level_views_filter\Plugin\views\filter::updateTerms',
          'wrapper' => 'de-vocabulary-level-views-filter-terms-wrapper'
        ],
      ],
      'de_vocabulary_level_views_filter' => [
        '#title' => $this->t('Term'),
        '#type' => 'select',
        '#empty_option' => $this->t('- Any -'),
        '#empty_value' => NULL,
        '#default_value' => !empty($form_state->get('term')) ? $form_state->get('term') : NULL,
      ],
      '#prefix' => '<div id="de-vocabulary-level-views-filter-terms-wrapper">',
      '#suffix' => '</div>',
    ];

    if (!empty($form_state->getValue('vocab'))) {
      $term_query = $this->entityQuery->get('taxonomy_term')
        ->condition('status', 1)
        ->condition('vid', $form_state->getValue('vocab'));
      $term_query_result = $term_query->execute();
      $terms = $this->termStorage->loadMultiple($term_query_result);
      $term_options = [];
      foreach ($terms as $term) {
        $term_options[$term->id()] = $term->label();
      }
      $form['value']['de_vocabulary_level_views_filter']['#options'] = $term_options;
    }
  }

There's a small ajax callback:

  public function updateTerms(&$form, FormStateInterface $form_state) {
    return $form[$this->options['expose']['identifier']];
  }

Currently it reloads a section of the form from the base of the filter form but the same results occur treating it as if it was just the bit from valueForm.

Optional configuration from dependence modules is installed before installing module when installing profile

$
0
0

Problem/Motivation

- Optional configuration of module does not install during installing profile.
- So if default configuration of any module that dependences on optional configuration of module, so we could not install profile.
- System throws `Drupal\Core\Config\UnmetDependenciesException`

Steps to reproduce

- The profile dependences B module
- Module B dependences A module
- Module A has an entity field(called custom field) that puts under config/optional
- Module B has views that required custom field of A module, that puts under config/install
- Then use drush to install site.(`drush site-install profile ...`)

Why do we need to set dependence of default configuration base on optional configuration

- Optional configuration could not import translation.
- In config/optional/language/{lang_code} does not fetch/configure during installing module at all.
- I also check Process translation config files for custom modules, but it seems that system will ignore config/optional/language/{lang_code}
- As you know `lightning_media_document` was moved YAMLs file to config/optional here, so the problem occures at here.

Proposed resolution

- Check and create patch to fix.

Remaining tasks

- Test, release.

Investigate

- I checked and saw that the problem is:

  • IN `core/includes/install.core.inc : install_tasks()`
    system runs `install_profile_modules` before `install_install_profile`
    ...
    'install_profile_modules' => [
      'display_name' => t('Install site'),
      'type' => 'batch',
    ],
    ...
    'install_install_profile' => [],
    ....
  • In `Drupal\Core\Config\ConfigInstaller : installDefaultConfig()`

    When `'install_profile_modules'` runs, config/optional does not consider cause `InstallerKernel::installationAttempted()`.
    At this time config/optional of A module did not install yet, so B module could not install, because dependence stuffs.
    Then system throws `Drupal\Core\Config\UnmetDependenciesException`
  if (!$this->isSyncing() && (!InstallerKernel::installationAttempted() || $profile_installed)) {
      $optional_install_path = $extension_path . '/' . InstallStorage::CONFIG_OPTIONAL_DIRECTORY;
      if (is_dir($optional_install_path)) {
        // Install any optional config the module provides.
        $storage = new FileStorage($optional_install_path, StorageInterface::DEFAULT_COLLECTION);
        $this->installOptionalConfig($storage, '');
      }
      // Install any optional configuration entities whose dependencies can now
      // be met. This searches all the installed modules config/optional
      // directories.
      $storage = new ExtensionInstallStorage($this->getActiveStorages(StorageInterface::DEFAULT_COLLECTION), InstallStorage::CONFIG_OPTIONAL_DIRECTORY, StorageInterface::DEFAULT_COLLECTION, FALSE, $this->installProfile);
      $this->installOptionalConfig($storage, [$type => $name]);
    }
  • So I think above code should be
    if (!$this->isSyncing()) {
      $optional_install_path = $extension_path . '/' . InstallStorage::CONFIG_OPTIONAL_DIRECTORY;
      ...
      $this->installOptionalConfig($storage, [$type => $name]);
    }

- If i miss anything, please correct.

Make Drupal 9 installable on PHP8

$
0
0

Problem/Motivation

This task will try to get Drupal 9 installable on PHP8.0 alpha so we can work out issues to address.

Proposed resolution

Make Drupal 9 testable on PHP 8 and PHP 7 at the same time.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Unicode::mimeHeaderDecode() doesn't support lowercased encoding

$
0
0

Problem/Motivation

In Inmail, we are dealing with mail message processing.
In order to decode email header fields, we use \Drupal\Component\Utility\Unicode::mimeHeaderDecode() helper.

Encoded header value is defined as:
encoded-field = "=?" charset "?" encoding "?" encoded-text "?="

The helper function assumes that encoding value is given as uppercase and fails to decode the given string when it's provided as lowercase.

RFC 2047 allows those values to be provided as either uppercased or lowercased:

Both 'encoding' and 'charset' names are case-independent. Thus the charset name "ISO-8859-1" is equivalent to "iso-8859-1", and the encoding named "Q" may be spelled either "Q" or "q".

Proposed resolution

Let \Drupal\Component\Utility\Unicode::mimeHeaderDecode() consider lowercased encoding values as well.
Provide test coverage for lowercased cases.

Remaining tasks

User interface changes

API changes

Data model changes


Add html2text/html2text and swiftmailer/swiftmailer into core

[Meta, no patch] Add Swiftmailer to deprecate majority of our mail system

$
0
0

What does Swiftmailer provide that is better than the current mail system

Swiftmailer simplifies means integrating email communications within Drupal. The current mail system only supports plain text email and one transport method.

Swiftmailer provides plain text and HTML content types and multiple transport methods. It has a pluggable system that allows it to be extended, like Twig.

Currently we manage our own plugin system for mail that provides a default PHP `mail()` integration. Contributed modules must then provide integration with SMTP, sendmail, or others. This also means integrations for Sendgrid and Mandrill must require the SMTP module or write their own mail plugin.

What new features would Swiftmailer enable that we currently don't have?

Swiftmailer would immediately allow Drupal to send email over SMTP, Sendmail, PHP, or any other possible transport method. More can be read here: http://swiftmailer.org/docs/sending.html.

This also means users can immediately integrate with services like SendGrid and Mandrill out of the box with Drupal.

* SendGrid: https://sendgrid.com/docs/Integrate/Code_Examples/v2_Mail/php.html
* Mandrill: https://mandrill.zendesk.com/hc/en-us/articles/205582157-How-to-Send-wit...

One need, especially in the e-Commerce realm, is HTML enabled emails for rich customer experiences. Allowing Drupal to send HTML based emails out of the box will improve the experience built on top of Drupal for customers interacting with it.

Why is Swiftmailer the best library for that? Are there alternatives?

Swiftmailer is an open source library that is part of SensioLabs. Drupal currently incorporates Twig and many Symfony components, all of which are part of SensioLabs. This makes Swiftmailer highly qualified and further brings together the Drupal communities and PHP community at large collaborating with SensioLab libraries.

There is PHPMailer (https://github.com/PHPMailer/PHPMailer), however it is not pluggable like Swiftmailer, and may be harder to customize than Swiftmailer. In fact, the SMTP module for Drupal just embeds PHPMailer in itself (instead of requiring it via Composer...)

What are the drawbacks of integrating Swiftmailer?

We have to handle deprecation of Drupal's messy mail system (Mail plugins, hook_mail.) We would probably have to deprecate the SMTP module and Mailsystem module.

I can't come up with any drawbacks.

Next steps

  • Use this issue as the plan/meta for integrating Swiftmailer
  • Get the library in core
  • Have core's php_mail use Swift_Transport_MailTransport instead of mail() directly
  • Use a library like html2text/html2text to deprecate methods in \Drupal\Core\Mail\MailFormatHelper
  • If an email specifies its content type as text/html respect that and allow it to send
  • Find a way to expose settings like the Swiftmailer module for configuring transport options

Original issue summary

Might be a good first step in de-WTF-ing our mail system.

Combine two tests to one in d7 MigrateFieldTest and MigrateFieldInstance

$
0
0

Problem/Motivation

d7/MigrateFieldTest and d7/MigrateFieldInstanceTest both have two tests which normally indicates a there is something different in the preparation for the test (different modules installed or changes to the source database) but in this case there are none. That is the two tests are identical except for the assertions run after the migration is finished. There is no need for two separate tests. The migration can be run once and then all the assertions

Also, an annoyance factor when working with those tests.

Steps to reproduce

Proposed resolution

Move the assertions from the second test to the first tests and remove the second test.

Remaining tasks

patch, review, commit

Deprecate MailFormatHelper in favor of html2text/html2text library

$
0
0

Problem/Motivation

We shouldn't have to maintain or own HTML to text code. Especially since we actually don't really do anything about maintaining it.

There was one bugfix in there in there last/this year (for 7.x), one in 2011 and most of the code is unaltered since 2007.

Proposed resolution

Deprecate it in favor of html2text/html2text, which is what swiftmailer.module is already using. Has 450k installs on packagist.

Problem is, it has *very* different opinions on what a plaintext version of a HTML text should look like. Literally every assert in \Drupal\system\Tests\Mail\HtmlToTextTest::testTags() is failing.

I have no idea if that is something that we can do for 8.x, especially thinks like the different link handling. Although that is configurable and other options might be more like our existing output.

Remaining tasks

Look into those test fails, look what of that is OK. We might also want to convert them to unit tests first to make it easier to change.

User interface changes

API changes

Data model changes

rdf comment storage load should not load NULL comments

$
0
0

Problem/Motivation

When deleting all comments from nodes, site breaks throwing error.
It seems like current if is not sufficiently filtering and not covering all use cases.

I'll attach resolution proposition.

Error: Call to a member function url() on null in rdf_comment_storage_load() (line 243 of /var/www/drupal/public_html/web/core/modules/rdf/rdf.module) #0 [error]
/var/www/drupal/public_html/web/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php(705): rdf_comment_storage_load(Array)
#1 /var/www/drupal/public_html/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(427): Drupal\Core\Entity\ContentEntityStorageBase->invokeStorageLoadHook(Array)
#2 /var/www/drupal/public_html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(242): Drupal\Core\Entity\Sql\SqlContentEntityStorage->doLoadMultiple(Array)
#3 /var/www/drupal/public_html/web/core/includes/entity.inc(280): Drupal\Core\Entity\EntityStorageBase->loadMultiple(Array)
#4 /var/www/drupal/public_html/web/core/modules/comment/src/Entity/Comment.php(193): entity_delete_multiple('comment', Array)
#5 /var/www/drupal/public_html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(367): Drupal\comment\Entity\Comment::postDelete(Object(Drupal\comment\CommentStorage), Array)
#6 /var/www/drupal/public_html/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(769): Drupal\Core\Entity\EntityStorageBase->delete(Array)
#7 /var/www/drupal/public_html/web/core/lib/Drupal/Core/Entity/Entity.php(395): Drupal\Core\Entity\Sql\SqlContentEntityStorage->delete(Array)
#8 /var/www/drupal/public_html/web/modules/custom/disposable_data_cleanup/src/DisposableDataCleanupService.php(311): Drupal\Core\Entity\Entity->delete()
#9 /var/www/drupal/public_html/web/modules/custom/disposable_data_cleanup/src/Utility/IrtDisposableBatchHelper.php(33):
Drupal\disposable_data_cleanup\DisposableDataCleanupService->processDisposableBatch(Array)
#10 /var/www/drupal/public_html/vendor/drush/drush/commands/core/drupal/batch.inc(163): Drupal\disposable_data_cleanup\Utility\IrtDisposableBatchHelper::processBatch(Array,
Object(DrushBatchContext))
#11 /var/www/drupal/public_html/vendor/drush/drush/commands/core/drupal/batch.inc(111): _drush_batch_worker()
#12 /var/www/drupal/public_html/vendor/drush/drush/includes/batch.inc(98): _drush_batch_command('1617')
#13 /var/www/drupal/public_html/vendor/drush/drush/commands/core/core.drush.inc(1212): drush_batch_command('1617')
#14 /var/www/drupal/public_html/vendor/drush/drush/includes/command.inc(422): drush_core_batch_process('1617')
#15 /var/www/drupal/public_html/vendor/drush/drush/includes/command.inc(231): _drush_invoke_hooks(Array, Array)
#16 /var/www/drupal/public_html/vendor/drush/drush/includes/command.inc(199): drush_command('1617')
#17 /var/www/drupal/public_html/vendor/drush/drush/lib/Drush/Boot/BaseBoot.php(67): drush_dispatch(Array)
#18 /var/www/drupal/public_html/vendor/drush/drush/includes/preflight.inc(66): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#19 /var/www/drupal/public_html/vendor/drush/drush/drush.php(12): drush_main()
#20

{main}
.
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Call to a member function url() on null in /var/www/drupal/public_html/web/core/modules/rdf/rdf.module on line 243 #0 /var/www/drupal/public_html/web/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php(705): rdf_comment_storage_load(Array)
#1 /var/www/drupal/public_html/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(427): Drupal\Core\Entity\ContentEntityStorageBase->invokeStorageLoadHook(Array)
#2 /var/www/drupal/public_html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(242): Drupal\Core\Entity\Sql\SqlContentEntityStorage->doLoadMultiple(Array)
#3 /var/www/drupal/public_html/web/core/includes/entity.inc(280): Drupal\Core\Entity\EntityStorageBase->loadMultiple(Array)
#4 /var/www/drupal/public_html/web/core/modules/comment/src/Entity/Comment.php(193): entity_delete_multiple('comment', Array)
#5 /var/www/drupal/public_html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(367): Drupal\comment\Entity\Comment::postDelete(Object(Drupal\comment\CommentStorage), Array)
#6 /var/www/drupal/public_html/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(769): Drupal\Core\Entity\EntityStorageBase->delete(Array)
#7 /var/www/drupal/public_html/web/core/lib/Drupal/Core/Entity/Entity.php(395): Drupal\Core\Entity\Sql\SqlContentEntityStorage->delete(Array)
#8 /var/www/drupal/public_html/web/modules/custom/disposable_data_cleanup/src/DisposableDataCleanupService.php(311): Drupal\Core\Entity\Entity->delete()
#9 /var/www/drupal/public_html/web/modules/custom/disposable_data_cleanup/src/Utility/IrtDisposableBatchHelper.php(33): Drupal\disposable_data_cleanup\DisposableDataCleanupService->processDisposableBatch(Array)

Proposed resolution

Make rdf_comment_storage_load properly handle NULL returns from getCommentedEntity and hasParentComment, essentially not try to use a NULL entity.

Remaining tasks

Patch
Write Test
Review
Commit

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Replace \Drupal\Component\Utility\Environment::checkMemoryLimit with a PHP memory checking helper class and service

$
0
0

Problem/Motivation

In #2583041: [PP-2] GD toolkit & operations should check for available memory we identified how \Drupal\Component\Utility\Environment::checkMemoryLimit, being a static method, cannot be unit tested under assumption of unavailable memory.

Proposed resolution

Spin off a part of #2583041-66: [PP-2] GD toolkit & operations should check for available memory:

  • Add a EnvironmentMemory class that manage calculating the actual memory size from php.ini, and provide methods to return total, used and free memory, as well as methods to check against a memory requirement (either total or remaining available).
  • Enable providing PHP Unit test that stub the currently used memory.
  • Add PHP unit tests.
  • Deprecate \Drupal\Component\Utility\Environment::checkMemoryLimit.

Remaining tasks

User interface changes

none

API changes

\Drupal\Component\Utility\Environment::checkMemoryLimit deprecated.

Data model changes

none

Create an upgrade path to determine if default_config_hash should be added (2625258)

$
0
0

Problem/Motivation

Follow-up to #2625258: LocaleConfigManager::updateConfigTranslations() deletes translations if a config object's name happens to match that of a shipped configuration object which adds a hash to configuration files. We need to provide a upgrade path for existing sites.

Proposed resolution

Discussed with @catch and @Gábor Hojtsy. We agreed that the upgrade path should:

  • check all active config and if name does not match - do not add hash
  • If name matches but has custom config translations - do NOT add hash
  • Otherwise add hash.

This way we don't get data loss and most sites will get localisations for default config.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

Existing configuration entities created through the installer have a default_config_hash key set.


Make a programmatic way to add contrib widgets to custom forms

$
0
0

Problem/Motivation

Adding widgets to custom forms is limited to those provided by default with each field type. The Field API stores settings in configuration files so widget settings are stored against the entity type's configuration file.

But there are instances when it would be useful for the UI to take advantage of widgets from contributed modules on custom forms. Currently the only way I've found to do this is to simulate the render array expected by the widget. This doesn't always work as expected, especially when the widget attempts to load settings from the Field API that won't exist for custom forms.

Ideas are welcome on how to make this work. Or if you have found a way to get this going (my case is using Entity Browser) I'd appreciate it!

Proposed resolution

Create ability to "instantiate" a widget against a custom field (such as on custom admin forms).

Remaining tasks

* Decide on an implementation.
* Architect the implementation.
* Implement the changes to the codebase.
* Review and submit for addition to Drupal core.

User interface changes

None (yet).

API changes

Unsure.

Data model changes

Unsure.

Call to a member function getConfigDependencyName() on null in Drupal\editor\Entity\Editor->calculateDependencies()

$
0
0

Problem/Motivation

When I try to uninstall modules, I get a php error:

 Call to a member function getConfigDependencyName() on null in
Drupal\editor\Entity\Editor->calculateDependencies() (line 110 of
/srv/www/htdocs/web/core/modules/editor/src/En

Steps to reproduce

Select modules to uninstall in the GUI

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Invalid byte sequence when using PostgreSQL and a language other than English is active

$
0
0

I get this error from drupal everytime I access a page with a blog entry:

# warning: pg_query() [function.pg-query]: Query failed: ERROR: invalid byte sequence for encoding "UTF8": 0x97 HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding". in /local/var/www/drupal-6.10_postgresql/includes/database.pgsql.inc on line 139.
# user warning: in /local/var/www/drupal-6.10_postgresql/modules/locale/locale.module on line 365.

# warning: pg_query() [function.pg-query]: Query failed: ERROR: invalid byte sequence for encoding "UTF8": 0x97 HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding". in /local/var/www/drupal-6.10_postgresql/includes/database.pgsql.inc on line 139.
# user warning: in /local/var/www/drupal-6.10_postgresql/modules/locale/locale.module on line 381.

I can reproduce this problem on different drupal installations and with different languages activated so I think it has to be something with the blog module and not the translations.

To reproduce:

  1. use postgresql 8.3.x
  2. activate blog module
  3. create a blog entry
  4. install and activate as default a language other than english. (I have try this with the spanish and danish translations)
  5. access any page that shows a blog entry

Any ideas? This is a big problem on busy sites because every page view with blog entries generates error entries by the dblog module

SQL source plugins: allow defining conditions in migration yml

$
0
0

Problem/Motivation

It would be great to be able to use conditions to narrow down your SQL source data for content/config entity types. The resulting functionality would provide similar capabilities to how you can migrate nodes one content type at a time, and the same for taxonomy terms -- but for users (by role), menu links (by menu), and so on.

The functionality would let you narrow your data during the source/extraction phase, instead of during the process/transformation phase (which you can do using skip_on_value/empty + method: row).

Benefits would include general tidiness of data :) And! Speed/performance!

(discussion of ideas/concerns/etc. started on Slack in mid-July 2019)

Proposed resolution

Ideas so far...

  • Generic system for skipping rows based on arbitrary/arbitrary-ish conditionals.
  • ^^ in SourcePluginBase and/or SqlBase.
  • Migration yml would have a conditions array with keyed values that get passed to the SQL source plugin.

Remaining tasks

(reviews needed, tests to be written or run, documentation to be written, etc.)

User interface changes

(New or changed features/functionality in the user interface, modules added or removed, changes to URL paths, changes to user interface text.)

API changes

(API changes/additions that would affect module, install profile, and theme developers, including examples of before/after code if appropriate.)

Data model changes

(Database or configuration data changes that would make stored data on an existing site incompatible with the site's updated codebase, including changes to hook_schema(), configuration schema or keys, or the expected format of stored data, etc.)

Release notes snippet

(Major and critical issues should have a snippet that can be pulled into the release notes when a release is created that includes the fix)

AssertLegacyTrait::assert(No)Text() in functional tests still have a message passed in

$
0
0

Problem/Motivation

Some of the current calls to AssertLegacyTrait::assert(No)Text() in functional tests still have a message passed in, even if the methods do not take that in. We need to remove the messages from the calls and inline them as comments where appropriate.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Viewing all 295290 articles
Browse latest View live


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