🇯🇵Japan @ultrabob

That all makes sense to me. I'm also not an expert on all the caching and context details here. I just know that when I tried to place the field as a block in block layout, I started getting the DWSOD. Given that this was happening with an Entity Reference field, I wonder if the core Entity Reference Field Formatter has an example we can learn from. Maybe the solution is to detect whether there is a render context, and only renderInIsolation or renderPlain when it isn't present. I appreciate you being responsive on this. It is a very cool module, that I became familiar with due to a talk at PNW Drupal Summit and then again a bit later at BADCamp last year.

I realized after submitting this that there is a new 3.1 release, so I tried installing that to see if it fixed my issue. It did not, but the patch applies to the new version and still works, but now I get a bunch of Warnings such as

Warning: Undefined array key "wrappers" in Drupal\custom_field\Plugin\Field\FieldFormatter\BaseFormatter->getFormattedValues() (line 477 of modules/contrib/custom_field/src/Plugin/Field/FieldFormatter/BaseFormatter.php).

and

Warning: Trying to access array offset on value of type null in template_preprocess_custom_field_item() (line 119 of modules/contrib/custom_field/custom_field.module).

so I've reverted to 3.0.x

I've created a merge request with the suggested change in place.

ultrabob → created an issue.

That fixes it. I have a few more improvements I want to make in the code, and then I'll put out a release for this. Thanks!

Thanks for that follow-up. We may need to consider a different selector for the gin theme. Any further detail or a patch would be greatly appreciated.

I'm sorry to hear that you are having trouble. I just tested with /node_*/ in the box, and the preview button was gone for all content type add and edit forms. Are you including the quotes? (The quotes should not be there)

kthull → credited ultrabob → .

I'd be glad to take this on again, assuming all works out to be there. Since I have the recording kit, some of it would be more straightforward next year.

For me, locking the module to 1.10 and adding this to my composer.json seems to get it to ignore the problematic patch.

    "patches-ignore": {
      "goalgorilla/open_social": {
        "drupal/views_ef_fieldset": {
          "Issue #3173822: Exposed operators are not included in fieldsets": "https://git.drupalcode.org/project/views_ef_fieldset/-/merge_requests/1/diffs.patch"
        }
      }
    },

This has broken our deploys for open_social as well, and I'm not sure how we could go about fixing it.

I'm not sure what the latest compatible version of views_ef_fieldset is. I've seen an issue saying that 8.1.10 is incompatible, so it is hard to construct a replacement patch, but even then, I'm not sure if we can patch the open_social composer.json.

As helmo points out, Gitlab patches should never be linked because they tend to disappear like this one did.

liberatr → credited ultrabob → .

I ran into this issue on an Open Social site, where a flexible group creation form had a taxonomy term entity reference field. Without the patch, there was no $form[$key]['#parent'] which led to a WSOD. The patch here showed the error message in the wrong place instead of the entire form white screening.

Confirming that patch #6 fixes the issue, but do not have time at the moment to contribute a test case to support the fix.

liberatr → credited ultrabob → .

I tested this with Drupal 11, and ran into an error when using the widget in the display due to the assert asserting the wrong type. I've fixed that issue, and tested that the module now works as expected with Drupal 11.

ultrabob → made their first commit to this issue’s fork.

Thank you for pointing that out. It has been addressed in the 2.0.x branch.

In that case, how about:

Node Menu Placer provides a new UI to facilitate the quick placement of nodes in complex menu structures. This module works with the Menu Link Weight module to update the menu settings of the node form.

https://www.drupal.org/project/node_menu_placer →

ultrabob → created an issue.

I'm not sure why the RectorBot created 5 Drupal 11 tickets, but I found a minor bug, fixed the tests, and marked the module as Drupal 11 compatible. I'll do a release shortly.

As long as the functionality of this module, doesn't interfere with how ckeditor5's autogrow functionality works, I'd say we go ahead and update it given that the only change that seems to be needed is updating the version in the info file.

ultrabob → made their first commit to this issue’s fork.

@robloach, I have confirmed that this issue exists, but this change doesn't seem to fix it. In my testing editMenuMenuParent was always defined, but an error happens later around line 193 where we try to get the parent menu title:

let currentParentTitle = currentOption.innerText.substring(
  currentOption.innerText.indexOf(' '),
);

currentOption has just been defined as null. so getting innerText is not possible. I think this is a pretty big problem of a bug, but I don't have the time to try and debug it at the moment.

ultrabob → made their first commit to this issue’s fork.

hestenet → credited ultrabob → .

hestenet → credited ultrabob → .

hestenet → credited ultrabob → .

hestenet → credited ultrabob → .

hestenet → credited ultrabob → .

hestenet → credited ultrabob → .

hestenet → credited ultrabob → .

hestenet → credited ultrabob → .

The status of how to do it via UI is still unclear, and the github issue has been closed, saying that there are details in a JIRA ticket. Here is how I accomplished the translation for french using the config files:

Create a new file called core.entity_view_display.private_message.private_message.inbox.yml in your default config/language/<langcode_here> directory. In my case, the contents of this file are:

langcode: fr
content:
  created:
    settings:
      past_format: 'il y a @interval'

Make sure to update the langcode value if you are translating a different language.

Create a new file called core.entity_view_display.private_message.private_message.default.yml in the same directory. Similarly, my contents were:

content:
  created:
    settings:
      past_format: 'il y a @interval'

Import config, and the private messages interface should be translated properly. I did not translate the future_format because I never expect to receive a private message from the future. You can translate that by adding the future_format key just above the past_format key.

I came here looking for deprecation details. It is essential to provide guidance about how to determine whether the module is safe to uninstall.

This has been merged, so I'm marking it as fixed.

ultrabob → created an issue.

ultrabob → made their first commit to this issue’s fork.

Info out of the starshot initiative webinar today: This is not possible. We'd need to provide a separate recipe to do it, recipes cannot be shipped as part of modules.

ultrabob → made their first commit to this issue’s fork.

Workflow Buttons now passes all linting and code analysis with no warnings or errors. There is another issue for adding tests, given that the existing tests were not testing Workflow Buttons features.

ultrabob → created an issue.

The drush recipe generator has never actually worked for me.  Is it just me, or should we remove that link?

In the issue description, it says that "site feature" is commonly used, but the wordpress.com example is using "your site's features." These are just English words used together in a sentence, not a unit that is commonly used. I'm not sure what the benefit of prepending "site" to "feature" is, unless this issue is a proposal for core or Drupal CMS recipes only, which is not clear from the description. Feature seems a better alternative than site feature.

I'm likely missing some context that isn't in the description, but it seems to me, that just like modules and themes, recipes will need short descriptions for both their page on drupal.org, and eventually for project browser. I'm not sure that mandating a name is all that useful or enforceable.

I think it is hard for the name to provide enough information about the type of things done in the recipe, the intention of the recipe, and the scope of the recipe. I feel like it would be better to focus on better descriptions, and consider some type of mechanism for automating a summary of the actions a recipe will take in a way that it can be more easily absorbed than by reading the yml file, etc.

Something along the lines of headings like:

Modules Installed

Config Modified

Actions Invoked

Content Added

with summaries in them. We wouldn't want to dig into deep detail, but could give a summary that should along with a short description, give a good idea that the recipe does what you think it does.

In the issue description, it says that "site feature" is commonly used, but the wordpress.com example is using "your site's features." These are just English words used together in a sentence, not a unit that is commonly used. I'm not sure what the benefit of prepending "site" to "feature" is, unless this issue is a proposal for core or Drupal CMS recipes only, which is not clear from the description. Feature seems a better alternative than site feature.

I'm likely missing some context that isn't in the description, but it seems to me, that just like modules and themes, recipes will need short descriptions for both their page on drupal.org, and eventually for project browser. I'm not sure that mandating a name is all that useful or enforceable.

I think it is hard for the name to provide enough information about the type of things done in the recipe, the intention of the recipe, and the scope of the recipe. I feel like it would be better to focus on better descriptions, and consider some type of mechanism for automating a summary of the actions a recipe will take in a way that it can be more easily absorbed than by reading the yml file, etc.

Something along the lines of headings like:

Modules Installed

Config Modified

Actions Invoked

Content Added

with summaries in them. We wouldn't want to dig into deep detail, but could give a summary that should along with a short description, give a good idea that the recipe does what you think it does.

tekNorah → credited ultrabob → .

@wylbur thanks a lot for your work on this. It looks like at this point we only have three minor phpstan warnings left, which we could add to the baseline and try to fix later, but given that they don't look like hard issues, I think I want to fix them so we can start with fully passing gitlab-ci.

Thanks for the review wylbur! I started trying to fix the tests, and when I looked into them deeper, it appeared to me that the tests had been copied from elsewhere, and were not testing the functionality of this module. We need a follow-up issue to add some test coverage for the module.

ultrabob → created an issue.

I fixed some cspell issues and some of the test issues, but ran out of time to solve the menu_link dependency fail. It probably needs a composer.json added so that menu_link will be available to the tests to get the unit tests to progress further

ultrabob → made their first commit to this issue’s fork.

ultrabob → made their first commit to this issue’s fork.

The BOF schedule description for the coffee exchange says "be sure to register below" which may be leftover from something else, or maybe I'm missing a link somewhere? It may not be possible to change, but I thought I'd point it out, and this seems like the best venue for that.

This is related to the Testing Techniques page linked in Related Pages.  It confused me to click on the Testing Techniques page and end up in the DeGov distribution documentation.  I recommend that we either make it clearer, that that is where the link is going or come up with a version of that page for Drupal core.

It confused me to click on the Testing Techniques page and end up in the DeGov distribution documentation.  I recommend that we either make it clearer, that that is where the link is going or come up with a version of that page for Drupal core.

Thanks for doing that. The checkers that come with GitLab-CI surfaced a bug that I've also fixed, and merged.

ultrabob → made their first commit to this issue’s fork.

ultrabob → created an issue.

It turned out that a cache clear was needed before trying to install. I'm still not able to install the recipe, but that seems likely to be related to the directory structure causing issues with the composer unpack plugin.

I've tried moving the kalastarter directory directly into the recipes directory with the same result, so it appears not to be a matter of where the recipe gets placed.

ultrabob → created an issue.

Kristen Pol → credited ultrabob → .

While this patch was completely ignored. It does look like someone came along and added a warning when there are no constraints, so I think this is good to stay closed. Thank you

hestenet → credited ultrabob → .

hestenet → credited ultrabob → .

hestenet → credited ultrabob → .

I've made several changes from fixing spelling errors to refactoring the javascript. It now passes all the CI checks. I just need a maintainer that is using it on their project to test that it still works as expected.

Code makes sense and the previously failing pipeline now passes! Thanks!

fjgarlin → credited ultrabob → .

Amazing, thank you for that quick fix!

ultrabob → created an issue.

Menu Link Weight 2.x completely changes the way it handles menu link weights. It begins doing it as a field, rather than using menu_ui. It would be welcome to make it work, but will also be a non-trivial undertaking. I'm going to adjust the composer.json file back to enforcing version 1 until this is complete.

Confirm I am running into this, just trying to get gitlab-ci configured for my module including next major version. My module doesn't have a package.json, so the failure seems unrelated to the module itself.

I've added RobLoach as a maintainer.

This does not work as expected in Open Social 12.

The group is translated:
In English it shows up properly:
In French interface it still shows in English:

Here is a modified patch to make it work again.

volkswagenchick → credited ultrabob → .

volkswagenchick → credited ultrabob → .

I'm hoping to work on it here today. If anybody pitches in I'll be thrilled.

I propose we build a form for this rather than trying to remove appropriate elements from the edit form.

ultrabob → created an issue.

Indrapatil, mlncn is this one good to close?

Thanks Katy,

Without investigating yet, I think that makes sense. The code that removes the fields that shouldn’t be there doesn’t impact the structure of the form where fieldsets are handled.

I’ll try to follow a new issue for that tomorrow and see if I can get it fixed.

Actually, it sounds like my problem is different. I'm trying to figure out why I can't access revisions, and this ticket is trying to restrict access to revisions further. Please disregard.

I installed the latest patch, and went in and turned on view all revisions in global permissions and the view revision permission under the group type permissions. I have tracked down where I get access forbidden down to Drupal\group\Plugin\GroupContentAccessControlHandler::entityAccess where the system is looking for a permission called "view all group_node:topic revision" against the list of permissions for the group in Drupal\group\Access\GroupPermissionChecker::hasPermissionInGroup. None of the permissions for the group had anything to do with revisions.

ultrabob → created an issue.