🇩🇰Denmark @ras-ben

ras-ben → created an issue.

I think your comments are excellent @pfrenssen, but I dont know if I'll have the time this month to look into fixing them - so, if anyone has the time and expertise, you are very welcome :)

Alright, so, it turns out that changing from 12h to 24h causes a sea of trouble. Sadly.

I've closed the other pull request, and opened a new, that simplifies things:

Instead, I just made sure that the settings form for EventSeries uses a date field, rather than a text field.

This way, an editor cannot input an invalid format, which was my original problem:

https://git.drupalcode.org/project/recurring_events/-/merge_requests/112

Also adding patch for merge request 64:

https://git.drupalcode.org/project/simple_oauth/-/merge_requests/64.patch

Adding patch file, for use in composer.json.
It is made from https://git.drupalcode.org/project/simple_oauth/-/merge_requests/66.patch

ras-ben → created an issue.

ras-ben → created an issue.

ras-ben → created an issue.

ras-ben → created an issue.

ras-ben → created an issue.

ras-ben → created an issue.

After digging, I realized it's cause the field_inheritance module only has a single, very broad permission.

Here's a patch:

https://www.drupal.org/project/field_inheritance/issues/3454350 📌 Create seperate permission for adding field inheritance Active

ras-ben → created an issue.

This appears to still be an issue.

A (very ugly) work around, that i added in a custom updatehook:

  $entity_type = 'eventinstance';

  $field_storage_definition = BaseFieldDefinition::create('string')
    ->setName('title')
    ->setLabel(t('Mock-title field'))
    ->setDescription(t('This is a mock title field, unused and read only. It is required, for eventinstances to work with entity reference autocomplete fields.'))
    ->setReadOnly(TRUE)
    ->setRevisionable(FALSE);

  \Drupal::entityDefinitionUpdateManager()
    ->installFieldStorageDefinition('title', $entity_type, $entity_type, $field_storage_definition);

  return "Mock title field has been added to the $entity_type entity.";

This is pretty hilarious - I opened this ticket 2.5 years ago, and today I decided to fix it and make a patch - and then 10 days earlier someone else has made it
Jesus 😅 - either way, here's my patch. I think the other one might be cleaner though!

A review comment:

if ($moderation_state = $node->get('moderation_state')->getString()) {

What if the node doesnt have 'moderation_state'? Then, you'll be doing ->getString() on null.

And, in addition to that, I've also added this deploy hook to run **AFTER** the patch has been removed.
Again - use at your own risk, but it seems to work well for me.

/**
 * Update invalid entity updates.
 */
function MY_MODULE_deploy_entity_updates() {
  $entity_type_manager = \Drupal::entityTypeManager();
  $entity_type_manager->clearCachedDefinitions();

  $entity_type_ids = [];
  $change_summary = \Drupal::service('entity.definition_update_manager')->getChangeSummary();
  foreach ($change_summary as $entity_type_id => $change_list) {
    $entity_type = $entity_type_manager->getDefinition($entity_type_id);
    \Drupal::entityDefinitionUpdateManager()->installEntityType($entity_type);

    $entity_type_ids[] = $entity_type_id;
  }

  drupal_flush_all_caches();

  return t("Installed/Updated the entity type(s): @entity_type_ids", [
    '@entity_type_ids' => implode(', ', $entity_type_ids),
  ]);
}

In addition to #293, I found out that I didnt have the correct table structure afterwards.
It seemed to cause issues with views that had groups relationship.

Here is the expanded deploy hook, that *seems* to work better - but, please, use it at your own risk :)

/**
 * Alter the database, to not have broken Groups module config.
 *
 * In the past, we used the group_entityqueue module on the site, however that
 * has later been removed as it was not necessary. In order to get
 * group_entityqueue to work, we needed to include a patch for groups:
 * https://www.drupal.org/files/issues/2021-08-24/2797793-279.patch
 * https://www.drupal.org/project/group/issues/2797793.
 *
 * This patch basically refactored groups, to save group content IDs as strings
 * instead of ints. This causes an ungodly amount of trouble with updating to
 * groups 2.x / getting groups 1.x ready for D10.
 * The problem now is that we cannot just remove the patch, as it didnt include
 * any uninstall hooks (or, atleast not any that works). If we just remove
 * the patch, Drupal will refuse to do anything, including CR and UPDB.
 * So, before removing the patch, we need to undo the mess that it has left
 * in the database. We'll port the data back to group_content_field_data, and
 * remove the entity_id_str references.<em></em>
 */
function MY_MODULE_deploy_fix_groups_db() {
  $database = \Drupal::database();

  // We need to re-add the entity_id column to group_content_field_data.
  // Get data from the table that the patch added ('group_content__entity_id').
  $database->query("ALTER TABLE group_content_field_data ADD entity_id INT(11);");
  $database->query("
    UPDATE group_content_field_data
    JOIN group_content__entity_id ON group_content_field_data.id = group_content__entity_id.entity_id
    SET group_content_field_data.entity_id = group_content__entity_id.entity_id_target_id;
  ");

  // Make sure the entity_id column has the correct index keys and properties.
  $database->query("
    ALTER TABLE `group_content_field_data`
    MODIFY COLUMN `entity_id` int(10) unsigned DEFAULT NULL COMMENT 'The ID of the target entity.',
    DROP INDEX IF EXISTS `group_content_field__entity_id__target_id`,
    ADD INDEX `group_content_field__entity_id__target_id` (`entity_id`),
    DROP INDEX IF EXISTS `group_content__entity_fields`,
    ADD INDEX `group_content__entity_fields` (`type`,`entity_id`);
  ");

  // Now, we can remove all the messed up config, from the old field.
  $database->query("DELETE FROM key_value WHERE name='group_content.field_schema_data.entity_id_str';");
  $database->query("DROP TABLE group_content__entity_id_str;");

  // If we don't delete the whole field_storage_definition, we run into errors,
  // when we remove the patch.
  $database->query("DELETE FROM key_value WHERE name='group_content.field_storage_definitions';");

  // Alternatively to removing the whole field storage definition, I'd prefer
  // to just remove the reference to entity_id_str, but I couldnt get that
  // to work.
  /** @var \Drupal\Core\KeyValueStore\DatabaseStorage $key_value */
  /*
    $key_value = \Drupal::service('keyvalue')->get('entity.definitions.installed');
    $group_field_defs_key = 'group_content.field_storage_definitions';
    $group_field_defs = $key_value->get($group_field_defs_key);
    unset($group_field_defs['entity_id_str']);
    $key_value->set($group_field_defs_key, $group_field_defs);
  */
}

In addition to #290 - I've had better luck with this:

/**
 * Alter the database, to not have broken Groups module config.
 *
 * In the past, we used the group_entityqueue module on the site, however that
 * has later been removed as it was not necessary. In order to get
 * group_entityqueue to work, we needed to include a patch for groups:
 * https://www.drupal.org/files/issues/2021-08-24/2797793-279.patch
 * https://www.drupal.org/project/group/issues/2797793.
 *
 * This patch basically refactored groups, to save group content IDs as strings
 * instead of ints. This causes an ungodly amount of trouble with updating to
 * groups 2.x / getting groups 1.x ready for D10.
 * The problem now is that we cannot just remove the patch, as it didnt include
 * any uninstall hooks (or, atleast not any that works). If we just remove
 * the patch, Drupal will refuse to do anything, including CR and UPDB.
 * So, before removing the patch, we need to undo the mess that it has left
 * in the database. We'll port the data back to group_content_field_data, and
 * remove the entity_id_str references.
 */
function bupl_departments_deploy_fix_groups_db() {
  $database = \Drupal::database();

  // We need to re-add the entity_id column to group_content_field_data.
  // Get data from the table that the patch added ('group_content__entity_id').
  $database->query("ALTER TABLE group_content_field_data ADD entity_id INT(11);");
  $database->query("
    UPDATE group_content_field_data
    JOIN group_content__entity_id ON group_content_field_data.id = group_content__entity_id.entity_id
    SET group_content_field_data.entity_id = group_content__entity_id.entity_id_target_id;
  ");

  // Now, we can remove all the messed up config, from the old field.
  $database->query("DELETE FROM key_value WHERE name='group_content.field_schema_data.entity_id_str';");
  $database->query("DROP TABLE group_content__entity_id_str;");
  $database->query("DELETE FROM key_value WHERE name='group_content.field_storage_definitions';");
}

Right, but what would the use case for that be in a template?
It seems overkill to send the data along for no reason, and using a hook in the process

Sorry for the slow reply, Beunerd.

You have a good point, in regards to view mode. However, I think it should most definetely be a "opt in" view mode, as otherwise, there's a massive performance issue.

In regards to the anonymous-user-avoid-bla-bla - yes - you're right, and my comment was irrelevant.

@beunerd apologies for the slow reply on the other ticket. I dont know why it's flown over my head.

It's quite many months since i created this patch, so i'm trying to remember - but, from reading my comment, it appears that I've missed that there's a second variable being set.

The variable i did notice - latest_revision_state - was not being used for anything, when I searched in the code.
That's why I called it fully redundant.

However, when I look in the code, it appears that "current_revision_state" is the same - it's being set, but not being used anywhere. Am i wrong?

Let's continue the discussion on full/viewmode in the other ticket :) https://www.drupal.org/project/workflow_buttons/issues/3328538 🐛 workflow_buttons should only be loaded/load edit form when relevant Fixed

Ah! That makes more sense.

So, I should just remove the version line all together.
Is this workaround documented anywhere, apart from here? It's pretty vital information :)

So, now that the patch has been added, does that mean we can get around the issue by adding

"version: -1" in the .libraries.yml file?

For example:

base:
  version: -1
  css:
    theme:
      dist/css/tipi.bundle.css: {}
      dist/css/tipi.print.css: {}
  dependencies:
    - core/drupal

and then it will re-aggreg on cache clear?

@yojohnyo Yes and no..

I've been able to finally remove the patch, after running these SQL commands first:

ALTER TABLE group_content_field_data ADD entity_id INT(11);
DELETE FROM key_value WHERE name='group_content.field_schema_data.entity_id_str';
DROP TABLE group_content__entity_id_str;
DELETE FROM key_value WHERE name='group_content.field_storage_definitions';

BUT BARE IN MIND - These are destructive commands! I have not tested fully, and I'm not sure yet if this causes new issues.

LGTM.

Can we please get this into a release ASAP? :)

Drupal 9 has EOL in a few months.

@SocialNicheGuru

But, even if i add that module, when i remove the patch, i still get the error ^

ras-ben → created an issue.