🇺🇸United States @asherry

asherry → created an issue.

I'm still seeing this issue as well with the paragraphs report → . That module is just calling:

    // Table output.
    $table['table'] = [
      '#type' => 'table',
      '#title' => $this->t('Paragraphs Report'),
      '#header' => $tabular['header'],
      '#sticky' => TRUE,
      '#rows' => $chunks[$current_page] ?? [],
      '#empty' => $this->t('No components found. <br /> You may need an Admin user to enable content types on the "Settings" tab and click the "Update Report Data" button.'),
    ];

I'm still seeing this issue as well with the paragraphs report → . That module is just calling:

    // Table output.
    $table['table'] = [
      '#type' => 'table',
      '#title' => $this->t('Paragraphs Report'),
      '#header' => $tabular['header'],
      '#sticky' => TRUE,
      '#rows' => $chunks[$current_page] ?? [],
      '#empty' => $this->t('No components found. <br /> You may need an Admin user to enable content types on the "Settings" tab and click the "Update Report Data" button.'),
    ];

+1 for this patch. This error message when we moved to PHP 8.2 is very annoying in dev environments.

I should add, in case anybody else tries, I was tempted to submit another patch with constructor promotion. It would be cleaner, it would only be a change of one line:

  public function __construct($plugin_id, $plugin_definition, FieldDefinitionInterface $field_definition, array $settings, $label, $view_mode, array $third_party_settings,
  protected AccountProxyInterface $currentUser) {
    parent::__construct($plugin_id, $plugin_definition, $field_definition, $settings, $label, $view_mode, $third_party_settings);
  }

... but it won't work for Drupal 9. Since the current version of this module supports Drupal ^9 it needs to also then be compatible with PHP 7.3+.

asherry → created an issue. See original summary → .

Fixes issue with parameters getting sent as a reference

@pschuelke and @ChristianSanders your particular issue of access was addressed at the end of the linked issue here https://www.drupal.org/project/menu_item_extras/issues/3167363#comment-1... 🐛 Children block not rendering children in Layout Builder Needs review

This ticket is not about access, this is about the issue with double rendering of the menu item extras because of being in preprocess vs an entity build.

This ticket is actually also just a different branch version for 🐛 Children block not rendering children in Layout Builder Needs review . If you do a re-roll of the code here it should be all the code I included, or, if it's not, it should be addressed in another ticket.

This issue is already very confusing, with this new patch it's now buried what the original intent of my code was.

I'm not sure I agree that it's a core issue, particularly regarding EntityReferenceFormatterBase. This class is very generic. It's meant as a basis for all entity references including entities that are not revisionable as well is config entities. In order to "load a revision" you would have to actually check if the entity is revisionable, which is well outside the scope of that class and would add complication for extending classes.

asherry → created an issue.

I'm going to update the status of this. I appreciate the effort, though I think the hard part isn't identifying that this project needs documentation, I think the hard part is actually writing the documentation.

Even the comment I just made took a while to explain coherently, hence, the lack of documentation.

It's a compound field. The original need was, for an event, to have an attendance count for different types of participants. So for an event node if you had:
- Adults: 10
- Children: 12
- Seniors: 4

... etc. The way I decided to set it up though, I added the ability to add any number of counts, so not just a count of 10, but several counts and with different labels. The column names will then depend on the field instance.

I re-used the module on a few projects in different forms, and so I've only had time to basically maintain the code. (upgrades, bug fixes). I haven't advertised it or had the time to make a project page.

If you'd like to help with that, I'd be more than happy to look anything over and publish it.

asherry → created an issue.

asherry → created an issue.

Thank you Bot, very kind of you.

update: getData should return the iterable data $iterableData. This is just in case any controllers want to manipulate the data, they will be able to do an offsetSet, but they can't (nor shouldn't really) edit the original response data itself. That should be renamed to a specific getResponseData.

asherry → created an issue.

asherry → created an issue.

I believe we're experiencing this issue. The current media view we're using has filters, but, I can replicate that the checkbox value and the image associated with it are out of sequence even without clicking a filter.

Just using the pager seems to render some items incorrectly. I wrote a quick script to try in the browser to compare the input value with the name of the image, does anybody else have this same markup?

jQuery('.js-media-library-item').each(function() {
    var $wrapper = jQuery(this);
    console.log($wrapper.find('.form-item__label').text() + ' ---- ' + $wrapper.find('.media-library-item__name').text())
})

Thank you for your help, and thank you very much for such an incredibly quick turnaround. When I saw my name appear on the project page as a maintainer, I thought that I had already submitted this and had maintainer status the entire time!

I'm not sure what you mean by "set the value for two projects", but for me everything seems right.

Turning this over to drupal.org support. I'd like to use this module for a field type/widget that handles 'weeks' specifically. This wouldn't be a specific date, it would be a way to choose "The week of [a date]", and then filtering in views would know to filter by this date 'range', or, could easily filter other 'week' values as well.

This is working on a production site already, here's a sandbox version https://www.drupal.org/sandbox/asherry/3208278 →

asherry → created an issue.

I can't really tell what patch version was actually committed, but, regardless almost everybody at least deserves issue credit for their work, not just the last person that submitted a patch.

There is still a remaining issue with this now not working with the FormAlter class. The class resolver is going to require the ::create() method, which the FormAlter class can't really use.

The form alter class implements its own createInstance so that it can always pass the $form and $form_state, with also a $context variable.

asherry → created an issue.

Justin/James: This really looks like a duplicate of the issue 🐛 Media Library validation bug when content type has a media field and a paragraph field with the same machine name Closed: works as designed . Changing the #parents array isn't a real complete solution.

Updated the approach to be a bit more logical. Using "audio.mediaelementjs,video.mediaelementjs"

asherry → created an issue.

Fixed two major issues with the last patch.
- Before auto alias creation we need to check if the current page is 404. (this might need more work)
- Check to see if there is an existing alias in the current language, OR in language unspecified.

marcelovani: I had already given you the permissions. You should have already seen the edit tab appear on the project page.

We're having the same issue. This block is doing its access check based on \Drupal\flag\Entity\Flag::access(). I don't know if/when things changed, but, the flag module doesn't actually seem to use the ::access() method for flagging, it seems to just use that for administration.

Access to see if a user has the permission to do a flag action is done with the "access_check" tagged services FlagAccessCheck and UnFlagAccessCheck. It makes sense I guess, the actual places it needs to check access are primarily done in routes. These methods are calling the Flag::actionAccess method and rather than use "create" as an action, it uses "flag" and "unflag".

I added a patch to check which action needs to be sent to ::actionAccess and then returned that for ::blockAcces.

asherry → created an issue.

I hope it's ok but I merged in the changes from 📌 Automated Drupal 10 compatibility fixes Needs review . I did this primarily because there was no composer.json file in this repo and it was already created there. I couldn't actually use the work here in composer until that was done.

Hopefully this will create less merge conflicts after that ticket is merged and then this one comes after.

Alternatively we might want to consider a 3.x branch and leave the 2.x branch to be compatible with Drupal 10 + ckeditor4.

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

asherry → changed the visibility of the branch 3296772-D10-ck4 to hidden.

asherry → changed the visibility of the branch 3296772-D10-ck4-#11 to hidden.

asherry → created an issue.

@solideogloria thanks for keeping an eye on that. That would definitely be a new ticket, although I'm not sure there would be anything actionable until at least #3179551: Provide no-library equivalents of common/useful jQuery functions → is done.

It looks like jQuery functions are being replaced by Drupal js functions using vanilla JS, and they have yet to be written. If we write our own functions it's repetitive and messy, but if we use the new functions it will break backwards compatibility.

Thank you for this, this is helpful. I made some tweaks that should probably be properly exempted but the rest is committed.

I'd like to see if there is a more performant solution than setting the caching to 0. It would be better if maybe:

• There was an added cache tag for the notification message entity in case of changes
• The cache max age was set to the difference between current time and the end date for the entity

The date fix was actually covered in 🐛 Message won't dismiss Fixed along with a JS issue. I'm not marking this as a duplicate though, as I like the actual code to create the date here better than in the other ticket.

I merged this code in with the other code.

This has been committed, thanks for your work on this. Very appreciated!

Ran into another error if the $arg variable turns out to be a proper EntityInterface object. I put in another check to see if it's a proper entity, just add it to the array, but, also check if it's an int/str to make sure it's safe to pass to entity load.

Still not sure about this solution as a whole, but, it's fixing errors for us at the moment.

Changes for the changes and MR to the 5.x branch. This works for us, marking this as RTBC.

Thanks @jldust, the patch in #3385283 works for us on 10.1.6.

I do still see validation issues though, somewhat related. It looks like there is an issue in the current 5.1.x accordion item component. Rather than open up a new ticket I made a quick patch that should fix this, however, we should probably create a new ticket to add a simple kernel or functional test to validate component.yml for prototype.

We were using this branch but unfortunately it looks like almost every line of code in it is outdated. The current 2.x branch handles drupal 9 compatibility and 📌 Drupal 10 Compatibility Active addresses Drupal 10 compatibility.

Going to mark this as outdated and recommend (although it's structurally very different and there doesn't seem to be an upgrade path) others should upgrade to 2.x

I pushed some updates to get the latest in 8.x-1.x. I still think Drupal 9/10 compatibility would have been better handled in a 2.x branch. I had to add in 🐛 jquery.once deprecated in D10 RTBC as well to this merge request as the once library isn't handled currently in 8.x-1.x.

For what it's worth, a few things I want to add a few things.
I would love to see some progress on this module as well. We inherited a project and it would be good to know if we'll need to move away from it, or contribute.
🐛 Compatibility error with Deprecated function: Return type of WsdlToPhp\PackageBase\AbstractStructBase::jsonSerialize() Active will need to be addressed and it's not an easy fix
📌 Drupal 10 Compatibility Needs review is close but doesn't seem quite ready
Aaron would be a great choice to help out. I support that 100%.

I believe that any request to maintain needs to be created as a support request first and set to needs review. It then gets sent over to d.o maintainers if there is no response. I'm going to change that now, feel free to correct me if I'm wrong.

asherry → created an issue.

asherry → created an issue.

I had this same issue and it seems to be fixed by the patch in #8 in 🐛 Drupal 10.1: fatal error on account creation Fixed , but more importantly it appears to be exactly the same error that's laid out in that issue.

I'm going to close this and mark it as a duplicate so that it's easier for people to reference.

asherry → created an issue.

Work for this is completed in 🐛 Drupal\eca\Plugin\Action\ActionBase causes issues for action plugins that extend FieldUpdateActionBase Closed: duplicate for better context

Thanks for your work and time on this jurgenhaas. I pushed this into version 8.x-1.0-alpha7 and 2.0.x. I'll create another 2.0.x release after testing some more.

• Drop support for Drupal 8
• Add support for Drupal 10

This version will act as an in-between for sites using the now removed ResponseObjects.

asherry → created an issue.

Good question, now that you mention it this was happening on 6.1.4 as well.

We're in the process of upgrading from D9-D10, so we upgraded webform from 6.1.4 to 6.2.0-beta4 and then to 6.2.0-rc2. This issue seems to be present on all of those versions.

asherry → created an issue.

I talked this over with jurgenhaas. This plugin and class is low-key enough to remove the constructor override.

If I could just ask that you:

• Close this ticket out and create a new one with a very clear description. Example: #3067546: [Webform 6.x] Fix subclassing and stop overriding constructors → . I'd like to make sure it has no reference to ECA or any ECA error messages as that will confuse the origin of the change.
• Please move the MR and update the code to create a setter method for the event dispatcher. As it is right now, it's setting a protected property

I've found the thread in slack where this started and I now have more context as to why the error message is showing up like this. https://drupal.slack.com/archives/C0287U62CSG/p1697106849930059?thread_t...

I'm still not sure how the alias is working, particularly in such a way that APItools thinks it's overriding an ECA class.

I'm willing to help with a solution, though, the MR/patch laid out here is not going to work.