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

"Notice: Undefined index: defaults" when visiting default media_library view

June 8, 2021, 8:59 am
$
0
0

Problem/Motivation

Visiting the default (formerly master) display for the media_library view's configuration page results in a dblog/watchdog php notice. Well, two actually:

Notice: Undefined index: defaults in seven_views_pre_render() (line 351 of /var/lib/tugboat/stm/web/core/themes/seven/seven.theme)
and
Notice: Undefined index: defaults in media_library_views_pre_render() (line 181 of /var/lib/tugboat/stm/web/core/modules/media_library/media_library.module)

I imagine this is unlikely to be seen by most since it requires having the "Always show the master (default) display" checkbox checked (or set in settings.local.php or whatever), and I honestly don't know even know if it's really a problem that could cause any real-world issues, but since my team's development workflow includes checking the dblog for potential issues in every PR, I wasted some time thinking my edit to that view caused a bug/regression.

Steps to reproduce

  1. Enable (or have enabled) media and media_library.
  2. Go to /admin/structure/views/settings and check the "Always show the default display" checkbox. Save the page.
  3. Visit /admin/structure/views/view/media_library (and/or maybe just go directly to /admin/structure/views/view/media_library/edit/default without having to do the previous step?)
  4. Visit /admin/reports/dblog and see the two new notices.

Proposed resolution

Of course an isset() or array_key_exists() or whatever could be added to those lines in the .module and .theme files, though I don't know if maybe the default display ought to be getting that ['defaults'] key also fed to it instead? (Or maybe those classes should be added regardless of whether ['defaults'] exists or whatever? I don't quite know what all the two hook_views_pre_render()s are doing in the first place.)

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

↧
Search

9.2.0 update breaks dynamic select queries

June 19, 2021, 10:26 pm
$
0
0

OS: CentOS
PHP: 7.3, 7.4, 8.0
Drupal 9.2.0

Following the directions given at https://www.drupal.org/docs/8/api/database-api/dynamic-queries/introduct... I get the following error:

Error: Object of class Drupal\Core\Database\StatementWrapper could not be converted to string in Drupal\Core\Entity\EntityStorageBase->buildCacheId() (line 126 of /home/user/public_html/core/lib/Drupal/Core/Entity/EntityStorageBase.php).

For example running this code produces the error:

$database = \Drupal::database();

$query = $database->select('users', 'u')
->condition('u.uid', 0, '<>')
->fields('u', ['uid'])
->range(0, 50);

$result = $query->execute();

↧
↧

Update module can get 'stuck' with 'no releases available'

November 1, 2017, 9:00 am
$
0
0

Problem/Motivation

I don't have great steps to reproduce this yet, but it's something like the following:

- update module can end up with items in the fetchTasks key/value store without equivalent queue items
- because there are items in fetchTasks, no new queue items get created for them, even when manually checking for updates.
- because no queue items are created or processed, the stale fetchqueue items never get cleared out

Therefore projects can get stuck with the 'no releases available' error and there's no way to reset things except to clear the k/v out manually.

In my case, the fetchtasks items were old enough that they were also different project versions (found this when updating to 8.4.0), so comparing the stored and current $project data and updating an item anyway if they didn't match broke the loop. This doesn't really feel like the right fix though but I'm uploading the patch for reference. However ensuring we always use the latest project info data seems like a small improvement too.

More appropriate might be to switch from key/value to keyvalueexpire, so that fetch tasks get discarded after an hour or day, which would be plenty of time for the queue to have finished processing.

Marking this major because though I wasn't able to find any other reports, it can mean update status not reporting updates at all.

Proposed resolution

Use temp key/value store, or fix #1548286: API for handling unique queue items properly and use that resultant API.

Remaining tasks

User interface changes

API changes

Data model changes

↧

Drupal.ajax does not guarantee that "add new JS file to page" commands have finished before calling said JS

May 7, 2013, 5:05 am
$
0
0

Problem/Motivation

It is impossible to load additional JS libraries in an Ajax response and then call that code through Ajax commands, because Drupal.ajax does not guarantee that the JS library will already have loaded.

See #23 and #31 for details.

Proposed resolution

TBD.

Remaining tasks

TBD.

User interface changes

None.

API changes

TBD

TBD

Original report by [username]

Hi,

Thanks for your module, it works perfect for me.

But I found there one small bug there: if all my .js files are mapped to the external CDN, ajax redirects doesn't execute. After some tests I found that CDN rewrites all js urls, even for ajax. So I attached a small patch that solved this problem for me.

Best regards,
Spleshka.

↧

How to fix "non-existent config entity name returned by FieldStorageConfigInterface::getBundles()"

October 14, 2017, 11:01 am
$
0
0

I have two recurring errors in my log as follows. Please could someone advise on a php code snippet to remove these errors? Both are reported as a 'views' error type and occur when clearing all caches.

A non-existent config entity name returned by FieldStorageConfigInterface::getBundles(): field name: field_mpn, bundle: cpl_microwave_heat_packs_other

A non-existent config entity name returned by FieldStorageConfigInterface::getBundles(): field name: field_product_packed_volumetric_, bundle: default

↧
↧

WebP integration with Breakpoint and Responsive Images module is unusable

May 11, 2021, 1:12 pm
$
0
0

Drupal 9.2 supports the webP image format (see change record: https://www.drupal.org/node/3171135).

In order for browsers that do not support WebP (earlier versions of Safari & IE), the image needs to be wrapped in a <picture> tag like so:

<picture>
  <source srcset="my-awesome-picture.webp" type="image/webp">
  <img src="my-awesome-picture.jpg" alt="Awesome">
</picture>

Older browsers will look at the type attribute on the <source> element, and fallback to the <img> element.

This is next to impossible to do with Drupal core (although you can get it working in an extremely hacky way!)

The breakpoint module gives you the option to select media queries and multipliers, but does not give you an option to select the type.

I do not have an option to create multiple image styles on a single media query. I can hack this by creating multiple media queries such as 'all and (min-width: 1x)' and 'all and (min-width: 2x)'. But this is just plain ol' wrong.

Note this is solved in contrib through the https://www.drupal.org/project/webp or https://www.drupal.org/project/imageapi_optimize_webp modules.

↧

Unsupported operand types in LinkFormatter->buildUrl()

October 1, 2020, 6:06 am
$
0
0

Problem/Motivation

When populating a link field programmatically, if there is no options array entered, the following error happens:

Unsupported operand types in Drupal\link\Plugin\Field\FieldFormatter\LinkFormatter->buildUrl()

This happens with PHP version 7.4.10.

Steps to reproduce

  $node->set('field_link', [
    'uri' => 'https://google.com',
    'title' => 'Google',
  ]);
  $node->save();

then view that node and an error is thrown. A work around for this is to enter an empty array for options:

  $node->set('field_link', [
    'uri' => 'https://google.com',
    'title' => 'Google',
    'options' => [],
  ]);
  $node->save();

Proposed resolution

The offending code is located on line 245 of /core/modules/link/src/Plugin/Field/FieldFormatter/LinkFormatter.php.

    $options += $url->getOptions();

If options isn't set as an array on saving the field, in PHP 7.4 we cannot do the += operation. I can see two possible resolutions, one being on line 244:

    $options = $item->options ?: [];

The other option is change line 245 to:

    $options = array_merge($options,$url->getOptions());

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

↧

Fields with Broken handler should not be shown in views

June 17, 2021, 7:31 am
$
0
0

Problem/Motivation

When there is a field in a view with Broken handler then such field is still being displayed in a view.
For example when you use table as a style plugin for your view then you'll end up with an empty column having a label of that field in table header but having no values in table rows. Such a field should not be really shown in a view.

Steps to reproduce

Create a view with table style plugin with a field with Broken handler.
Look at the view.

Proposed resolution

Field with Broken handler should not be presented in a view at all.
Broken field handler class should deny access to such field.

↧
Search

[Meta] Bug Smash Initiative triage fortnight commencing 2021-06-08

June 9, 2021, 5:20 am
$
0
0

Meta for triage credit, please comment and link to issues you triaged and closed.

↧
↧

Avoid error when $options is NULL in buildUrl()

April 19, 2017, 12:31 pm
$
0
0

We've run into an issue where we are getting an error on a link field:

Error: Unsupported operand types in /core/modules/link/src/Plugin/Field/FieldFormatter/LinkFormatter.php on line 245

I don't know if it's possible to reproduce this error with just core. The error seems to be coming from a translation issue in Paragraphs where the "options" property isn't getting set right. This patch is a work-around to that but it's just checking that $options is an array and making it one if it's not so it won't hurt anything to have it in there as a failsafe.

↧

Deprecate both Aggregator and our dependency on Laminas Feed for removal in Drupal 10

December 15, 2020, 11:05 am
$
0
0

Problem/Motivation

This issue is postponed on #3135100: [policy and meta] Provide a proper mechanism for deprecating modules.

In #1136482: [policy] Deprecate aggregator.module in D9 core and remove it in D10 we've agreed to deprecate the Aggregator module for removal in Drupal 10, along with Laminas Feed (which only Aggregator depends on).

Proposed resolution

  • Begin deprecating the module and dependency once we've addressed the issue of providing a better mechanism and process for deprecating modules.
  • Create an Aggregator contrib project (also only once the process issue is resolved). @larowlan and @andypost have offered to maintain the contributed module.
  • Provide and document the upgrade path from the core module to the contributed version.

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD

↧

Fix up topics to use new help_topic_link function

January 13, 2021, 8:10 am
$
0
0

Problem/Motivation

On #3090659: Make a way for help topics to generate links only if they work and are accessible, we are adding two new functions for making links in help topics.
Related change record is https://www.drupal.org/node/3192582

Once that is committed (this issue is postponed until then), we need to fix up all of the existing help topics to use the new functions.

As an example, this is how the block.place.html.twig file was updated in the patch on that issue (that was the only production topic that was updated):

-{% set configure = render_var(url('help.help_topic', {'id': 'block.configure'})) %}
+{% set configure_topic = render_var(help_topic_link('block.configure')) %}
 
...

-  <li>{% trans %}In the <em>Manage</em> administrative menu, navigate to <em>Structure</em> &gt; <a href="{{ layout_url }}"><em>Block layout</em></a>.{% endtrans %}</li>
+  <li>{% trans %}In the <em>Manage</em> administrative menu, navigate to <em>Structure</em> &gt; {{ layout_link }}.{% endtrans %}</li>

...

-  <li>{% trans %}Configure the block and click <em>Save block</em>; see <a href="{{ configure }}">Configuring a previously-placed block</a> for configuration details.{% endtrans %}</li>
+  <li>{% trans %}Configure the block and click <em>Save block</em>; see {{ configure_topic }} for configuration details.{% endtrans %}</li>

Steps to reproduce

N/A

Proposed resolution

  1. [done] Make sure that the help topics standards on https://www.drupal.org/docs/develop/documenting-your-project/help-topic-... are updated to use the new functions.
  2. Fix up the rest of the topics in core/modules/help_topics/help_topics to use the new help functions.
  3. Add code to core/modules/help_topics/tests/src/Functional/HelpTopicsSyntaxTest to make sure that:
    • Those functions are being used for links and not the base Twig url() function.
    • If help_route_link is used, the text is translated.
    • The syntax test includes "bad" examples to verify the tests are working, so there should also be "bad" examples added that violate those two test cases, to make sure the test is working properly.

Remaining tasks

Make a patch, review, and commit.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Not necessary. This is an Experimental module.

↧

Unable to Upload an image using API

June 18, 2021, 4:16 am
$
0
0

Hello,
I am trying to add/upload images with products using API. For that, I guess we need to provide the id of the uploaded image in the API body of the product.

So, I installed module file entity(https://www.drupal.org/project/file_entity). I checked this issue for my solution: https://www.drupal.org/project/drupal/issues/2682341

I am using POSTMAN to run this API.

I am using Drupal 9.2.0

The API I am using to upload image:

URL:
{{Domain}}/entity/file?_format=hal_json

Method: POST

Body:

{
	"_links": {
		"type": {
			"href": "{{Domain}}/rest/type/file/image"
		}
	},
	"filename": [
		{
			"value": "imagename.jpg"
		}
	],
       "filemime": [
		{
		        "value": "image/jpg"
		}
	],
	"data": [
		{
			"value": "base64encoded image string"
		}
	]
}

Response: 

{
    "message": "Could not determine entity type bundle: \"type\" field is missing."
}

Any suggestions?

↧
↧

Improve Email field validation error message to improve accessibility

February 17, 2020, 12:27 am
$
0
0

Hi,

We had an accessibility audit and one of the issues was that the error message for email fields was not helpful enough and should contain something about the format it expects. Personally I disagree and think the message is good enough, but perhaps it is worth to look into.

I decided to create a patch instead of overriding the email class because the latter would not keep track of any possible future changes to the Email field.

Sincerely,

Dagomar

↧

Change available updates link to point to action page

June 23, 2017, 12:55 pm
$
0
0

/admin/modules contains the instruction:

Regularly review and install available updates to maintain a secure and current site.

This currently links to Available updates /admin/reports/updates, which provides a report but doesn't enable any action. Further, it reports on all modules, not just those requiring updates.

It might be better to instead link to /admin/modules/update, which not only specifically lists just those modules needing to be updated but also enables the action to do so.

↧
Search

User login page broken when there are more than 5 failed login attempts for an account

February 11, 2021, 10:13 am
$
0
0

Hello,

The User login page broken when there are more than 5 failed login attempts for an account. Error message should be displayed on the same user login page but the error message displayed on the blank screen. Kindly find the screenshot attached.

Thanks

↧

ExtensionList Fatal error after update to D9.1.10

June 16, 2021, 8:10 am
$
0
0

Problem/Motivation

After updating to 9.1.10 from 8.9.16 I got the following error:
Drupal\Core\Extension\Exception\UnknownExtensionException: The module does not exist or is not installed. in Drupal\Core\Extension\ExtensionList->getExtensionInfo() (line 346 of /app/web/core/lib/Drupal/Core/Extension/ExtensionList.php).

Steps to reproduce

Proposed resolution

I created the patch based on https://www.drupal.org/project/drupal/issues/3000677

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

↧
↧

Remove Firefox workaround for details focus effect

October 4, 2019, 3:54 am
$
0
0

Problem/Motivation

We have a workaround for the details focus effect to make it more consistent with Chrome. However, this makes the details element focus inconsistent with some other elements on the same browser. Since this is presumably expected behavior in Firefox (on OS X) and not a bug, we should consider whether we want to have this workaround or not.

The motivation is to make the focus effect behavior consistent across websites visited with the same browsers .

There aren't any macOS system settings that make a difference.

Steps to reproduce

  1. Install Drupal, log in with an admin user and visit /admin/config/system/site-information'.
  2. Click on the Site details summary, collapse and expand it. Using 'Stable' or 'Stark' themes, you will see the (browser-default) focus effect of the <summary> element in browsers, but not in Firefox on OS X operating system. With Claro theme, you will see the focus effect.
  3. Now focus the Site details summary with keyboard. You will see the focus effect of the <summary> element with every browser.

Proposed resolution

Remove Claro's details summary workaround and rely on Firefox's default behavior when it comes to details focus effects.

Remaining tasks

  • patch
  • review
  • commit

User interface changes

Users using Firefox on OS X operating system won't see the focus effect of details summary if they are using their pointer device for collapsing or expanding the <details> element.

API changes

Nothing.

Data model changes

Nothing.

↧

When you remove the "Breadcrumb" block in Seven, there's no top padding for the main content

June 16, 2017, 8:56 am
$
0
0

Problem/Motivation

With

Without

Proposed resolution

Fix CSS.

Remaining tasks

Browser tests

User interface changes

minimal, better spacing when breadcrumb block is disabled on admin pages

API changes

none

Data model changes

none

↧

Claro + layout builder messages display additional icon in top left corner

May 27, 2020, 6:11 am
$
0
0

Steps to reproduce

  1. Install Drupal 8.9
  2. Create a block type or two
  3. Enable layout builder module
  4. Enable Claro theme
  5. On a CT display, enable "Use Layout Builder" and click "Edit layout"
  6. Add a block in a region

Current result

  • Messages display an additional icon in the top left corner

Expected result

  • Messages should not display any additional icon in the top left corner

 

↧
Viewing all 294883 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>