🇺🇸United States @glassb

I think I got it working with daily, weekly, monthly, and yearly schedule frequencies.

I'm not sure if I'm doing this correctly, but my changes are dependent on 🐛 Fix Scheduled Hour Time Zone Conversion Active and 🐛 Third party settings are migrated to the state in a wrong way Active so I'm marking this issue Postponed until they have been accepted and merged.

After looking into this more, I think it would be more manageable to accomplish the time zone conversions using Drupal\Core\Datetime\DrupalDateTime. I've committed the necessary changes to MR4.

glassb → created an issue.

glassb → created an issue.

Please see MR!2 for review.

In addition to removing the use of third party settings and moving migration to an update hook, I noticed there was an issue with the last timestamp never being set in the State API. As a result, the condition always used the scheduled time on the following day and would never send emails. This should be fixed in the MR.

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

I tested on a fresh site with MR !7 and didn't have any issues.

Steps Taken:

1. Install fresh Drupal 10.3.1 site
2. Composer require Views Entity Embed module
3. Apply MR !7
4. Enable Views Entity Embed
5. Add Views button to text format
6. Enable Display embedded views and Display embedded entities for text format
7. Create node with embedded View

I wasn't able to reproduce the issue described in #32. Can you test again and see if you notice the same issue?

I tested MR !17 on a site running 10.1.8 with content moderation, but I found that duplicate profiles were still being created. After some debugging, it looks like it is making it to

if ($profile_exists) {
      $this->context->buildViolation($constraint->errorMessage)
        ->atPath('uid')
        ->addViolation();
    }

and $profile_exists does evaluate as true when expected. I'm not familiar with Symfony constraints, but it seems like once the violation is raised it should prevent the submission. I tried looking into it, but it looks correct as far as I can tell.

For now, #2 patch does seem to work for me.

I've tested on a local development site and can confirm that MR 1 fixes the issue.

pstewart → credited glassb → .

I was able to apply MR87 to one of our test sites and everything seems to be working as expected. I can confirm the wid column was successfully changed from int to bigint in the database and all of the data seems to have been copied over correctly.

I also tested how the table lock would handle other traffic during the update by:

1. Adding a 5 minute delay after the schema lock with $this->connection->queryDirect("WAITFOR DELAY '00:05:00'");.
2. Running drush updatedb.
3. Performing operations on the site that would generate logs.
4. Running a select query in SSMS.
5. Checking resulting logs after updates were complete.

I found that while the database updates were running, the site would continually load on any requests that would generate logs. Afterwards, all of the logs generated during that update were shown in the new table. I was also unable to query the table during the updates. This suggests to me that the table lock is functioning as expected and preventing any inserts until after the update is complete.

Everything seems to be functioning correctly so I believe this is ready to be marked RTBC. Hopefully we can get a release candidate out soon. Thanks to everyone who worked on this issue!