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

[upstream] CKEditor Style for <img> not working because it is an "image" widget

December 31, 2015, 7:15 am
$
0
0

I can not assign a class to the img element using the new "Styles Dropdown" for the relevant CKEditor profile. I can do so with block or inline elements, such as h1 or span elements.

Steps to replicate

  1. Navigate to "Configure" the "Full HTML" text format profile at admin/config/content/formats/manage/full_html
  2. Under "Toolbar Navigation" drag the "Style" dropdown menu into the active toolbar
  3. This will add a new vertical navbar to the profile page, "Styles Dropdown"
  4. Create a rule for an image element, i.e., img.testStyle|Test Style and save the configuration update
  5. Create a new "Base page" node and add an image to the body field
  6. Select the image either by directly clicking it or by using the CKEditor element selector in the ckeditor pane footer (the span#cke_1_bottom region) The styles button remains inactive

Note: If I change "img.testStyle|Test Style" to "image.testStyle|Test Style" I can apply the style through the styles dropdown, but CKEditor will wrap the img element in an image element, which itself will be "corrected" to two img tags.

Original markup:
<p><img alt="test" data-entity-type="file" data-entity-uuid="558bfafa-8b58-4c18-b529-41a58a53c795" src="/sites/default/files/inline-images/take-two.JPG" /></p>

Applied markup:
<p><image class="testStyle"><img alt="test" data-entity-type="file" data-entity-uuid="558bfafa-8b58-4c18-b529-41a58a53c795" src="/sites/default/files/inline-images/take-two.JPG" /></image></p>

"Corrected" markup:
<p><img class="testStyle" /><img alt="test" data-entity-type="file" data-entity-uuid="558bfafa-8b58-4c18-b529-41a58a53c795" src="/sites/default/files/inline-images/take-two.JPG" /></p>

↧
Search

Field rendering should respect configurable field display

November 15, 2017, 5:18 am
$
0
0

Problem

As discussed in #2353867: Title does not appear as a field in Manage Display, sitebuilders cannot configure the display of node's title even though they often want to.

Worse, even if developers use a hook to modify the node's title field adding ->setDisplayConfigurable('view', TRUE), and a sitebuilder then enables the title field in a view mode, it makes no difference. The template_preprocess_node and the node.html.twig take over the rendering of the node's title, ignoring the configured view displays.

The same problem applies to node 'created', node 'uid', taxonomy term 'name' and aggregator feed 'title' fields.

This issue has been split from #2353867: Title does not appear as a field in Manage Display to contain minimal, back-compatible changes to core in order to allow setDisplayConfigurable to be usable in contrib. The changes here are also a necessary prerequisite to solving the original issue in core.

A related problem is that the node title field template is used both when the node title is used for the page title in the page title block, and when the field is made configurable and displayed as part of an entity display.

Solution

1) Modify the logic of template_preprocess_* and templates so that they only usurp rendering if the field's display is not configurable.

2) Add an '#inline_field' variable to field templates so that the can distinguish whether they are called in a context where they should return block markup or inline markup. Use this for node title, uid and created fields.

3) Add an 'inline-field.html.twig' helper template to help themers developing field templates, and remove the duplicate core templates for node title, uid and created.

Results

If a developer makes these fields configurable, then a sitebuilder can configure them and the configuration will take effect.

The exception is when the entity is viewed on it's "own page" (in particular at its canonical route as the main display or potentially other cases such as the preview page). In that situation, there are a variety of problems related to EntityViewController's buildTitle method which are covered in #2941208: Title formatting broken due to flawed EntityViewController->buildTitle.

In general these changes are fully back-compatible provided that a developer has not previously used setDisplayConfigurable to enable configurable display of the relevant fields. This is discussed further in the change record.

↧
↧

Add chili sauce to Umami

February 8, 2018, 8:14 am
↧

Choose policy for defining font-weight on Umami theme

March 5, 2018, 10:58 am
$
0
0

Problem/Motivation

So far we can find several components using both syntax: font-weight: normal and font-weight: 400, or font-weight: bold and font-weight: 700 in the Umami theme.
font-weight: normal is the same asfont-weight: 400 and it's not a matter of browser compatibility since all accept both syntax.

Proposed resolution

Decide if we should use font-weight: normal/font-weight: 400 and font-weight: bold/font-weight: 700and implement it.

Remaining tasks

  • Decide which syntax we should use.
  • Review the current code to be sure we use the chosen syntax everywhere.
↧

Add experimental JSON API module

January 12, 2017, 1:29 pm
$
0
0

Problem/Motivation

See #2836165: New experimental module: JSON API and #2757967: API-first initiative.

Proposed resolution

Drop in of the JSON API module. After that, a plan with next steps towards stability is detailed in #2842148: The path for JSON API to "super stability".

Remaining tasks

  1. Provide a patch.
  2. Review the code. Some review + clean-up/refactoring has been done already by Wim Leers (rest.module maintainer) in #2829327: Review JSON API module for core-readiness.

User interface changes

No user interface changes.

API changes

No API changes. Only additions isolated in the experimental module.

Data model changes

No data model changes.

↧
↧

Views: No support for using an expressions (formulas) inside addField(), orderBy() methods.

February 12, 2018, 3:41 pm
$
0
0

I will quote some intro from this issue https://www.drupal.org/project/drupal/issues/2744069

Views allows magic query arguments to be used and translates them when the query is run so you can cache the original query, but keep the functionality of adding in the current user's ID for example.

The problem is that if we use expressions inside such methods $query->addField() or $query->addOrderBy() we can't use placeholders for later substitutions from hook_views_query_substitutions().

Here are an examples:

  // Custom views field based on Boolean.
  public function query() {
    $table_alias = $this->ensureMyTable();
    $this->query->addField(
      NULL,
      "FIND_IN_SET(:langcode, $table_alias.langs) > 0",
      'translation_status',
      [
        ':langcode' => '***TRANSLATION_VIEWS_TARGET_LANG***',
      ]
    );
  }

or

  // Custom views sorter based on Standard.
  public function query() {
    $table_alias = $this->ensureMyTable();

    // Mysql FIND_IN_SET func will return position of element,
    // when no element was found then it returns 0,
    // so we use "> 0" as condition to filter out untranslated rows.
    $this->query->addOrderBy(
      NULL,
      "FIND_IN_SET(:langcode, $table_alias.langs) > 0",
      $this->options['order'],
      'translation_status_sorter',
      [
        ':langcode' => '***TRANSLATION_VIEWS_TARGET_LANG***',
      ]
    );
  }

NOTE: Also I find very strange to pass query parameters in first case using 'placeholders' option and in the second one without it, I feel very confused)

Anyway the problem sits in the views_query_views_alter() function, I will reference it here: https://cgit.drupalcode.org/drupal/tree/core/modules/views/views.module?h=8.6.x#n704
We check substitutions for joins, conditions, but not for the fields and orderBy (technically orderBy just adds expressions to the fields' list)

Proposed solution:
Add $expressions = &$query->getExpressions() in the top of the function and add support for expressions traversing in the $tables's foreach.
Or refactor and move foreach into separate function and call twice: once - for this new function for tables, second - for exprssions.

↧

Allow data-dialog-options to be set as array.

March 13, 2018, 11:47 am
$
0
0

Problem/Motivation

Currently to pass jQuery dialog options onto drupal's dialogs you have to do something like:
'data-dialog-options' => Json::encode(['width' => 400]),
This is kinda of annoying

Proposed resolution

Automatically encode the options if they are an array.

Remaining tasks

Patch
Test

User interface changes

None

API changes

data-dialog-options could be set as a json encode string or an array.

Data model changes

None

↧

Drag-and-drop image uploading in Quick Edit doesn't work on Media fields, only File fields

March 12, 2018, 9:00 am
$
0
0

In Quick Edit module, we have this nice drag/drop file upload capability, but it currently only works for File fields. We need to expand it to also work with Media fields, particularly if we want to eventually push Media fields as the primary way of content authors getting images, etc. into Drupal.

Drag and drop file uploading

↧
Search

Add Crema Catalana to Umami

March 11, 2018, 12:58 pm
$
0
0

This patch adds a new recipe to the default content created on the Umami profile.

↧
↧

Increase the delta of the "weight" field for workflow transitions to support more than 20

March 13, 2018, 12:08 pm
$
0
0

I'm working on a site that has ~50 workflow state transitions defined. It's impossible for me to order them properly though, because the underlying "weight" field in the sort table only supports weights ranging from -10 to +10.

↧

Update classList.js to 1.2.2018012

March 10, 2018, 11:16 am
$
0
0

Problem/Motivation

Core using version released in 2014, there's newer stable release

Proposed resolution

update library, it has few bugfixes since 2014

Remaining tasks

review, do manual testing, commit

↧

CONCAT_WS is not compatible with all database drivers

May 31, 2013, 10:39 am
$
0
0

Problem/Motivation

Drupal core is using a MySQL specific function (CONCAT_WS) that does not exist in SQLite and MSSQL. The SQLite performance penalty is huge as CONCAT_WS is implemented as a userland PHP code override.

Drupal Core SHOULD not use any database specific behaviour and be ANSI compliant, and when it cannot, then use the database abstraction layer.

Proposed resolution

Switch from CONCAT_WS to CONCAT.

All the code was already in place to switch from CONCAT_WS to CONCAT as the whitespace separator was already being added to the field array.

Remaining tasks

RTBC

User interface changes

None.

API changes

None.

Data model changes

None.

Original report

SQLSTATE[42000]: [Microsoft][SQL Server Native Client 11.0][SQL Server]'CONCAT_WS' is not a recognized built-in function name.

Exception shown when using combined text filter in core views.

CONCAT_WS is not available in all databse engines, specifically, any SQL Server version under 2012 does not have this implementation.

It is extremely difficult (if possible) to implement a query alternative that 100% behaves like CONCAT_WS, so a patch is proposed that checks for database driver and if using SQLSRV changes the query for an alternative implementation that, although does not 100% match CONCAT_WS, gets very close to it.

↧

Support prefers-reduced-motion in off-canvas dialog

January 30, 2018, 8:22 am
↧
↧

Documentation for the format of #default_value of the date form field is incorrect

July 4, 2017, 5:41 am
$
0
0

The documentation for the date form element mentions that the default value should be passed as an array but this is not correct, it should instead be passed as a string in the format 'YYYY-MM-DD', which is ISO-8601 extended.

↧

Add titleNotEquals to WebAssert and a assertNoTitle to AssertLegacyTrait

September 5, 2016, 12:29 am
$
0
0

Problem/Motivation

For BC reasons we need a method assertNoTitle on AssertLegacyTrait
as well as a new method on \Drupal\Tests\WebAssert called titleNotEquals

Proposed resolution

Remaining tasks

Add a test for titleNotEquals to \Drupal\FunctionalTests\BrowserTestBaseTest

User interface changes

API changes

Data model changes

↧
Search

What could Drupal implement from other CMS or content editors to improve its Admin Interface?

February 14, 2018, 2:46 am
$
0
0

Problem/Motivation

Current Drupal's admin UI (the Seven theme) was a great improvement but hasn’t evolved much over the last years and it starts to feel outdated and needs a visual update. Some first steps were done at DrupalCon Vienna 2017 and conclusions can be seen here. The defined vision so far is:

Declutter and simplify the content authoring experience by driving user’s focus on the content itself, modernize the tools used for content authoring and move the meta/settings/workflow elements to a new “utility(ies)” section(s).

Although Experiments with JavaScript frameworks or modernization of the underlying theme architecture will help and we rely in the improvements it will bring, this is not the place to discuss them. We should design thinking on the user needs.

What do we need?

One of the next steps is to search what is going on outside Drupal’s island that we can implement. Have you seen something that you think Drupal should have? Help us collecting ideas, patterns and workflows to improve Drupal’s Usability and Interface and make it better.

Some competitors and products to look at would be:
- Wordpress
- Contentful
- Adobe Experience Manager
- Sitecore
- Squarespace
- Wix
- [More ideas?, please add others here]

How to collect ideas&patterns

To be able to process and analyze all the ideas later on it would be great to follow some patterns. We’ll need visual examples of what you are sharing because we might not have access to the product you are sharing and all we’ll have about it is what you share.

  1. Moodboard. We’ve prepared this easy-to-use so you can add GIFs/images just by Drag&Drop with no need to register: http://www.gomoodboard.com/boards/wjQ-cbbH/share
  2. Youtube. Have you recorded a long video? Share here the link so we can watch it.
  3. Issue queue. You can also add here what you found, but please add some screenshots to it.
↧

Add array type hinting to BlockPluginInterface parameters

March 13, 2018, 12:08 pm
$
0
0

I ran into an issue where phpcs is flagging the lack of type hinting in a subclass but I can't add it because the interface is in core and is missing the type hint. There is an issue to add them across all of core (#318016: Type hint array parameters) but it hasn't been touched in 5 years. The last comment suggests doing it in smaller patches so I will be adding a patch that covers BlockPluginInterface.php as well as classes that make use of the interface or further down the hierarchy.

↧
↧

[PP-2] Add workspace UI in top dialog

March 5, 2018, 2:40 am
$
0
0

Problem/Motivation

This is the implementation issue for #2732081: WI: Phase G2: Full-site preview with Workspace UI.

There are two dependencies:
#2784921: Add Workspaces experimental module
#2916781: Allow off-canvas dialog to be rendered elsewhere on the page

Should-have:
#2940677: Support prefers-reduced-motion in off-canvas dialog

Proposed resolution

Following the designs from https://marvelapp.com/2db8i71/screen/26360612, implement the Workspace list builder in a top dialog.

Remaining tasks

User interface changes

API changes

Data model changes

↧

Make Trait for field discovery in migrate entity derivers

March 9, 2018, 6:03 am
$
0
0

Problem/Motivation

In contrib (and even in core itself), there is a lot of boilerplate repeated when a migrate deriver wants to add fields to an source migrate deriver. Let's make the code for discovering and adding fields generic and make a re-usable trait.

Paragraphs and Commerce would use this. Node, user and taxonomy term in core could also.

Proposed resolution

Take a look at node source deriver, make a trait and then implement it for node, user and taxonomy.

Remaining tasks

  1. Code it
  2. Run existing tests
  3. Commit it

User interface changes

API changes

Data model changes

↧

Cannot manually set the sorting of content types on page /node/create

March 23, 2017, 5:19 am
$
0
0

I want to sort the content types on the page /node/add/. In Drupal 7, I went to the
Navigation menu and changed the order, then went to /node/add/ page and the new order is displayed. In D8 I go to Administration menu and changed the order and saved it. The order is saved but If I look at the /node/add/ page it still has the old order? This could be a Drupal 8 bug.

↧
Viewing all 298122 articles
Browse latest View live
Search