🇨🇦Canada @joelpittet

A change to the query to avoid

Expression #1 of HAVING clause is not in GROUP BY clause and contains nonaggregated column 'db.users_field_data.mail' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

1. Accessing argFormat via a getter method:
   

   • The code now checks if the getArgFormat() method exists using method_exists(). This ensures compatibility with the patch in issue #2325899 while maintaining backward compatibility if the patch isn’t applied.

2. Providing default values for other date argument classes:
   

   • The method includes specific cases for additional date classes, such as WeekDate, MonthDate, and DayDate, providing appropriate formats for these cases.

   • It adds a sensible default ('Y-m-d') for any unhandled cases, ensuring that the method will always return a valid date format.

joelpittet → created an issue.

I thought we could keep committing to a merged MR similar to what I have done in gitlab but apparently not.

I have merged it though here https://git.drupalcode.org/project/calendar/-/commit/a026ab7b18fea50a16c...

With some cleanup with phpcbf in this commit
https://git.drupalcode.org/project/calendar/-/commit/69f417e1c26f5bfe6f1...

That closes out the need to have Tests added to the calendar module thank you @ramil g, @franceslui, for the commits and @Diego_Mow for reporting it on behalf of the "phpunit initiative"

Thanks @ramil g I think that answers the question.

I recommend 1.x branch instead of the 2.x branch because we are giving it more attention as it's a closer port to D7.

Thanks @ramil g I will merge the MR in a moment.

I am going to move ahead with this change while I have momentum. Now there is less conflict and more CSS points to hook into to and modify with a reasonable (looking) default.

I will close this issue when we have

@johnv I was thinking the same thing but that would mean it would only be added when the view has the CalendarHeader area in there... The MR looks better at this point but maybe there is somewhere a little less global we could add it?

@sagarmohite0031 that must be the patch, the MR should look like my screenshots.

joelpittet → changed the visibility of the branch 3196394-test to hidden.

That seems to fix it in my quick test

joelpittet → created an issue.

Shouldn't the granularity need to be seconds and not minutes (in the patch)

-      $form_state->setValue(\array_merge($valueParents, ['time_start']), '00:00:00');
-      $form_state->setValue(\array_merge($valueParents, ['time_end']), '23:59:59');
+      $form_state->setValue(\array_merge($valueParents, ['time_start']), '00:00');
+      $form_state->setValue(\array_merge($valueParents, ['time_end']), '23:59');

I would assume 23:59:59 would be the fix here?

This might be good to have a test case to cover this bug report?

Seems like a nice UI improvement, hides the occurrences button where there are none.

Just so nobody gets tripped up by this, I fixed the Drupal 11 composer mentioned in #19 issue in 🌱 Add Tests and enable gitlab-ci Active

There are lots of rough edges in the beta release. I am hoping to iron a bunch out and add some tests.

I am hoping this will do the trick, the default pager classes conflicts with too many other theming elements and Olivero goes it's own approach.

This makes the pager a bit closer to Full Calendar and could fairly easily be themed like that. I added some SVGs for good measure

There has been no response so I am going to close this as fixed but also can't reproduce as per comment #11 but I am glad you both agree and there is an ISO-8601 to back up the decision

This one is kinda funny PagerPluginBase overrides that with "Unknown" but "PluginBase" has "Settings".

Thanks again @marc.bau and @vensires

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

Thank you @marc.bau that is a good solution.

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

I agree there is a problem there but core doesn't use those utility classes on it's pagers. I think we should follow core pager classes or write our own to avoid conflict if they need to be different.

This is a closed fixed issue, please open a new issue if you have something to contribute, please don't assign tasks to yourself.

joelpittet → created an issue.

Totally exist this module needs tests. I will make a plan and add this to it.

joelpittet → changed the visibility of the branch issue/calendar-2820803-2820803-support-recurring-dates to hidden.

There is still CSS code in the patches. This still needs work.

@claudiu.cristea I didn't remove the comment yet as I did a close to a straight copy over. But once I can confirm its resolved I will remove it.

After merging the 📌 Group roles and permissions UI Active I replaced Role class from core from the OgRole exends with ConfigEntityBase like it does and copied all the code up to OgRole, so it should in theory work the same as it did before... Though I am human so likely made a mistake, though I tried to make the changes as "diffable" as I could

Actually when doing 📌 The OG role 'og_role' entity should not extend core's 'role' Active I realized I was duplicating work here, so wanted this in as a base for that work.

This fixes the problem, ConfigEntityInterface is what RevisionableEntityBundleInterface extends from but without the need for the entity to be revisionable.

joelpittet → created an issue.

That error might be resolved after this: 📌 The OG role 'og_role' entity should not extend core's 'role' Active

This port has been moved to it's own project: https://www.drupal.org/project/og_access →
Please use that if you need this functionality that was provided in D7.

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

This is looking really good so far and passing tests.

On admin/config/group/roles/node/committee_project/add

I ran into this which @damienmckenna ran into here also https://github.com/Gizra/og/pull/243#issuecomment-2085728265

The website encountered an unexpected error. Try again later.

Drupal\Core\Entity\Exception\UndefinedLinkTemplateException: No link template 'canonical' found for the 'og_role' entity type in Drupal\Core\Entity\EntityBase->toUrl() (line 211 of core/lib/Drupal/Core/Entity/EntityBase.php).

Drupal\Core\Config\Entity\ConfigEntityBase->toUrl() (Line: 259)
Drupal\Core\Entity\EntityBase->toLink() (Line: 105)
Drupal\og_ui\Form\OgRoleForm->save()
call_user_func_array() (Line: 129)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers() (Line: 67)
Drupal\Core\Form\FormSubmitter->doSubmitForm() (Line: 597)
Drupal\Core\Form\FormBuilder->processForm() (Line: 326)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult() (Line: 39)
Drupal\layout_builder\Controller\LayoutBuilderHtmlEntityFormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 741)
Drupal\Core\DrupalKernel->handle() (Line: 19)

@claudiu.cristea I agree that moving this to a separate module in the OG ecosystem could streamline development and help with maintenance over time. Keeping it distinct would likely simplify its evolution without adding further load to OG itself.

My initial testing of the port was promising as-is, given that it’s a direct port, but I see the value of exploring the Access Policy API. Perhaps for a 1.0 release, we could keep it node-centric as originally designed, then immediately open a 2.x branch to explore re-architecting it with Access Policy API integration. This way, we can establish a stable base while paving the way for more flexible group context handling.

As for the scope, you’re right; the current solution focuses solely on nodes, consistent with the D7 implementation. Expanding to support additional entity types as groups or group content would indeed be beneficial as we move forward, though again I would recommend doing so in a 2.x branch of the separated module.

joelpittet → created an issue.

This is a duplicate of the code I merged here 🐛 "The default OG membership type cannot be deleted" on uninstall RTBC

joelpittet → created an issue.

@claudiu.cristea Totally agree, I didn't evaluate those, just copied it over. I'll make make a different plan for stable release.

claudiu.cristea → credited joelpittet → .

Thanks I tweaked and merged this quick fix, seems reasonable assumption

Clone the og membership view and filter and aggregate to your hearts content:
https://d10.test/admin/structure/views/view/og_members_overview

This module has tests, that is the best place to see how adding users to groups programmatically can and should be done.

There is a trait even for creating membership:
https://git.drupalcode.org/project/og/-/blob/8.x-1.x/tests/src/Traits/Og...

That sounds like that is because of og_access not being ported and that field not being there, not specific I think. I will close that as a duplicate of 📌 OG Access port Active and you can try that out to see if it helps?

This exists here:
https://www.drupal.org/docs/comparison-of-contributed-modules/comparison... →

and a bit here too:
https://www.gizra.com/content/og-message-stack-drupal8/#group-module

Sounds like you fixed your problem, I will close this to clean up the queue

I am closing this as a duplicate of 📌 OG Access port Active Please see the merge request to add the og_access submodule.

Adding labels as tags and adding @gordon

This was fixed in c8c303b9ba9ae86e78fba2e7217f6485d5687256, and thanks to @claudiu.cristea we are back in drupal.org git.

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

joelpittet → created an issue.

Thanks for this MR, it was fixed in a different issue.

They need a maintainer it looks like. Feel free to offer to maintain this @maxilein

Might want D11 in this too but it's better than the broken state it's currently in. Check this out it's somehow confused with adoption_navbar:

❯ composer info -a drupal/tracker
name     : drupal/tracker
descrip. : Enables tracking of recent content for users.
keywords :
versions : 1.0.x-dev, dev-1.0.x
type     : metapackage
license  : GNU General Public License v2.0 or later (GPL-2.0-or-later) (OSI approved) https://spdx.org/licenses/GPL-2.0-or-later.html#licenseText
homepage : https://www.drupal.org/project/adoption_navbar
source   : []
dist     : []
names    : drupal/tracker

support
source : https://git.drupalcode.org/project/adoption_navbar

requires
drupal/adoption_navbar ^1
drupal/core ^8

RTBC++

@smustgrave, I don't have a fix but the tests do demo the problem.

Updated the issue summary to help make this clearer

@joseph.olstad you are now maintainer, welcome aboard!

This affects themes like https://www.drupal.org/project/basic → which I would like to be a starterkit theme.

Breaking that out with the Issue Summary example:

$patterns = [
  'old' => [
    'machine_name' => 'galactus',
    'machine_name_camel' => 'galactus',
    'machine_name_pascal' => 'Galactus',
    'machine_name_title' => 'Galactus',
    'label' => 'Galactus',
    'label_camel' => 'galactus',
    'label_pascal' => 'Galactus',
    'label_title' => 'Galactus',
  ],
  'new' => [
    'machine_name' => 'galactus_ta',
    'machine_name_camel' => 'galactusTa',
    'machine_name_pascal' => 'GalactusTa',
    'machine_name_title' => 'Galactus_ta',
    'label' => 'galactus_ta',
    'label_camel' => 'galactusTa',
    'label_pascal' => 'GalactusTa',
    'label_title' => 'Galactus_ta',
  ],
];
$filename = str_replace($patterns['old'], $patterns['new'], $old_filename);

Why does it always add TaTa_ to the new $filename in these examples
$old_filename = 'galactus.settings.yml'
$filename = 'galactusTaTa_ta.settings.yml'
$old_filename = 'block.block.galactus_mainpagecontent.yml'
$filename = 'block.block.galactusTaTa_ta_mainpagecontent.yml'
$old_filename = 'block.block.galactus_pagetitle.yml'
$filename = 'block.block.galactusTaTa_ta_pagetitle.yml'
$old_filename = 'block.block.galactus_tabs.yml'
$filename = 'block.block.galactusTaTa_ta_tabs.yml'
$old_filename = 'block.block.galactus_primaryadminactions.yml'
$filename = 'block.block.galactusTaTa_ta_primaryadminactions.yml'
$old_filename = 'block.block.galactus_main_menu.yml'
$filename = 'block.block.galactusTaTa_ta_main_menu.yml'
$old_filename = 'block.block.galactus_breadcrumbs.yml'
$filename = 'block.block.galactusTaTa_ta_breadcrumbs.yml'
$old_filename = 'block.block.galactus_help.yml'
$filename = 'block.block.galactusTaTa_ta_help.yml'
$old_filename = 'block.block.galactus_drawer.yml'
$filename = 'block.block.galactusTaTa_ta_drawer.yml'
$old_filename = 'galactus.schema.yml'
$filename = 'galactusTaTa_ta.schema.yml'
$old_filename = 'galactus.theme'
$filename = 'galactusTaTa_ta.theme'
$old_filename = 'galactus.libraries.yml'
$filename = 'galactusTaTa_ta.libraries.yml'
$old_filename = 'galactus.breakpoints.yml'
$filename = 'galactusTaTa_ta.breakpoints.yml'
$old_filename = 'galactus.info.yml'
$filename = 'galactusTaTa_ta.info.yml'

It applies to more than just files, it's only that this is easy to represent.

Still working on a solution but it would be nice to know why so many variations for the replacements were needed in the first place.

I'm narrowing down on 📌 Making a theme compatible with core's theme generator is too difficult Needs work

Where this code was introduced in GenerateTheme:

  private static function namePatterns(string $machine_name, string $label): array {
    return [
      'machine_name' => $machine_name,
      'machine_name_camel' => u($machine_name)->camel(),
      'machine_name_pascal' => u($machine_name)->camel()->title(),
      'machine_name_title' => u($machine_name)->title(),
      'label' => $label,
      'label_camel' => u($label)->camel(),
      'label_pascal' => u($label)->camel()->title(),
      'label_title' => u($label)->title(),
    ];
  }

Flying in to do a test. Red/green test-only/test-with-patch seem to be doing the trick.

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

joelpittet → created an issue.

Have a look over here in this issue:

https://www.drupal.org/project/drupal/issues/3473195  → There are some workarounds until it's released

benjifisher → credited joelpittet → .

Yes this helped, thank you both

quietone → credited joelpittet → .