🇺🇸United States @skyriter

skyriter → created an issue.

skyriter → created an issue.

@johnv, we filter on the workflow state itself, rather than the transition.

skyriter → created an issue.

Good point. I can just call my node creation function in the gatherItemsToProcess() before I go and get those just created nodes.

swirt → credited skyriter → .

skyriter → created an issue.

skyriter → created an issue.

swirt → credited skyriter → .

skyriter → created an issue.

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

tekNorah → credited skyriter → .

Those steps are now here in this issue. This should be ready once more to be reviewed.

Compared in a visual diff tool both the Safari and Chrome output, and it was the same.

I'm continuing with this work. Whereas yesterday, I added a -webkit-drop-shadow to maintain Safari UI parity with Chrome and Firefox, I realized that the type of shape we are putting the shadow on was a rectangle and cshould be visually identical with box-shadow, which Safari supports. So I'm going to update the code accordingly.

@marky was mentoring at my table and helped me in my first time contribution.

Could someone take a look at this when they have a moment?

I added this merge request during the Portland DrupalCon 2024 Contribution day.

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

I added some of those changes here:
https://git.drupalcode.org/project/codit_batch_operations/-/merge_reques...

skyriter → created an issue.

Even though I agree we've ruled out logging, the slowdown is still a legitimate phenomenon, at least when running the script on my content. I suspect this will be experienced by others with mature platforms. I would like to keep this ticket open to investigate a possible mitigation.

If it turns out that some combination of sleep() and resume after a certain number of items achieves the desired effect of shortening the overall execution time significantly, we could add a feature request issue to add config in the UI to pause at after a certain number of items and set the length of the pause. We could even provide some guidance while leaving the option as an advanced setting, perhaps.

After more research into the codit_batch_operations script behavior and that of a similar previously-written custom script that does the same thing, I have to concur. I see no evidence that it has anything to do with logging. Based on conversations @swirt and I have had privately, I'm convinced by his initial supposition that it was about other processes associated with saving the nodes that begin to stack up.

Because we are pushing changed data to a queue to send to an api, we found that a source of significant slowdown a deduplication process to make sure to we don't add duplicate data to the queue. Turning off that process, which we have in a config form on our site, made a huge difference.

Running this locally in DDEV, before I had the deduping turned off, I was getting the following performance as the script processed ~16,000 items (broken out during certain percentage bands of completeness):

• 4 - 5%: 5:11 minutes (at around 30 row/min)
• 7 - 8%: 7:02 minutes (at around 25 row/min)
• 8 - 9%: 7:19 minutes (at around 25 row/min)
• 8 - 10%: 8:28 minutes (at around 17 row/min)

After I turned off deduping, I saw this performance:

• 38 - 39%: 1:00 minute
• 39 - 40%: 1:00 minute
• 40 - 41%: 1:00 minute
• 61 - 62%: 1:45 minutes
• 62 - 63%: 1:49 minutes

Not, that we're still seeing a slowdown, but not nearly as extreme. The changed content is still being added to our queue to push to an api, as it would in production. If we didn't have content that did so, we would probably see better performance.

When I try to rerun it, the codit code returns a message to delete the running instance first, so I did that.

But the time I ran it after the rebuild of the environment, I did not rerun it. It slowed down, nevertheless.

skyriter → created an issue.

Released with https://www.drupal.org/project/codit_batch_operations/releases/1.0.1-beta5 →

skyriter → created an issue.

Another option would be to have getNidsOfType() accept a prefix argument, which could be the <bundle_type> or anything else.

skyriter → created an issue.

Thanks for this and all your help, Steve.

swirt → credited skyriter → .

I was just looking through this and wanted to note that with Drupal 8 having reached EOL, this patch should no longer have to do a version check.

I was wondering why the Access policy API is not in alphabetical order. Was that intentional?

swirt → credited skyriter → .

swirt → credited skyriter → .

I fully endorse Norah, knowing her to be a supportive and effective Drupal community member for years with many code and organizational contributions.

For some context, I created a site on Simplytest.me with the following modules installed and enabled
- office_hours@1.17.0
- clientside_validation@4.0.2
- clientside_validation_jquery@4.0.2

I used the default configuration.

While entering the hour range, the site threw this error when going from the "To" to the "From" field.

Terrific. Thank you!

johnv, do you know when a new release will be created?

Thank you for your quick response and action, johnh. We use this module in many of our content types and paragraphs at the VA. Would you mind granting me credit for my involvement on this issue?

swirt → credited skyriter → .

I moved this to Needs Review after making my MR.

I noticed that this failed the test pipeline. I think it's because config/schema/office_hours.schema.yml was not updated to include "show_empty".

#10 worked for me, but the other patch → did not.

After discussion with other developers on the project, I opted to not completely replace the help text but to concatenate it, both to have consistency with the help test across all Linkit widgets and to minimally affect existing fields.

swirt → credited skyriter → .

swirt → credited skyriter → .

skyriter → created an issue.

swirt → credited skyriter → .

skyriter → created an issue.

skyriter → created an issue.

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

skyriter → created an issue. See original summary → .

The records with a null field that had been failing previously are passing once again during migration.

I have run multiple migrations successfully with this patch in my local development environment.

Um, please disregard.
A co-worker noticed my typo

class TsField extends ProcessPluginBase {

not

class TzField extends ProcessPluginBase {

skyriter → created an issue.

I just tested the patch in our PR environment. The URLs are no longer truncated and are thus visually distinguishable from each other.

I tested this, and it's working in my environment.