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

Improve js error when CKEditorPlugin plugin id doesn't match js plugin name

$
0
0

Problem/Motivation

Currently if a developer creates a plugin for a ckeditor plugin and the CKEditorPlugin.id and the name of the plugin as it is called in the Javascript don't match then they are met with this very un-useful error.

ckeditor.js?v=4.8.0+2018-04-18-security-patch:242 Uncaught TypeError: Cannot read property 'icons' of null

Proposed resolution

Make this error more useful. I am not really sure what the working should be, but I know that this isn't doing anyone any good.

This might also be an upstream issue.

Remaining tasks

Come up with better wording.
Find way to display this error to the use.

User interface changes

API changes

Data model changes


Make search button 100% width on small screens

$
0
0

This issue is created from a comment on #2936878: Umami Theme - follow-up - margin/padding left/right for search page elements
Specifically https://www.drupal.org/project/drupal/issues/2936878#comment-12468176

===
I did see this oddity with the search button though on mobile. Ideally, the button would be disconnected from the field on mobile and set at full width. This is because mobile devices need bigger "touch targets" for a variety of accessibility and UX reasons. Attaching a proposed mock-up of how this could look.
===

Current:

Proposed:

Follow-up for #2910211: fix all deprecation warnings

$
0
0

Problem/Motivation

Since #2910211: Allow computed exposed properties in ComplexData to support cacheability., implicit cacheability bubbling is deprecated, because there now finally is a way for normalizers to bubble cacheability metadata of the data they're normalizing.

As of #2870194: Ensure that process-isolated tests can use Symfony's PHPunit bridge to catch usages of deprecated code, deprecation errors result in test failures. But any deprecation errors that result in core test failures are ignored, for now.

Proposed resolution

Let's fix all deprecation errors for the deprecation that #2910211 added. This is then also fixing REST/Serialization technical debt. That deprecation is:

Implicit cacheability metadata bubbling (onto the global render context) in normalizers is deprecated since Drupal 8.5.0 and will be removed in Drupal 9.0.0. Use the "cacheability" serialization context instead, for explicit cacheability metadata bubbling. See https://www.drupal.org/node/2918937

Remaining tasks

  1. Find all the places.
  2. Fix them.

User interface changes

None.

API changes

None.

Data model changes

None.

Support optgroups for taxonomy selection list

$
0
0

Love the module, simple and much needed. However there doesn't seem to be Views support? I'm offering an exposed field to the users in Views and I would like the taxonomy selection list to have the nice format this module provides. Is this possible?

Custom blocks are no longer displayed and no longer appear in the custom block library

$
0
0

Hello,
After updating the core from 8.5.6 to 8.6.0, the custom block library appears empty. Custom block types still exist, but the custom block list is empty. Yet, they still exist in the database.

On the Block Layout page, custom blocks are listed in their place in the regions, but they do not appear with the message :

This block is defective or missing. The content is missing or you may need to activate the original module

.The TypedConfigManager.php file is identical to https://cgit.drupalcode.org/drupal/tree/core/lib/Drupal/Core/Config/Type... and I restarted the server without success.

The update operations for the blocks ran successfully :
block_content 8600 hook_update_n Add 'reusable' field to 'block_content' entities.
block_content add_views post-update Adds a 'reusable' filter to _reusable Custom Block views. _filter

The drush command php with

$ service=\Drupal :: service ('config.typed');
get_class ($ service);

return :

=> Drupal\Core\Config\TypedConfigManager {# 917
     + "_ serviceId": "config.typed",
   }

And after a press on entry :

=> "Drupal\Core\Config\TypedConfigManager"

Commenting out the line $context->setTypedDataManager($old_context->getTypedDataManager());in the core/lib/Drupal/Core/Plugin/Context/Context::createFromContext() file does not solve the problem.

Thank you for considering this case

Sample images cannot be generated while in a non-default workspace

$
0
0

Problem/Motivation

Generating a sample value for an image field is not possible in a non-default workspace.

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

N/A

API changes

TBD

Data model changes

N/A

Consider using the default PHP session ID instead of generating a custom one

$
0
0

Background

  1. The session id is a random value generated when a session is started. The session id is stored as a cookie in the browser such that on subsequent visits the data stored in the session can be loaded and reused. This issue is about the session id (cookie value) and not about the session name (cookie name).
  2. Drupal does not rely on built-in PHP methods for generating the session id currently, but uses a random 32 byte value.

  3. Before Drupal 7.24 different methods were used for anonymous vs. authenticated users, such that anonymous session ids were less expensive to generate.

    (see this commit; also note that the comment about "less random sessions" is wrong now).

  4. In contrast Symfony does not expect that the session-id is changed manually after the session has been started (see [...]\Session\Storage\Proxy\AbstractProxy::setId() and completely relies on the PHP built-in function session_regenerate_id() (see [...]\Session\Storage\NativeSessionStorage::regenerate().

Problem

  1. Our approach does not allow us to use session_regenerate_id().
  2. Instead, it is necessary to override NativeSessionStorage::regenerate completely and re-implement the mechanism in custom code (see #801278: Authenticated users getting "less random" session IDs).

Proposed solution

  1. PHP 5.4 ships with improvements regarding session ID generation:

    1. The INI setting session.entropy_file defaults to /dev/urandom or /dev/arandom if it is available (session.c (5.4) vs session.c (5.3)). On Windows, the Random API is used.
    2. On machines with /dev/urandom or /dev/arandom present on compile time session.entropy_length defaults to 32. On Windows, this seemingly has to be configured manually.
  2. According to the OWASP PHP Security Cheat Sheet:

    PHP's default session facilities are considered safe, the generated PHPSessionID is random enough, but the storage is not necessarily safe.

  3. When using the Drupal Crypt::randomBytes() function, the best (most secure and most performing) random source is selected automatically. The performance of both approaches was analyzed in #9. According to the results, no performance regression is to be expected when switching to PHP built-in session id generation.
  4. → Remove our custom code for generating session IDs and rely on the native PHP functionality instead.

API changes

Add link to add a new entity in an empty entity list controller table

$
0
0

Posted by xjm

This issue is a followup for #1781372: Add an API for listing (configuration) entities and #1783964: Allow entity types to provide menu items.

Problem/Motivation

Proposed resolution

Remaining tasks

User interface changes

Current behavior

list-controller-no-add-link.jpg

Intended behavior

list-controller-add-link.jpg


Get process plugin sets multiple for empty array

$
0
0

I have been scratching my head over this issue. The source sometimes has a blank offers, sometimes it is an array with data and sometimes it is an empty array - like this one:
https://api.hel.fi/linkedevents/v1/event/matko:16134/

With the latter example I was getting a bunch of Array index missing, extraction failed exceptions from the extract plugin, despite the skip_on_empty plugin running before, as you can see from my yml file:

  field_offers_is_free:
    -
      plugin: skip_on_empty
      method: process
      source: offers
    -
      plugin: extract
      index:
        - 0
        - is_free
  field_offers_info_url:
    -
      plugin: skip_on_empty
      method: process
      source: offers
    -
      plugin: extract
      default: false
      index:
        - 0
        - info_url
        - fi

I managed - in the end - to track down the reason for why our skip_on_empty plugin was never called: When Get sets $multiple to true, processRow in MigrateExecutable runs a foreach on the value - causing the whole skip_on_empty plugin to be skipped.

With this quick fix in modules/migrate/src/Plugin/migrate/process/Get.php's transform function things work fine for me:

    if (is_string($source)) {
      $a = is_array($return[0]);
      $b = !empty($return[0]);
      $this->multiple = $a && $b;
      return $return[0];
    }

Did I encounter a bug in Migrate or should I change my migration configuration?

[meta] Miscellaneous UI issues for the Layout Builder module

$
0
0

This is a meta-issue for tracking Miscellaneous UI issues for the Layout Builder module. Please open tasks for new issues using this one as the parent.

Convert DialogTest to a FunctionalJavascript test

$
0
0

The conversion of DialogTest is becoming too complex to be described as a simple conversion.

There are a few issues that need to be discussed.

External cron URL on status page is not absolute

$
0
0

in system.install the code seems to be invalid:

    $form['cron_url'] = array(
      '#markup' => '<p>' . t('To run cron from outside the site, go to <a href="!cron">!cron</a>', array('!cron' => $this->url('system.cron', array('key' => $this->state->get('system.cron_key')), array('absolute' => TRUE)))) . '</p>',
    );

To run cron from outside the site, go to <a href="/drupal8/cron/[KEY]?0%5Babsolute%5D=1">/drupal8/cron/[KEY]?0%5Babsolute%5D=1</a>

deprecate magic ServiceProvider file discovery; declare in services.yml

$
0
0

In the docs at https://www.drupal.org/docs/8/api/services-and-dependency-injection/alte...

> Note that if you want this service alteration to be recognized automatically, the name of this class is required to be a CamelCase version of your module's machine name followed by ServiceProvider, it is required to be in your module's top-level namespace Drupal\your_module_name, and it must implement \Drupal\Core\DependencyInjection\ServiceModifierInterface (which ServiceProviderBase does).

The relevant code is in discoverServiceProviders().

It seems a bit backwards to be doing magic discovery on a class name, when all other things of this sort are done by explicitly declaring the class -- eg dynamic routes, dynamic permissions.

In line with that pattern, we should declare a dynamic service provider in the module's services.yml file.

Notice: Undefined variable: label in _batch_process()

$
0
0

This might not happen a lot but when I was doing a batch process with issues, I received the error Notice: Undefined variable: label in _batch_process().

There is a case that the $label variable will not get set.

Track Layout override revisions on entities which support revisioning

$
0
0

Problem/Motivation

Revisionable entities with custom layout override only track layout changes incidentally when an entity is saved via the entity's edit form. In order to provide full layout revisioning, we should check that the entity type's bundle is revisionable and whether or not a new revision should be created before calling entity save in the Section Storage object.

Proposed resolution

Section storage for the field should determine if the entity's bundle is RevisionableEntityBundleInterface and check shouldCreateNewRevision(). If this is "true" then a new revision should be set on the entity before saving.

Remaining tasks

Write a patch
Write tests
Convince people

User interface changes

No direct changes to the UI. Layout saves for entity override would prompt the creation of new revision which would display the entity's revision tab. That "ui change" is incidental and expected.

API changes

None

Data model changes

None


Move UserInterface::hasRole to AccountInterface::hasRole

$
0
0

Problem/Motivation

The UserInterface defines a method hasRole, but the Drupal::currentUser() method returns an AccountInterface, which does not have this method unless the current user is authenticated, in which case a UserInterface object is returned.

Because of this, the method hasRole cannot be used without first checking the object type.

Proposed resolution

Since UserInterface extends AccountInterface, move the hasRole method there.

Remaining tasks

User interface changes

API changes

Data model changes

Change Inline Blocks workflow in layout build to match mocks

Connection::query() does not support 'target' option

$
0
0

Problem/Motivation

\Drupal\Core\Database\Connection::query() and ::defaultOptions() refer to a 'target' option where the database connection can be changed. This doesn't actually work, as you define the target when setting up the connection object - you can't change it later. This is was presumably copied as-is from the db_*() functions which did support the 'target' option but now should be removed from the documentation.

Proposed resolution

Remove the references to 'target'

Remaining tasks

Patch, discuss, commit

User interface changes

None

API changes

None

Data model changes

None

Migrate support for deleting items no longer in the incoming data

$
0
0

Problem/Motivation

We would like to add support for deleting items that are no longer present in the incoming data when a migration is run. This was a feature of Feeds in D7 and seems like a common need.

Proposed resolution

From @mikeryan in #15:

I really think this should be a distinct "purge" operation that gathers the currently-available source IDs from the source plugin, and scans the map table for any which aren't in that list to invoke the destination rollback on them. Now that I think about it, maybe it could even be an option on rollback - drush migrate-rollback --missing-from-source my_migration.

Remaining tasks

Add tests.

User interface changes

API changes

Data model changes

Allow CKEditor to apply style classes to media <drupal-entity tags to be more consistent with traditional image insertion usage

$
0
0

Our content people are familiar with CKeditor and they even know that they can insert an image and then assign classes that we've set up for them. Some of those classes are for example, lightbox and thumbnail-lightbox. When they insert an image using ckeditor they can click on the styles dropdown and choose thumbnail-lightbox which resizes their images to 100px wide AND assigns class lightbox to it which is then processed by jQuery so that, you guessed it, when someone clicks on that thumbnail the image pops up in a lightbox. We have a variety of other classes that do nifty things that the content people use as well. Note that we do use paragraphs for structured content in quite a few places, but the content people still like being able to insert images in the articles they write, and our readers enjoy the interspersed images.

Enter the amazing new Core Media functionality. "Hey content people, you can now reuse images by saving them in this fancy new media system!" That's great but they can no longer apply classes to these saved and reused images. First issue is that there is not anyway whatsoever to apply classes to the <drupal-entity tag this media system uses. Ckeditor won't assign our fancy classes, and if we manually add a class by editing the source, that class ends up on the <article tag instead of the <img tag inside of the article. I presented this conundrum to the drupal community and god-among-men wombatbuddy whipped up a contrib module here that moves the class from the article tag to the subordinate img tag. It works, it's awesome, he's awesome, that gets us halfway there! Now our content people can edit source, add a class like dropshadow to the <drupal-entity tag and when the page is saved the class is moved to the img tag and voila, drop shadow (or lightbox or ??) and it works great. That in itself was a massive step forward for us.

Still, ideally we should be able to set up classes in ckeditor that we can apply to <drupal-entity by simply using the style drop down box. So in the ckeditor class assignment section, where we previously had img.lightbox|Lightbox we also attempted to add drupal-entity.lightbox|Lightbox so as to allow assigning the lightbox class to drupal-entity tags that are inserted by the media functionality, just as we would if we used the traditional image insertion. Sadly this doesn't work, ckeditor doesn't allow drupal-entity to be a tag because of its hyphen, and ckeditor doesn't see actual drupal entities as pieces of content that can be manipulated by adding classes.

It seems like for consistency's sake and to maximize functionality, images that are inserted via the new media system should be just as versatile as images manually uploaded through ckeditor's image function. Of course other media types might also benefit from being able to assign classes, but images seem like the most pressing use case at present.

Thoughts? Better ways to approach this? We have quite a few classes that do different css and even jQuery things to images and none of these are available if the image comes from Media instead of being uploaded through ckeditor. Wombatbuddy's contrib module posted here got us a lot closer because now our content guys can at least view source and manually add class="lightbox thumbnail dropshadow" etc. Thoughts?

Thanks guys!!!

edit: User wombatbuddy added a contrib module that gets a step closer, it basically moves classes that are assigned to <drupal-entity to the subordinate image tag, so adding class="lightbox" to a<drupal-entity moves it to the img tag inside upon saving. See here: https://www.drupal.org/forum/support/post-installation/2018-08-31/how-to...

Viewing all 292961 articles
Browse latest View live


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