Account created on 22 December 2006, about 17 years ago
  • Senior Software Engineer at BixalΒ  …
#

Merge Requests

Recent comments

πŸ‡ΊπŸ‡ΈUnited States RoloDMonkey

If you are running 4.0.x with PHP 8.2 you may still see this error. If so, you can use this link to patch it.
https://git.drupalcode.org/project/smart_date/-/merge_requests/63.patch

πŸ‡ΊπŸ‡ΈUnited States RoloDMonkey

The other error when $element[0] is empty is not directly related to this one.

I created πŸ› Javascript warning from content language and translation page Needs work for that error, and provided a fix.

πŸ‡ΊπŸ‡ΈUnited States RoloDMonkey

As far as I can tell, this issue is not fixed by πŸ› contentTranslationDependentOptions behavior doesn't check if found element array is empty RTBC . That is a very similar issue in the same file, but not in the same place.

The merge request "failure" was just some suggested whitespace changes. I have made those changes and everything is passing now.

πŸ‡ΊπŸ‡ΈUnited States RoloDMonkey

Since it has been more than a year since this was marked RTBC, and people are still actively debating the correct solution, I am bumping this back down to "Needs work".

πŸ‡ΊπŸ‡ΈUnited States RoloDMonkey

I have applied this patch while running Drupal 10.2.0 and it works.

πŸ‡ΊπŸ‡ΈUnited States RoloDMonkey

Expected behavior:

When the main entity type, like Article, is translatable the fields under the article should always be expanded. On the other hand, if the translatable checkbox next to an entity type is not checked then its fields should not be visible.

The fields will become visible if you are clicking the translatable checkbox for the first time, or if you turn it off and then back on again. But, they are not expanded when the page first loads. That is why I marked this as a major issue, because right now there isn't a way to accurately view and manage which fields are translatable through the UI.

πŸ‡ΊπŸ‡ΈUnited States RoloDMonkey

Is the 4.1 branch set up for automated testing? If so, the patch needs to be submitted in the correct way so that it will trigger automated testing.

πŸ‡ΊπŸ‡ΈUnited States RoloDMonkey

This is a duplicate of πŸ› User deprecated function - warning Needs review .

πŸ‡ΊπŸ‡ΈUnited States RoloDMonkey

I also couldn't make heads or tails of those tables. Right now, it looks like someone copied and pasted the tables without changing the release versions. Either that, or there were going to be multiple releases of the same versions on completely different schedules.

We definitely need to include some way to let visitors know that each table is a possible release schedule.

πŸ‡ΊπŸ‡ΈUnited States RoloDMonkey

TLDR:

  1. I was also able to make these errors go away by clicking on "Check manually".
  2. This might be a problem with how Drupal provides dev versions of modules via Composer

I just saw this when checking /admin/reports/translations. Six modules threw this warning. In four cases, we required a dev version in composer.json. In one case it was a module that had not been in the codebase for months. I don't know how to explain that.

For the four cases where we were pulling dev versions of modules, the .info.yml files did not have a project, for instance:

name: Admin Toolbar
description: Provides an improved drop-down menu interface to the site Toolbar.
package: Administration
type: module
configure: admin_toolbar.settings
core_version_requirement: ^9.2 || ^10
dependencies:
  - drupal:toolbar

In other cases, the project was added when pulling the module from Drupal, like so:

name: 'Block Class'
type: module
description: 'Allows assigning the classes to Blocks.'
package: User interface
configure: block_class.settings
core: 8.x
core_version_requirement: ^8 || ^9 || ^10
dependencies:
  - drupal:block

# Information added by Drupal.org packaging script on 2022-12-26
version: '2.0.11'
project: 'block_class'
datestamp: 1672065315

The last case was CTools, which was surprising. It looks like our composer.lock file still thought that CTools was required by Pathauto, even though that is no longer the case, and we did not have CTools enabled.

πŸ‡ΊπŸ‡ΈUnited States RoloDMonkey

This is still an issue. If you have this module installed, and you enable Actions, then when you go to configure actions (/admin/config/system/actions) you get a fatal error.

This module needs to be compatible with core. A hidden requirement for Views Bulk Operations is not good.

See also: https://www.drupal.org/project/views_bulk_edit/issues/3173187#comment-14... β†’

πŸ‡ΊπŸ‡ΈUnited States RoloDMonkey

Thanks to everyone for fixing this! I have been putting up with my terminal being flooded by duplicate messages while I tested and re-tested a pretty complex migration. I never had time to look into why it was happening.

Today, it took me a moment to realize that I only saw one line/notice in my terminal for each migration. What a pleasant surprise!

Production build https://api.contrib.social 0.61.6-2-g546bc20