Problem/Motivation

I'd like to be able to have the check_on_upload setting enabled, but not have pdfa11y be scanning during a migration that creates media. Any kind of exception thrown or parsing slows down the migration significantly.

Ideally we would queue those items to be scanned.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Issue fork pdfa11y-3595626

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

dave reid created an issue. See original summary.

dave reid opened merge request !24

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Status: Active » Needs review

joshuami made their first commit to this issue’s fork.

joshuami’s picture

joshuami
he/him
Primary language English
Location Portland, OR
commented
Status: Needs review » Postponed (maintainer needs more info)

This looks great and makes a ton of sense. Question though, what would you think of moving this to below the PDF check so that the only queued checks would be for actual PDFs?

<pre>
    $uri = $file->getFileUri();
    if (!str_ends_with(strtolower($uri), '.pdf')) {
      return;
    }
</pre>

That's at line 144.

I'd love to get this into the next release as it might be a blocker to some bigger projects using it alongside migrations.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

I wanted to short circuit and make it as quick as possible without having to do more loading. I think the queue worker also does the same check too, so it felt safe to defer in order to minimally add more time to a migration.

joshuami’s picture

joshuami
he/him
Primary language English
Location Portland, OR
commented
Status: Postponed (maintainer needs more info) » Fixed

Fair. It's low cost either way, so I trust your judgement. Merging. It will go in the next release, which I'm hoping to cut in the next day or two.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.