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

Make serializer customizable Cache\DatabaseBackend

$
0
0

Problem/Motivation

The Drupal\Core\KeyValueStore\DatabaseStorage uses a configurable serializer to store PHP objects. This serializer is injected as a service in core. The pre-configured serializer used there Drupal\Component\Serialization\PhpSerialize:

  keyvalue.database:
    class: Drupal\Core\KeyValueStore\KeyValueDatabaseFactory
    arguments: ['@serialization.phpserialize', '@database']
  serialization.phpserialize:
    class: Drupal\Component\Serialization\PhpSerialize

This architecture allows contrib modules like https://www.drupal.org/project/igbinary to swap the serializer. For example igbinary shrinks the size of larger serialized PHP objects to one third without losing any performance. (In some cases the performance is increased as well.)

Having this kind of memory saving would be a huge benefit for all kind of drupal caches that store serialized PHP objects, especially if there using in memory solutions like memcache. Systems like redis or even the database will benefit from igbinary as well.

Unfortunately the Drupal\Core\Cache\DatabaseBackend and the Drupal\Core\Cache\MemoryBackend use a hard-coded PHP serialization. Therefore the could not be easily improved by modules like https://www.drupal.org/project/igbinary

Proposed resolution

Follow the pattern of Drupal\Core\KeyValueStore\DatabaseStorage and Drupal\Core\KeyValueStore\DatabaseStorageExpirable and inject the serialize as a service to the Drupal\Core\Cache\DatabaseBackend.

The default configuration in core should then "remain" as it is and inject Drupal\Component\Serialization\PhpSerialize.

Even if this improvement makes sense for the Drupal\Core\Cache\MemoryBackend as well, @catch decided to not modify it in core. This backend is heavily used in the tests which will be more complicated afterwards. Therefore the igbinary contrib module will provide it's own backend as drop-in replacement.

Remaining tasks

Review the existing patch.

User interface changes

None.

API changes

Similar to Drupal\Core\KeyValueStore\KeyValueDatabaseFactory and Drupal\Core\KeyValueStore\DatabaseStorage the constructor of Drupal\Core\Cache\DatabaseBackend an its factory need to be prepared for dependency injection.
In addition we define a new interface Drupal\Component\Serialization\ObjectAwareSerializationInterface that just extends Drupal\Component\Serialization\SerializationInterface to clearly indicate that implementing Serializers are suitable for PHP Object serialization.

Old:

DatabaseBackendFactory::__construct(Connection $connection, CacheTagsChecksumInterface $checksum_provider);
DatabaseBackend::__construct(Connection $connection, CacheTagsChecksumInterface $checksum_provider, $bin);

New:

interface ObjectAwareSerializationInterface extends SerializationInterface {}

DatabaseBackendFactory::__construct(ObjectSerializationInterface $serializer, Connection $connection, CacheTagsChecksumInterface $checksum_provider);
DatabaseBackend::__construct(ObjectSerializationInterface $serializer, Connection $connection, CacheTagsChecksumInterface $checksum_provider, $bin);

Data model changes

None.


More random fails in UpdatePathTestBase tests: "settings.cache failed with: missing schema"

$
0
0

Problem/Motivation

After #2749955: Random fails in UpdatePathTestBase tests, we are continuing to see random fails in UpdatePathTestBase tests. For example, from #2627512-139: Datetime Views plugins don't support timezones:

https://www.drupal.org/pift-ci-job/532197

https://www.drupal.org/pift-ci-job/532126

https://www.drupal.org/pift-ci-job/532196

https://www.drupal.org/pift-ci-job/532198

When you look at these reports, there isn't a clear symptom other than

fail: [Browser] Line 248 of core/modules/system/src/Tests/Update/UpdatePathTestBase.php:
GET http://localhost/checkout/update.php/start?id=2&op=do_nojs returned 0 (0 bytes).

fail: [Other] Line 263 of core/modules/system/src/Tests/Update/UpdatePathTestBase.php:
Schema key block.block.bartik_login:settings.cache failed with: missing schema

at some point in the output.

Given the recent work that has gone into test isolation (need links to the related issues) for APCu, database, and filesystem collisions during parallel tests, these new fails more baffling.

Proposed resolution

Until this can be isolated, I think we need to consider two radical options

- Disable parallel tests
- or Force a fresh testbot for each full run

that should(?) point us in the right direction.

Remaining tasks

User interface changes

API changes

Data model changes

Match States API required fields theming with Forms API

$
0
0

Currently states.js just adds a "form-required" class to the dependee form element when marking it as required.
With this patch, I propose to improve this by matching the appearance of a plain Forms API required field, by adding a themable marker at the end of the corresponding label, identical by default to that defined by theme_form_required_marker.

Ignore 'Transfer-Encoding' header in EntityResourceTestBase::testGet

$
0
0

Problem/Motivation

EntityResourceTestBase compares headers between HEAD and GET requests in testGet. It has a list of headers to ignore, which makes a lot of sense. However, it's currently missing the 'Transfer-Encoding' header which could be present on GET requests, depending on web server configuration, but obviously don't make much sense on a HEAD request. So it means running tests can fail, depending on web server configuration, so would be good to remove that fail factor.

Tentatively marked as bug report. It's kind of between that and task for me.

Proposed resolution

Add 'Transfer-Encoding' to the list of ignored headers in

EntityResourceTestBase::testGet()

.

Remaining tasks

User interface changes

N/A

API changes

N/A

Data model changes

N/A

All serialized values are strings, should be integers/booleans when appropriate

$
0
0

Problem/Motivation

JSON produced by the HAL and JSON normalizers provides all data values as strings. This makes it difficult for strongly typed uses of the REST interface to interact with the JSON payload. Examples include: client libraries, auto-generated documentation, and schemas. By providing BooleanItems as booleans, IntegerItems as integers, and so on, the values output in JSON will have the correct type without client-side casting. This has the nice side effect of better lining up output with expectations of the Typed Data API.

Proposed resolution

Add additional field item normalizers casting values to explicitly match the type implied by the field item class.

Remaining tasks

None.

User interface changes

None.

API changes

None: this is an opt-in change. Existing sites continue to get the exact same responses, with booleans and integers as strings.

Only new sites will get the "correct" output by default.

See the change record: https://www.drupal.org/node/2837696.

Data model changes

None.

Entity reference field normalization has target_type and target_uuid, but not used in denormalization

$
0
0

#2060677: Add target_type, target_uuid to serialized output of entity reference fields in non-HAL formats added target_type and target_uuid to the normalization. But didn't add denormalization support. It was intended to become a follow-up, but that follow-up was never filed. Until now.

#2060677-21: Add target_type, target_uuid to serialized output of entity reference fields in non-HAL formats:

Should we also be adding a new EntityResolverInterface here for denormalizing?

#2060677-22: Add target_type, target_uuid to serialized output of entity reference fields in non-HAL formats:

We have the right tools already I think, we just need serialization module to actually use them. I think we should do that in a follow up to this though, and just keep this for adding this to the denormalized data. Sound ok?

Drupal 8 Views trim text is not working.

$
0
0

Hi there,
This is my first time submit a issue in Drupal, hope i am doing everything right. I am working on Drupal 8 views right now and i figure out views's "Trim this field to a maximum number of characters" does't work correct.

I figured out only title trim not work, i have tried trim on a body fields, it works great. I haven't try other fields yet.

You guys can check on first pictures, when apply trim text to title, title will disappear.

I don't know if this is a bug or my setting problem, so i am trying to use this submit a issue.

Thanks!

Views Trim text

Views trim text

Make it easier to write on4xx() exception subscribers

$
0
0

Problem/Motivation

We have a really flexible exception system which was a bit designed around the usecase of HTML, which requires you to have a different behaviour for every XYZ HTTP status code.
For the case of JSON/XML etc. this is though not the common case so its really cumbersome to create for example a 40X method for every possible one.

Proposed resolution

Introduce onX** methods, which catches all respecting cases.

Remaining tasks

User interface changes

API changes

Data model changes


inaccurate description for EntityTypeManager::getHandler()

$
0
0

API page: https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Entity!EntityType...

> Creates a new handler instance for a entity type and handler type.

That's not true. It caches the instantiated handlers and only creates one if needed.

Rather than say 'creates', the documentation should explicitly state that handlers are per entity type, not per entity.

This is so developers know that they may statically cache something in handler, but also to ensure the cache is per entity if necessary.

change sub-headings into bold Of Help link

$
0
0

change sub-headings into bold of help link on extent menu

URL
sitename/admin/help/block

Style Javascript messages in the offcanvas tray

$
0
0

Problem/Motivation

For 8.2 only warning messages were styled for the off canvas tray singe they were only needed for the tabledrag save alert. As more modules extend the offcanvas tray all messages will need to be supported.

Proposed resolution

Style all messages for the off-canvas tray.

Warning:

Error:

Status:

Message Multiple:

Message long:

Remaining tasks

  • Style warnings
  • Style errors
  • Style alerts
  • Add rtl styles
  • Add hover states
  • Test in all themes
  • Teas cros browser
  • Test for touch devices
  • Test responsive

User interface changes

All messages are styled for the off canvas tray (dark background)

API changes

None

Data model changes

None

Handle offcanvas differently at lower widths

$
0
0

Right now the offcanvas tray displaces the "main canvas" which under a certain width look weird.

Should we really use displace() and try to show the main canvas when the tray is open at widths < 400 px?

If a toolbar item besides the admin menu is open when going into edit mode it is not closed.

$
0
0

Problem/Motivation

Steps to reproduce
Enable Settings tray module
Visit a non-admin page
Open the "Shortcuts" tray from the toolbar.
Click "Edit" in the toolbar to enter Editing mode.
The Shortcuts tray disappears but there is black area left.

Proposed resolution

Close all toolbar trays when entering edit mode.

Remaining tasks

User interface changes

API changes

Data model changes

Not work correctly ROOMS_INCREASE

$
0
0

Hello, I have created a module to increase the price per day not proportional, for example 1 day 10€ 2 days 15€ 3 days 18€
the module is similar that rooms_pricing per cosecutive days
it's works correctly

The problem is that I use the complents with porcentage. In my case a ski rental:

1 day without boots 27,50€ with boots +20%
2 days without boots 50,50€; with boots +20%=60.60€
...

The problem is, it only calculate correctly the first day.

I think that the problem is that in the file

sites\all\modules\rooms\modules\rooms_pricing\includes

the $base_price is not correct, if modify the $bise_price for 60.60 manualy, it works correctly

case ROOMS_INCREASE:

$price += $base_price * ($modifier['#amount'] * $modifier['#quantity']) / 100 ;
$reply['log']['modifiers'][$source][ROOMS_DYNAMIC_MODIFIER]['op'] = ROOMS_INCREASE;
$reply['log']['modifiers'][$source][ROOMS_DYNAMIC_MODIFIER]['post'] = $price;

break;

Do you have some idea
thanks

Message "Required by Drupal (Fields Pending Deletion)" baffles users

$
0
0

Problem/Motivation

When disabling modules that create fields this error is sometimes displayed. The message does not make it clear what caused the issue or how to fix it which is frustrating for users.

If you want to fix the underlying issue that causes this message check out http://drupal.org/node/943772.

Proposed resolution

Change message to be more descriptive and more helpful in resolving the issue

There are Fields pending deletion that were created by a module you just tried to disable. Delete offending fields now or try running cron, it might fix this issue.

The error message is produced by field_system_info_alter() in core/modules/field/field.module.

Remaining tasks

  1. Finalize the message text
  2. Write a patch

Original report by [joachim]

I saw this message in my modules list and it completely baffled me.
I only found out I had to run cron thanks to a comment buried in an issue on a contrib module somewhere.
When this text appears in the module admin page it should be linked to further help.


Let TimestampItem (de)normalize to/from ISO timestamps, not UNIX timestamps, for better DX

$
0
0

We have added a date field to a node type called EVENT.

When we use the default admin edit form for the node we have noticed that the values for the date are saved in the database -2hours from what is entered.

There never seems to be any problem when viewing nodes or editing nodes. BUT we are using a REST service to access and write nodes... when we do this to doesn't add or remove the 2 hours either way...

Changing Time Zone of Default Country doesn't change anything either way...

We're a bit confused by this and are wondering what we may be doing wrong. Has anybody else encountered this problem?

Multilingual Migrations for Non-Drupal Sources

$
0
0

Motivation

So there's a flurry of activity concerning multilingual Drupal content from D6 & D7 being properly migrated (#2208401: [META] Multilingual migrations / i18n meta issue), but I'm not seeing much if anything concerning non-Drupal imports for multilingual content. Point of fact, I'm having trouble coming up with good examples of how multilingual migrations are intended to work, let alone actual working examples using Drupal or other sources.

Proposed resolution

I'd like to use this thread to compile migration solutions or examples that successfully implement multilingual content. Ultimately, that would become a documentation page, or depending on how things go a feature request or module.

Groundwork

So since I had an immediate need and was looking for solutions I ended up finding #2313265: How import Multilingual Content with Migrate Module. While it originated Pre-D8, @digitaldonkey had a good solution for a POST_ROW_SAVE event in D8. I liked it, but it wasn't flexible enough for me to I took it and made it a little more broadly based. I updated the 'updateTranslations' function of the original:

/**
   * MigrateEvents::POST_ROW_SAVE event handler.
   *
   * @param MigratePostRowSaveEvent $event
   *   Instance of Drupal\migrate\Event\MigratePostRowSaveEvent.
   */
  public function updateTranslations(MigratePostRowSaveEvent $event) {

    $row =  $event->getRow();

    if ($row->hasSourceProperty('constants/available_languages')) {

      // These are defined in migration.yml.
      $available_languages = $row->getSource()['constants']['available_languages'];
      $default_language = $row->getDestination()['langcode'];

      // Unset default language from available languages.
      unset($available_languages[$default_language]);

      $migrated_entity = $event->destinationIdValues[0];
      $dest_config = $event->getMigration()->getDestinationConfiguration();
      $dest_plugin = explode(':', $dest_config['plugin']);

      if ($dest_plugin[0] == 'entity') {
        $entity = \Drupal::entityTypeManager()
          ->getStorage($dest_plugin[1])
          ->load($migrated_entity);

        foreach ($available_languages as $key => $lang_map) {

          $translated_entity = $entity->addTranslation($key);
          foreach ($lang_map as $field => $source) {
            $translated_entity->$field = $row->getSourceProperty($source);
          }
          $translated_entity->save();

        }

        $map = $event->getMigration()->getIdMap();
        $map->saveIdMapping($event->getRow(), array($migrated_entity));
      }
    }
  }

What this allows you to do is declare translations in your YAML file by adding available translations as constants. So your source would look something like

source:
  ...
  constants:
    available_languages:
      en:
      es:
        title: title_spanish

Where title is the name of the field you're entering and title_spanish would be the field coming in from the source. This is perfect for a lightweight translation of content from the same source. Note that it only works on entities and that the main langcode MUST be set in the process.

For bulkier translations that need processing or those coming from a different source, I put together a custom destination. This takes a separate migration and appends identically ID'd translations to it.


namespace Drupal\custom_migrate\Plugin\migrate\destination;

use Drupal\Component\Plugin\DependentPluginInterface;
use Drupal\Core\Entity\DependencyTrait;
use Drupal\migrate\Plugin\MigratePluginManager;
use Drupal\migrate\Plugin\MigrationPluginManagerInterface;
use Drupal\Core\Language\LanguageManagerInterface;
use Drupal\Core\Plugin\ContainerFactoryPluginInterface;
use Drupal\migrate\Plugin\MigrationInterface;
use Drupal\migrate\Row;
use Symfony\Component\DependencyInjection\ContainerInterface;
use Drupal\migrate\Plugin\migrate\destination\DestinationBase;

/**
 * Provides Configuration Management destination plugin.
 *
 * Persist data to the config system.
 *
 * When a property is NULL, the default is used unless the configuration option
 * 'store null' is set to TRUE.
 *
 * @MigrateDestination(
 *   id = "entity_translation"
 * )
 */
class EntityTranslation extends DestinationBase implements ContainerFactoryPluginInterface, DependentPluginInterface {

  use DependencyTrait;

  /**
   * The config object.
   *
   * @var \Drupal\migrate\Plugin\MigrationInterface
   */
  protected $old_migration;

  /**
   * The language manager.
   *
   * @var \Drupal\Core\Language\LanguageManagerInterface
   */
  protected $language_manager;

  /**
   * The process plugin manager.
   *
   * @var \Drupal\migrate\Plugin\MigratePluginManager
   */
  protected $processPluginManager;

  /**
   * The migration plugin manager.
   *
   * @var \Drupal\migrate\Plugin\MigrationPluginManagerInterface
   */
  protected $migrationPluginManager;

  /**
   * Constructs a Config destination object.
   *
   * @param array $configuration
   *   A configuration array containing information about the plugin instance.
   * @param string $plugin_id
   *   The plugin ID for the plugin instance.
   * @param mixed $plugin_definition
   *   The plugin implementation definition.
   * @param \Drupal\migrate\Plugin\MigrationInterface $migration
   *   The migration entity.
   * @param \Drupal\Core\Language\ConfigurableLanguageManagerInterface $language_manager
   *   The language manager.
   */
  public function __construct(array $configuration, $plugin_id, $plugin_definition, MigrationInterface $migration, MigrationPluginManagerInterface $migration_plugin_manager, MigratePluginManager $process_plugin_manager, LanguageManagerInterface $language_manager) {
    parent::__construct($configuration, $plugin_id, $plugin_definition, $migration);
    $this->migrationPluginManager = $migration_plugin_manager;
    $this->migration = $migration;
    $this->processPluginManager = $process_plugin_manager;
    $this->language_manager = $language_manager;
  }

  /**
   * {@inheritdoc}
   */
  public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition, MigrationInterface $migration = NULL) {
    return new static(
      $configuration,
      $plugin_id,
      $plugin_definition,
      $migration,
      $container->get('plugin.manager.migration'),
      $container->get('plugin.manager.migrate.process'),
      $container->get('language_manager')
    );
  }

  /**
   * {@inheritdoc}
   */
  public function import(Row $row, array $old_destination_id_values = array()) {

    $migration_id = $this->configuration['migration'];
    $migration = $this->migrationPluginManager->createInstance($migration_id);

    // TODO: I think this only works right now if the keys and key labels match, so I'll need to expand later
    $source_id_values = $row->getSourceIdValues();

    $destination_ids = $migration->getIdMap()->lookupDestinationID($source_id_values);

    $dest_config = $migration->getDestinationConfiguration();
    $dest_plugin = explode(':', $dest_config['plugin']);

    $entity = \Drupal::entityTypeManager()
      ->getStorage($dest_plugin[1])
      ->load($destination_ids[0]);

    $lang = $row->getDestinationProperty('langcode');

    // TODO: Validate langcode against list of site languages

    $translated_entity = $entity->addTranslation($lang, $row->getDestination());
    $translated_entity->save();

    return $destination_ids;

  }

  /**
   * {@inheritdoc}
   */
  public function fields(MigrationInterface $migration = NULL) {
    // @todo Dynamically fetch fields using Config Schema API.
  }

  /**
   * {@inheritdoc}
   */
  public function getIds() {
    $ids['config_name']['type'] = 'string';
    return $ids;
  }

  /**
   * {@inheritdoc}
   */
  public function calculateDependencies() {
    $provider = explode('.', $this->config->getName(), 2)[0];
    $this->addDependency('module', $provider);
    return $this->dependencies;
  }

}

It's still very rough, but once it's in place you can use it to translate entities by adding this destination:

destination:
  plugin: entity_translation
  migration: original_content

Where original_content is the targeted migration. Note that it's still very rough, but is certainly a step in the right direction. Once again, it will only work for entities and the langcode needs to be set in the process.

Help Text does not override Link text 'This must be ...'

$
0
0

Problem/Motivation

When creating a link field, the optional help text for the field is not rendered. Instead, there are string constants that are displayed based off of the type of url the field expects (internal vs external). I don't know of other examples where Drupal is prescriptive on the language used for a field, but it makes sense to me that if I provide help text; it should be displayed instead of the default, 'This must be...'.

Also, I understand that there may be a theming solutions for this problem. If that is the preferred fix, I think there needs to be more documentation on how to correctly implement it and the help text for the field should warn authors, e.g "this behaves differently than you might expect".

Note: The attached patch file is the output of a linux diff in which I had to have two copies of the file (LinkWidgetBU.php and LinkWidget.php). If necessary, I can provide a git version.

Proposed resolution

Check if a content author has provided help text for link field, if so , use it.

Remaining tasks

User interface changes

API changes

Data model changes

DatabaseSchema_mysql -> tableExists returns false possitives

$
0
0

When using DB users that have access to multiple databases, function tableExists tries to determine if a table exists by catching an error when selecting from a table, however the exception is not always catch and the function returns a false positive.

Attached is a proposed patch with a more reliable way to test for tables existence and still faster than selecting from infromation_schema.

This issue happened to me when trying to enable module dblog:

  1. In my script I load a DB backup from Dev, Stage or Prod environment which may or may not have dblog module enabled
  2. The script will always try to disable and uninstall (drush dis -y dblog && drush pm-uninstall -y dblog)
  3. The forcefully remove watchdog table through mysql command (mysql -u root -e "drop table if exists ${site}_prod.watchdog;")
  4. Then enable dblog module, then the script fails because "Table watchdog already exists"

When applying the attached patch, the issue doesn't happen and it identifies correctly when tables exist or not.

Move Off-canvas related CSS from drupal.outside_in library to drupal.off_canvas

$
0
0

Problem/Motivation

Currently all the CSS in the Settings Tray module is in the drupal.outside_in library.

Presumably in #2784443: Move off-canvas functionality from Settings tray module into drupal.dialog.ajax library so that other modules can use it the off-canvas tray will need some of this CSS to look and behave correctly.

Proposed resolution

Move all needed CSS needed for the off-canvas tray to drupal.off_canvas.

Remaining tasks

Determine which CSS that is.
Also there is a lot of CSS to format form elements. Should that CSS be available to other modules that would like to put forms in the tray when Settings Tray is disabled?

If we do want to move the form CSS from Setting Tray should it be an option to use it in the tray or not. We could make loading the CSS for forms an option in data-dialog-options.

User interface changes

API changes

Data model changes

The drupal.outside_in library contains all the CSS in the module.

Viewing all 293246 articles
Browse latest View live


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