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

No title sort for Entity Reference fields

$
0
0

I created a field referencing content (formerly called Entity Reference). In the "sort by" selection box, neither "Title" nor the name I had used as override for "Title" (which was "City") appeared in the list.

Strangely enough, I saw the names of overridden title fields for other content types, just not for the content type I was referencing in that case.

Summary Update:
Steps to reproduce:

  • Create some content types
  • Update the title field label from 'Title' to something else (in all content types including Article and Page).
  • Add an entity reference field to any content type, the sort by select list won't have the 'Title' option.

The title field is being shared between content types, at least in the entity reference Sort By select list.
So if the title field label is updated in one or more content types, then chances are that the Sort By select list displays one of the updated labels instead of 'Title'.

So imagine the next scenario w/only two content types:

  • Content type one set its title field label to 'title one'
  • Content type two set its title field label to 'title two'
  • Add an entity reference field to content type one pointing to content type two, and try to sort by title.

The sort by title select list won't display the 'Title' option, instead it would display 'title one' or 'title two' (but only one of those). So if you want to sort the entity reference field pointing to content type two by title, and neither 'Title' or 'title two' are on the Sort By select list it can be confusing.
How are you going to know that the option to select is 'title one' because that corresponds to the title field? In this scenario w/two content types is easy to figure out, but imagine multiple content types and even worst more than one person working in the same project.

Solution Suggested:
For consistency always display 'Title' as an option in the Sort By reference select list instead of any custom title field label.


Clean up the "print.css" code in Bartik

$
0
0

Follow-up to #1342054: [META] Overhaul Bartik's code.

Problem/Motivation

  1. Bartik's template files need to be assessed and cleaned up of redundant markup, bad formatting and ID's.
  2. Bartik's CSS files need to follow Drupal's CSS Coding Standards.

Proposed resolution

For this issue we take "print.css" within Bartik in css/print.css plus any template file associated with the CSS and clean them up.

CSS formatting tasks to do

  1. The CSS file needs to use the correct Comment formats - see guidelines here and also reference other fixed Bartik CSS files for wording guidelines.

CSS architecture tasks to do

  1. Replace any ID's with classes within the CSS files and Twig files associated with it - see guidelines here.

CSS cleanup tasks to do

  1. Check all of the selector rules are correct and are currently in use. Fix any broken ones found.

Remaining tasks

  • (Done) Write a patch containing as much of the above as possible.
  • (Done) Post a patch with screenshots.
  • Visual review of a patch - check the print view of Bartik visually with and without patch applied. Take screenshots.
  • Code review of a patch - check the code follows coding standards, suggest improvements if needed in a comment.
  • Produce a new patch with improvements if needed.

User interface changes

Screen layout for reference: screen.png

Print layout A4 paper: Before / After

Print layout A3 paper: Before / After

API changes

None

Data model changes

None

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue categoryTask because it is refactoring CSS and templates in Bartik
Issue priorityNot critical because Bartik functions fine we are just doing cleanup tasks
Unfrozen changesUnfrozen because it only changes CSS and markup
Prioritized changesThe main goal of this issue is usability of the Bartik's codebase
Disruptionnon-Disruptive as it is just changing markup and CSS

Wrong response for non-integer id for node and user

When installing a site in a language besides English, the site name is not saved and reverts to "Drupal"

$
0
0

When installing a fresh version of Drupal 8.2.0-beta2 (and beta3) the given site name is not showing. Instead it just says "Drupal" on the newly homepage.
MacOS Sierra, Apache 2.4.23, PHP 7.0.8. Safari 10.0 (build 12602). See attachment phpinfo. Site installation with language dutch (Nederlands).

Steps to reproduce it:

- Choose "Español" as site language.
- In the "Configure site" section, set the site name, mail, user and password as usual and in the regional options set "España" and "Europe/Madrid" and click in Save and Continue.
- When the install process finish the site name is "Drupal" and not the site name that you set during the install process.

I recorded a gif (drupal_site_name_issue.gif) with the process and the steps to reproduce it.

The system is a MacOS Sierra with php 7.0.12, sqlite, php built-in webserver and Drupal 8.2.1. I also tested with apache 2.4.18, mysql and OSX El Capitan and Ubuntu 16.04 as os with the same results.

PathValidator can get NotAcceptableHttpException

$
0
0

PathValidator class can get NotAcceptableHttpException exception from getPathAttributes method.
For example in my case system throws this exception from \core\lib\Drupal\Core\Routing\RequestFormatRouteFilter.php:48.

As I suppose PathValidator should catch this Exception.

Remove whitespace modifiers from links.html.twig

$
0
0

The template file links.html.twig has a lot of whitespace modifiers. These dashes here, {%- if heading -%}

They were originally added when the template was converted, but don't seem to serve a purpose and can be removed. They might have been there originally for tests but joelpittet confirmed they aren't needed for that now. See the patch here, https://www.drupal.org/node/2465399#comment-9829099

If they can be removed, remove them from the template in the System module, and the template in Classy. To determine if they can be removed we need to look for any instances where links might be rendered inline. That is a place where whitespace could be an issue.

Also, this template has a wrapping if statement:

{% if links -%}
...
{%- endif %}

The if was a direct copy of functionality from when this was a theme function. We cannot verify why it is still needed. Investigate whether it can be removed, and, if so, remove it.

If this issue is worked on after #2455211: Comment field displayed last regardless of assigned weight gets committed, investigate removing the if from the links template in Bartik, as well.

Update : Made the changes in the core links.html.twig template to fix the white-spaces issue as mentioned by Cottser
https://www.drupal.org/node/2472591#comment-10878510

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue categoryTask because it's not broken, just minor cleanup to the template
Issue priorityNormal, this only changes the appearance of the template code and whitespace in markup.
Unfrozen changesUnfrozen because it only changes templates.
DisruptionNot disruptive at all.

Store revision id in originalRevisionId property to use after revision id is updated

$
0
0

Problem/Motivation

After calling $entity->setNewRevision(TRUE) we have no way of knowing what revision id the entity used to be.

Considered a blocker for #2640496: Revision ID in {node} and {node_revision} can get out of sync which is critical.

Proposed resolution

Set the revision id to an originalRevisionId property in __construct
Update the originalRevisionId on post save
Return the property with getOriginalRevisionId() method

Remaining tasks

Review

User interface changes

none

API changes

Two methods added to ContentEntityBase and ContentEntityInterface

Data model changes

None

(Blocking #2809123: Reverting a revision doesn't keep moderation state)

Implement language aware tokens for one time login link and cancel link


RequestFormatRouteFilter throws NotAcceptableHttpException for html format

$
0
0

Drupal\Core\Routing\RequestFormatRouteFilter can throw Symfony\Component\HttpKernel\Exception\NotAcceptableHttpException, and it does it for html format also, but it shouldn't. So we should add check for format and throw 406 for non html formats only.

Make the 'Add content' link in the 'Tools' block finger friendly

$
0
0

Problem/Motivation

On mobile/touch devices, some participants of the usability study found the 'add content' link in the sidebar hard to press.

Proposed resolution

Make it bigger, the recommendation is 44px x 44px
Consider a rule that makes non-content links bigger?

Remaining tasks

None.

User interface changes

Bigger touch targets on mobile

API changes

None.

Data model changes

None.

Only local images are allowed.

Only local images are allowed.

Date FAPI element type do not allow AJAX via #ajax API

$
0
0

Problem/Motivation

When creating a form via form API, ajax API can be used to upate partial form parts using #ajax command. Date element #type does not support that.

Ex.:

$form['date'] = ['#type' => 'date','#default_value' => date('Y-m-d'),'#ajax' => ['callback' => '::dateCallback','wrapper' => 'table-wrapper',
  ],
];

Reproduction scenario

In order to easily test (as a human) that the patch work. Here is a testing module.
Steps:

  1. Install given module
  2. Move to move to /ajax_date page : when you change the date (via keyboard, or via picker), nothing special happens. (useless to submit the form, I did not implement submit method
  3. Apply the given patch
  4. Clean cache and make sure the /ajax_date page is not served from cache.
  5. Now change the date : ajax throbber appears and a line is added beneath the date field: 'Selected date: xx'

Proposed resolution

Allow support of #ajax for Date render element.

API changes

Date FAPI element will now support #ajax.
No break is forcasted for other elements, such as date without #ajax.

Looks like LazyRouteFilter doesn't handle priority

$
0
0

Looks like LazyRouteFilter doesn't handle priority

Destination URL breaks preview

$
0
0

From #1510544: Allow to preview content in an actual live environment

I did accidentally find one other bug in testing: if you're at admin/content, and select "Edit" next to a node in the list, then click "Preview," instead of being shown the preview, you will be taken back to admin/content and your changes lost. I suspect that's because the URL you end up on is http://8.x.local/node/1/edit?destination=admin/content and this somehow screws with the preview system's use of URLs? Hm.

Oh yes, the destination parameter, we somehow lost that in the patch somewhere, I remember we used to store that property as well.
It's not /that/ hard to implement, but I'm AFK until monday. If we can wait that's fine, unless someone else takes that up. Also more than happy to fix that in a follow up. You can even assign it on me immediately :)

This has this bewildering effect:

  • On admin/content, edit a node.
  • Change stuff, click Preview.
  • You are returned to admin/content. Edit the node again.
  • The changes appear to have been saved by preview, but totally were not.

Redesign the menu link add form to be less overwhelming

$
0
0

Problem/Motivation

During the usability sessions, some participants struggled with fill out the menu link add page. It has an overwhelming number of options, some are really important, some aren't important or commonly used.

Proposed resolution

We can reuse some of the design conventions introduced in #1510532: [META] Implement the new create content page design. Placing the important fields in the main column and the less important fields in the secondary column.

On the content creation page they are divided into collapsible fieldsets. I couldn't figure out any nice groupings for any of fields. Suggestions are welcome!
This is just a mockup so it doesn't look very good, this will need some visual tweaks.

Remaining tasks

Implement the suggestions
Design review
Test

User interface changes

A less overwhelming add menu link form

API changes

None

Data model changes

None

Mention relevant CR in an improved trigger_error() message in FormattableMarkup::placeholderFormat()


PostgreSQL: Support JSON and JSONB data types

$
0
0

I am trying to create a field type that leverages the JSON and JSONB data types in Postgres. My goal is to have a field that can store JSON objects who's properties can be indexed. This is a Postgres specific feature.

Basically I want to be able to paste JSON or parse a CSV with another custom module and store the object in this field with the intent of being able to query this data, treating it like a NoSQL store. Since Mongo isn't fully implemented, and would require two databases running instead of one, Postgres seems like a natural fit.

I believe I created the field type plugin as I should, but there is an issue in the Schema.php for the PGSQL where it does not account for either type. Patching in these two lines got me past the initial errors of undefined index in getFieldTypeMap(), allowing me to create a JSONB field type. It appears to have been created in the database correctly at this point.

/**
   * This maps a generic data type in combination with its data size
   * to the engine-specific data type.
   */
  function getFieldTypeMap() {
    // Put :normal last so it gets preserved by array_flip. This makes
    // it much easier for modules (such as schema.module) to map
    // database types back into schema types.
    // $map does not use drupal_static as its value never changes.
    static $map = array('varchar:normal' => 'varchar','char:normal' => 'character','text:tiny' => 'text','text:small' => 'text','text:medium' => 'text','text:big' => 'text','text:normal' => 'text','int:tiny' => 'smallint','int:small' => 'smallint','int:medium' => 'int','int:big' => 'bigint','int:normal' => 'int','float:tiny' => 'real','float:small' => 'real','float:medium' => 'real','float:big' => 'double precision','float:normal' => 'real','numeric:normal' => 'numeric','blob:big' => 'bytea','blob:normal' => 'bytea','serial:tiny' => 'serial','serial:small' => 'serial','serial:medium' => 'serial','serial:big' => 'bigserial','serial:normal' => 'serial','json:normal' => 'json','jsonb:normal' => 'jsonb',
      );
    return $map;
  }

Horizontal orientation of the admin should have sub options just like the vertical admin menu

$
0
0

The title says it all. I think integrating this feature in the horizontal menu would help!

Add support distinct on construction

Add a base class for entity reference selection handlers

$
0
0

Problem/Motivation

This is a prerequisite for #2786841: Entity reference fields should add selection handler config dependencies and probably for #2776571: EntityAutocomplete should pass the original URI to the selection handler.

  • DefaultSelection and ViewsSelection are duplicating a lot of code: protected properties, constructor, create() method.
  • Selection handlers should have setters and getters for their configuration.
  • Selection handlers should declare their handler default settings in a consistent way in order to get sane defaults. Right now DefaultSelection hardcodes this, see ::buildConfigurationForm(). Default configurations should be sane automatically.
  • Anticipating #2786841: Entity reference fields should add selection handler config dependencies, selection handlers should implement calculateDependencies() even with no effect right now.

Proposed resolution

  1. Introduce a new base class for selection handlers - SelectionPluginBase:
    abstract class SelectionPluginBase extends PluginBase implements SelectionInterface, ConfigurablePluginInterface {
      ...
    }
  2. Introduce a trait SelectionTrait to provide shared code between DefaultSelection and ViewsSelection:
    trait SelectionTrait {
      ...
    }
  3. Make DefaultSelection and ViewsSelection extend the new SelectionPluginBase class and use SelectionTrait.
  4. Make Broken selection handler extend SelectionPluginBase .
  5. Move the common code from DefaultSelection and ViewsSelection into SelectionTrait.
  6. In SelectionPluginBase provide base implementations for: defaultConfiguration(), setConfiguration(), getConfiguration(), calculateDependencies(), buildConfigurationForm(), validateConfigurationForm(), submitConfigurationForm() and entityQueryAlter().
  7. SelectionPluginBase::setConfiguration() will take care to assure BC by creating a handler_settings level, same as the field config has. Basically all handler settings will live in the root level but will be synced also under handler_settings. Add a @todo to remove the BC handler_settings key in Drupal 9.0.x.
  8. Implement ::defaultConfiguration() in all core selection handlers that need it.
  9. Cleanup code from DefaultSelection, UserSelection and ViewsSelection that assures sane-defaults because now the configuration is already sane.
  10. Remove empty instances of buildConfigurationForm(), validateConfigurationForm(), submitConfigurationForm() and entityQueryAlter() from implementations because we already provide them now in the base class.

Remaining tasks

Continue with #2786841: Entity reference fields should add selection handler config dependencies.

User interface changes

None.

API changes

This change will not introduce any BC break. All custom selectors based on DefaultSelection or ViewsSelection will continue to works as we provide base implementations for all new methods. Custom selections not extending DefaultSelection or ViewsSelection but implementing directly SelectionInterface will not be affected at all.

API changes:

  • New base class for selection handlers SelectionPluginBase:
    abstract class SelectionPluginBase extends PluginBase implements SelectionInterface, ConfigurablePluginInterface {
      ...
    }
  • New trait SelectionTrait:
    trait SelectionTrait {
      ...
    }

Data model changes

None.

There should be a reset block layout to default in core themes

$
0
0

The title says it all. I think integrating this feature would be useful for users.

Viewing all 294937 articles
Browse latest View live


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