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

RuntimeException: Base route not available for route entity.field_config.image_slider_field_edit_form in Drupal\config_translation\ConfigNamesMapper->getOverviewRoute()

July 22, 2021, 1:25 pm
$
0
0

I get this message when trying to run Drush cr and/or clearing cache in drupal. Any help would be very much appreciated! I did not find anything on this issue I have already installed Path Auto Module and still getting the same error message.

The website encountered an unexpected error. Please try again later.

RuntimeException: Base route not available for route entity.field_config.image_slider_field_edit_form in Drupal\config_translation\ConfigNamesMapper->getOverviewRoute() (line 248 of core\modules\config_translation\src\ConfigNamesMapper.php).

↧
Search

Allow to configure translation per property on link fields (for translating only the title, not the url itself)

June 17, 2020, 9:16 am
$
0
0

Problem/Motivation

In images, we can configure that only title and alt texts are translated, and not the original file.
I think it will make sense in some cases to do the same for links, where you may want to allow to translate the title but not the url.

Proposed resolution

Add columns to modules/link/src/Plugin/Field/FieldType/LinkItem.php definition.

Add a UI mark depending on #3152587: Add a mark when editing a field property will affect all the translations as we do with fields themselves outcome.

Remaining tasks

  • Ensure this is an acceptable feature request.
  • Have a working patch
  • Add tests
  • Right now, the (*all translation) markers doesn't work for subfields, so it's not obvious that this will affect all translations (see #3152587: Add a mark when editing a field property will affect all the translations as we do with fields themselves). We need to figure out a way to do that before this lands, as the UI would remain the same but you won't know you are updating all the translations.
  • Decide on the defaults: should be translatable or not by default?
  • Add an upgrade path: for existing sites, the url should be always translatable on upgrade, for avoiding to change the expected behavior on sites upgrading.
  • Add upgrade path tests.

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD

↧
↧

Add ViewExecutable::getStylePlugin and ViewExecutable::getRowPlugin as public methods

May 4, 2016, 4:20 pm
$
0
0

Problem/Motivation

\Drupal\views\ViewExecutable::$style_plugin and \Drupal\views\ViewExecutable::$rowPlugin
should have corresponding methods, one could call.

Once we do that, we can also mark the public properties as deprecated

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

↧

Issue with doTrustedCallback() must be array

July 21, 2021, 9:14 am
$
0
0

Hello Everyone,

I installed drupal 8.9.16. Installation process is completed successfully but when i tried to login with admin details I got error "
TypeError: Argument 1 passed to Drupal\Core\Render\Renderer::doTrustedCallback() must be callable, array given, called in /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php on line 781 in Drupal\Core\Render\Renderer->doTrustedCallback() (line 51 of core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php)."

Please anyone can help to resolve this issue.

Thanks

↧

[meeting] Migrate Meeting 2021-07-08

July 5, 2021, 1:22 am
$
0
0

Hello all, it’s time for the weekly migration subsystem meeting. The meeting will take place in slack in various threads
This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every Thursday and alternates between 1400 and 2100 UTC.
➤ Is done on the #migration channel in Drupal Slack (see www.drupal.org/slack for information).
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to. See the parent issue for an idea of the typical agenda.
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

Core migration issues

Next video meeting

2021-07-15 - The hope is that most or all of the maintainers will attend. We will try to focus on longer-term goals than in the weekly meeting.

0️⃣ Who is here today? Introduce yourself in this thread. (edited) 

Arthur Deryckere (KenowaX)Yop ! :slightly_smiling_face:I'm Arthur Deryckere, I work at Webstanz, a Drupal Web Development company in Belgium.
damienmckennaDamien McKenna, work at Mediacurrent in the USA, that guy with the bunny ears :wink:
MatroskeenIvan, work at DevBranch in Ukraine. I don't have bunny ears, but I'm one of the "Rabbit Hole" module maintainers :rabbit: (edited)
stevenxSteven Schulz, work as senior Drupal developer in Hamburg Germany for Klambt Verlag on Drupal Thunder mostly
Jeya SundharamHi my name is sundhar, Drupal developer at ypungglobes.
marvil07Marco here, doing several things around drupal migrations.

1️⃣ What do we need to talk about? Post topic suggestions here, and we will create threads as needed

Arthur Deryckere (KenowaX)Quick question for any beginners out there :are there any tutorial pages/videos on how to customize migrate ?(Custom Source Plugin, Custom Process Plugin, Extending Migrate, etc.)
mikelutz (he/him)The api documentation is at https://www.drupal.org/docs/drupal-apis/migrate-api/migrate-api-overview
srjosh@dinarcon wrote a pretty good set of blog posts, but I don't remember where they are.  Mauricio?
dinarconhttps://understanddrupal.com/31-days-of-migrations
dinarconThat does not cover much in terms of development though. There is an example of a custom plugin at https://github.com/dinarcon/drupal-migrations-intermediate
damienmckennaI haven't worked on my upgrade projects in a while, I need to look at them again and e.g. see if the Commerce Migrate items have moved forward.
marvil07One small update about drush/migrate_tools: two more commands now ready: basically adopt drush implementation, remove migrate_tools equivalent, and add suggested changes to get missing thing on drush code base.Details at #3213947: Drush core migrate commands integration#mr4-note32148

2️⃣ Add extra orderBy to d7_file source plugin to avoid random results

mikelutz (he/him)#3220155: Add extra orderBy to d7_file source plugin to avoid random results
MatroskeenThanks for adding the thread. I actually wanted to ask a question, somehow related to this issue.I want to come up with a list of Novice tasks for the internal code sprint we're hosting in August (thanks to @benjifisher for the idea).I think that adding missing orderBys to the existing SQL-based source plugins can be a good chunk of work.I want to make sure that migrate maintainers approve this scope, as long as we add order by primary key and existing tests don't fail.If we don't have any objections, I'll create a META task and then bunch of sub-tasks for each plugin or set of plugins. (edited)

3️⃣ Map text_plain field formatter to basic_string for long text fields

mikelutz (he/him)#3088917: Map text_plain field formatter to basic_string for long text fields
mikelutz (he/him)Looks to need only a small documentation tweak
↧
↧

Map text_plain field formatter to basic_string for long text fields

October 18, 2019, 2:00 pm
$
0
0

When a D7 site has a long text field that uses the "text_plain" format, migration errors occur.

The "text_plain" plugin does not exist

The same problem was fixed for normal textfields in #3042223: Map text_plain field formatter to string.

Proposal: implement the same fix for long text fields.

↧

Refactor UrlTest tests to use a dataProvider

October 17, 2014, 6:23 am
$
0
0

During working on #2350507: \Drupal\Core\Url has no __toString() magic method we realized that the test methods of \Drupal\Tests\Core\UrlTest interfere with each other, which makes reliable tests impossible. Because the \Drupal\Tests\Core\UnroutedUrlTest uses a similar approach, I guess there will occure similar problems. So I took a deeper look into the \Drupal\Tests\Core\UrlTest test class and realized that there are some points that may be solved much better. Here is a list of what I found:

  1. Demo values are created in the setUp method and saved in a property ($this->map). This should be refactored to use the @dataProvider approach PHPUnit offers.
  2. The testUrlFromRequest() should use the @dataProvider approach as well to shorten its code and it should not be necessary for it to be a dependency for several other test methods only because it creates the URL objects (by using @dataProvider this is handled in another way)
  3. The testToArray() method says it covers the Url::toArray(), but does not use it in its test implementation

The \Drupal\Tests\Core\UnroutedUrlTest test class has similar issues like stated in 1. and 2. (here for method testFromUri), so this should also be reworked as best as possible.

↧

deprecate file_save_data, file_copy and file_move and replace with a service

July 12, 2021, 12:48 am
$
0
0

Problem/Motivation

Currently file_save_data depends on a number of services and calls logging and flash messages. We should deprecate it, and move it to a service so it can be better tested, throw exceptions and let calling code handle the logging and flash messages.

Steps to reproduce

Proposed resolution

Deprecate file_save_data and replace with a service.

Remaining tasks

User interface changes

API changes

file_save_data, file_move() and file_copy() are replaced with a service and deprecated.

Data model changes

Release notes snippet

↧
Search

UX issue with disabled blocks in block admin UI.

February 25, 2020, 1:12 pm
$
0
0

Problem/Motivation

In this issue: #2513534: Remove the 'disabled' region from Block UI, a new "disabled" block state was added. This issue also added CSS that makes disabled blocks in the Block admin UI semi-transparent.
However, this styling was not present in any core themes, as Stable provided an earlier version of the stylesheet. Once #3115223: Remove Stable as a base theme of core themes, core themes in Drupal 9 will see this new style.

There's a UX problem with this style: making this semi-transparent tells the user that the interactive elements are disabled, and they are not. The block is in a disabled state -- but the interactive elements for that block are still active (and should be). The block being disabled should be represented in another way (or not at all if it's deemed sufficient to have the dropbutton say "Enable"

The styling results in an additional problem in Bartik and Umami: it results in insufficient contrast. This may be less of a concern since those are not admin themes and it can be determined in this issue if that needs to be a concern.

Claro

Seven

Bartik

(Contrast is not accessible - 4.15:1)
Umami

Contrast is not accessible - 3.82:1

Proposed resolution

Determine a more UX friendly approach and implement.

Remaining tasks

Note that if work begins on this before #3115223: Remove Stable as a base theme of core themes lands, the styling this issue is addressing will not be visible unless Stable is configured to not override block.admin.css

User interface changes

API changes

Data model changes

Release notes snippet

↧
↧

Allow hiding configured blocks in layout builder

August 4, 2020, 2:20 am
$
0
0

Motivation

Similar to panel's "Disable this pane" feature it would be nice if layout builder would allow hiding a block without removing the block & its configuration. That way a site-builder could easily temporarily hide a bloc

Proposed resolution

Add a quickedit menu entry "Hide block / Show block" and some CSS highlighting the current state.

Data model changes

Related issues

#2916876: Add visibility control conditions to blocks within Layout Builder

↧

PHP 8 overrides sender email settings

July 22, 2021, 7:53 pm
$
0
0

Problem/Motivation

When using Drupal 9.2.2, PHP 8 and MySQL 8, any email sent using Drupal (sitewide contact form, system emails, Simplenews module, anything) overrides any Drupal-configured emails (such as default system email address) with the actual server's default email address.

This issue disappears when the server is switched to PHP 7.4.

Steps to reproduce

Install Drupal 9.2.x in a server using PHP 8.0
Get Drupal to send an email
Check the email account that Drupal sent an email to
The "From" field will be your server's default email and NOT what Drupal is configured to

Proposed resolution

This only happens in PHP 8. No issues with PHP 7. So it has something to do with PHP 8.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

↧

deprecate system_retrieve_file() and replace with a service

July 12, 2021, 12:34 am
$
0
0

Problem/Motivation

Follow up to #3223016: Deprecate file_build_uri()

system_retrieve_file() largely depends on the file system and should probably be moved from the system module to a core service so we can inject dependencies and allow it to more easily tested.

We can clean up the API issues such as #2177545: Change system_retrieve_file function to return error instead of generating Drupal messages at the same time.

Steps to reproduce

Proposed resolution

Move it to a core file system service and deprecate.

Remaining tasks

User interface changes

API changes

system_retrieve_file() is deprecated.

Data model changes

Release notes snippet

↧

All serialized values are strings, including integers/booleans

July 22, 2021, 10:17 pm
$
0
0

Problem/Motivation

When I create a REST EXPORT in Views, all the fields in the result JSON are Strings, including integers and booleans. I was expecting them to be ints, bools etc whenever appropriate. I've read that this is an old issue that has long been fixed ( https://www.drupal.org/node/2837696 ) prior to Drupal 9, and Drupal 9 should by default show them as strings, ints, booleans etc

I'm on Drupal 9.2.2 and hadn't worked with the Rest API in previous version (Drupal 8). I migrated from 7 to 8 and directly to 9 (in case it has anything to do with the situation).

Drupal 8 had a setting (serialization.settings.yml) where you could opt in and out of serialising them as strings or not, but I don't think Drupal 9 has any way option to force the fields into showing as strings, ints, booleans?

I migrated from 7 to 8, and then 9 (I'm not sure if this has anything to do with it. I'm assuming if I tested a clean install of Drupal 9 this, I'm sure this).

Steps to reproduce

Create a Rest Export in View, add some Int fields like Content ID or User ID. The fields in that JSON result are all Strings.

↧
↧

Allow text fields and textareas to use the other's widgets.

April 28, 2015, 7:39 pm
$
0
0

It's super frustrating when you want to have a text field (255chars) but the only way to see the entire 255 chars in that field is a really really reeeeally long textfield. Text areas are a thing. We should be able to use them (and not just for longtext text fields).

in Drupal 7, to use a textarea you need to create a whole new field and migrate all your data into it, but the underlying data structure is exactly the same!! This should not be necessary. Let's add the textarea widget as an option for text fields (but leave the existing widget as default)

↧

Allow deprecating theme suggestions

July 14, 2020, 5:18 am
↧
Search

Tables can create horizontal scrolling at narrow viewports in Olivero

January 29, 2021, 7:26 am
$
0
0

Problem/Motivation

Tables can create horizontal scrollbars as seen in the attached video screencast based off of the Style Guide module.

Steps to reproduce

  1. Download/enable Style Guide module
  2. Go to /admin/appearance/styleguide/olivero and navigate to the "Filter Tips, Long" and "Tables" sections
  3. Change your viewport width to a 320px
  4. Verify that the table content causes horizontal scrollbars by using the left/right arrow keys (keyboard-only users), using the browser's scrollbars, or using your mouse to drag the page left and right

Proposed resolution

Before we work on this issue I think it's important to have discussion with the team on the best approach. The big question: Are we wanting tables to be stacked or stay in a tabular format in mobile view?

Remaining tasks

TBD

User interface changes

TBD

↧

[ignore] Patch Testing Only

June 30, 2021, 4:08 am
↧
↧

Local tasks should honor selected admin interface language (if set)

May 14, 2019, 8:06 am
$
0
0

Problem/Motivation

Local task labels are always displayed using the content language, ignoring that users can set their admin language preference (if the site has an admin language preference option set in negotiation). Local task label should honor this config and use the admin interface language. Even if they are in a non-admin pages, they are part of the admin interface.

This is very similar to what is being done in #2313309: Admin toolbar should always be rendered in the admin language (if set), but for local tasks. It's worth to note that in that issue current patches seems to translate Contextual Links as well (if not, probably a new issue should be created).

Proposed resolution

Render local task labels using the admin language config from language negotiation.

Remaining tasks

Implement it.

User interface changes

Local task labels will be in an admin-appropriate language. Optionally, a checkbox can be added to make this behavior optional.

API changes

Likely none.

↧

Enable Content Moderation integration for taxonomy terms

April 10, 2019, 3:29 am
↧

How do we add page title to Layout Builder.

August 3, 2020, 9:15 am
↧
Viewing all 292545 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>