🇺🇸United States @k_a_l

volkswagenchick → credited k_a_l → .

volkswagenchick → credited k_a_l → .

Hi Scott, understood. It's likely my IDE was making additional improvements. I synced with 1.0.x and removed some of the minor updates to improve diff readability. Thanks

k_a_l → created an issue.

k_a_l → created an issue.

After troubleshooting this, it's more so an issue with sending the selected text to the jQuery UI dialog, which is done as a query string. The AI request is already being sent as a POST request. I had the same issue, so I decided to refactor how the data is sent by using a JavaScript object instead of query parameters.

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

FWIW, The work being done in 3266732 ✨ Need @media(max-width)/(min-width) capacity Active will solve the inline styles issue I mentioned previously.

This is looking great! I finally had the chance to test out the fork, and thank you, mortona2k, for your contributions. I completely agree—this seems like a strong candidate for a v2 release. Moving away from inline styles is essential for adding improvements and new features, so it’s great to see that shift happening.

It’s been a while since I’ve reviewed this code, so I may need a bit more time to dive in and offer more detailed feedback. That said, I’m really pleased to see a solid solution addressing the known issue, along with several enhancements. Well done, and cheers!

Hi jive01,

Thanks for your interest - it's definitely an interesting idea.

Is the requirement that this needs to be within the same section, or could you add another section below with a different grid structure? If it’s within the same section, we’d need a way to combine rows or subsets of columns within the main section’s grid and treat them as a grid area, which could then have its own grid dialog options.

One big limitation we’re currently facing is the module’s reliance on inline styles for grid layouts, which prevents us from using features like grid-template-areas. Implementing something like this would likely require a refactor in how styles are generated and applied to the markup.

I've tested the MR and I'm seeing a console error stating "$submit is not defined". The issue looks to be because $submit is defined within the attach method but not in the detach method, which is why it is not available when detach is called.

After moving that variable into a higher scope, your patch does seem to fix the issue.

I reconfirmed patch #6 works, but only with gin:3.0-rc9 and multiselect:2.0.0-beta2. The latest patch wasn't working with gin:3.0-rc13 and multiselect:2.0.0-beta4, if that helps. FYI, I had to downgrade gin_lb in order to install gin rc9.

Using Drupal 10.3.2

greysonniedbalski, because the error goes away on page refresh, it indicates a caching issue. To sidestep this, I've set up a cron job that requests the /simplesaml/module.php/core/welcome page in SimpleSAMLphp in an effort to “warm up” the Symfony router. This approach appears to be effective, as I haven't seen the error since implementing it.

Hi, there seems to be a regression with this patch after some recent updates:

Drupal: 10.3.0
Gin: 8.x-3.0-rc12
Admin Theme: Gin
Multiselect: 2.0.0-beta3 or 2.0.0-beta4

I tested the patch in #9 but it also didn't resolve the original issue. No console errors, however, I'm not using Big Pipe on my site.

Still seeing that cache error after rolling back to symfony/framework-bundle:6.4.3

The router "Symfony\Component\Routing\Router" cannot be warmed up because it does not implement "Symfony\Component\HttpKernel\CacheWarmer\WarmableInterface".

I've set up a temporary cron ping in an effort to bust the cache from the SimpleSAML welcome page to avoid concern from our users. Hopefully that will work for now until a fix is available.

Thanks

I'm seeing these issue too. I've tried patching as mentioned in #3453721 💬 Fatal exception with simplesamlphp 2.2.2: non-existent service "serializer.normalizer.object" Closed: works as designed but the "WarmableInterface" cache issue persisted. I'm now testing rolling back to symfony/framework-bundle:6.4.3 and will report back.

k_a_l → created an issue.

k_a_l → created an issue.

My mistake, was not applying due to another patch being applied.

This patch wasn't applying cleanly for me so I updated it for latest 3.6.

k_a_l → created an issue.

k_a_l → created an issue.

This has been resolved with the modules' latest releases.

Updated some of the older verbiage/commands and removed references to a deprecated module that's now just refereed to as Migrate Tools.

k_a_l → created an issue.

The permissions for this role in question are set to: "Use the Moderation Dashboard" but not "View any Moderation Dashboard".

I think the issue is the canonical user route has a user object parameter, while the moderation dashboard view page only has the user id.

In the access method of src/Access/ModerationDashboardAccess.php, $current_user_id = $this->routeMatch->getParameter('user'); can either be the user object or the user id depending on the route, from what I found. As you can see in the module's Access class below, if a user object is pulled from the route, the access conditionals are not met, which ends up forbidding the local task link on the user page. See a side by side of the two different params returned from the route in Screenshot 2023-02-16 at 12.12.02 PM.png

public function access(AccountInterface $account) {
    $dashboard_owner = $account;
    $current_user_id = $this->routeMatch->getParameter('user');

    // If the current user is on their own dashboard, they can view it.
    if ($current_user_id === $dashboard_owner->id() && $dashboard_owner->hasPermission('use moderation dashboard')) {
      return AccessResult::allowed();
    }

    // If the given user doesn't have a dashboard, nobody can view it.
    if (!$dashboard_owner->hasPermission('use moderation dashboard') && !$dashboard_owner->hasPermission('view any moderation dashboard')) {
      return AccessResult::forbidden('User does not have access to view this dashboard.');
    }

    // But they can only view the dashboard of others with another permission.
    if ($dashboard_owner->hasPermission('view any moderation dashboard')) {
      return AccessResult::allowed();
    }
    else {
      return AccessResult::forbidden();
    }
  }

A I think a better alternative would be to use getRawParameter('user') to always pull the user id.

Sorry, there’s no error. My user cannot access the Moderation Dashboard from the local task menu on their profile page.

My user's profile page (/user/ID) returns an object as the route parameter where as the moderation page returns and id. In src/Access/ModerationDashboardAccess.php, a check against an id is done. Since I have a user object, that conditional fails for me. Drupal 10.1 as well.

k_a_l → created an issue.

Added the CSS Grid Layout module as another option.

Adding a conditional that checks for subfolder paths in `getSitePath()` in order to fix a redirect issue when nodes are created for registered or published sites.

Fixes validation and alias generation issue

I've refactored this based on your suggestion to use path aliases. The code still needs constraint validation among other improvements and tests, but it seems like a good [re]start and would appreciate any additional feedback. Thanks!