FWIW The patch in #4 did not work when tested on 2.0.3.
I did eventually find that https://www.drupal.org/project/views_ajax_history → was able to solve for the use case here. With that you can toggle a setting under Ajax in Views and see page parameters display in the URL.
Alternative, easier paths opened in the time since I made the initial post.
I ended up redoing the entire import with File-Field to Media-Field and got significantly better results, especially with image alt tags and titles. I would recommend looking into it for your use:
FWIW somebodysysop, I had a similar issue. On Used not managed I got:
Drupal\Core\Entity\Exception\UndefinedLinkTemplateException: No link template 'canonical' found for the 'paragraph' entity type in Drupal\Core\Entity\EntityBase->toUrl() (line 211 of core/lib/Drupal/Core/Entity/EntityBase.php).
This is how I troubleshooted:
- Spun up an isolated dev site
- Visited Used not managed page, saw the error
- Deleted all Paragraphs
- Got a clean page load for Used not managed
- Restored DB
- Deleted groups of Paragraphs at a time until I got a clean page load on Used not managed.
- Repeated until it became clear just one Paragraph was the culprit - even though it rendered fine as content.
- Deleted that one Paragraph, rebuilt it, and now I see the report from Used not managed.
This persists and is reproduced in 2.1.3 testing in Drupal 11.2 dev. It seems like this issue is related to the setting Import files to location set in media.
If Import files to location set in media = true
when I run Media Import multiple times
then files are moved to the image media type directory
no duplicates are created for files.
I can repeatedly run the Media Library importer and everything works as expected. 1 record in Files, 1 Media entity. No duplicates on successive imports.
However...
If Import files to location set in media = false
when I run Media Import multiple times
then file ID duplicates are created each time the importer runs
and each instance of the duplicate gets its own ID
and each instance is pointing to the same source file.
I don't think this is an issue with the Files View itself. The view is just showing what is in files_managed. Each and every time the Importer runs, a new record is added to files_managed. Media isn't modified in this example. The hard part to work around is that all the duplicate managed records point to a single file, so deleting any record results in deleting the source file, and thus also breaking the media entity using that file.
In both cases, Media never gets duplicated. "You can run import as many times as you like. Once created, media entities will not be duplicated." is true. Unfortunately, if keeping existing files in place, Files lists and views around the site gets quickly overwhelming with incorrect records - especially if this is tied in with a cron job.
Issue persists in 2.1.1
In your configuration at admin/config/media/media-library-importer
What path do you have for Import from folder?
What's the setting of "Exclude media image "styles" folder"?
What's the setting of "Import files to location set in media"?
Like others here, removing a space before <?php in a settings.local.php resolved this for me.
I had no problems on 10.1, 10.2, or 10.3. On 10.3.1 now, php 8.3.
The patch in #8 works for me using Audit Files 4.1.0-beta2 in Drupal 10.3, PHP 8.3.8, nginx 1.25.4, MySQL 8.3.0
nateB → changed the visibility of the branch 3417201-4.1.x to active.
nateB → changed the visibility of the branch 3417201-merge-references-exception to active.
nateB → changed the visibility of the branch 3417201-4.1.x to hidden.
nateB → changed the visibility of the branch 3417201-merge-references-exception to hidden.
nateB → changed the visibility of the branch 3417201-merge-references-exception to hidden.
nateB → changed the visibility of the branch 3417201-merge-references-exception to hidden.
nateB → created an issue.
For other people who may find this page searching for similar issues with site archiving through drush, it does appear that the commands were restored as of Drush 11.1.1 and yet errors persist for drush ard in some circumstances.
I was getting: Exit Code: 127(Command not found)
I "fixed" this by reinstalling Composer through Homebrew. I'd previously installed it manually and aliased through .zshrc. I saw from reading about similar errors that aliasing was frequently connected to command not found problems, so rather than dig in to the problem, I tried the first fast alternative I could think of: brew install composer, which historically caused more problems than it solved but seems to be OK now. (Had to add mysqldump as well, which was later called through a successful drush ard.)
Then I got: Invalid working directory specified, /Users/nateB/Websites/Drupal does not exist.
Which was because there was a space in the actual folder name, Drupal 10, which wasn't being escaped (Drupal\ 10). It would seem drush ard command doesn't handle spaces in a working directory path. I changed the folder name to get around this, ran the command, then got my archive as expected.
No doubt there may be more precise, forward-thinking ways to handle these issues, but maybe this comment will help someone else.
e.bogatyrev's change at https://git.drupalcode.org/project/auditfiles/-/merge_requests/21/diffs resolves my issues with Used Not Referenced report returning the No link template... error for paragraphs.
Audit Files 4.2.x-dev | Drupal 10.2.6 | PHP 8.2.16
I've gone through the same thing, in my case for 8.7.6. I found that drupal/recommended-project, drupal/core-recommended and drupal/legacy-project only go back to around 8.8.0. It would seem that despite the instructions on the
older 8.x version pages →
like
composer create-project drupal/recommended-project:8.7.14 "install-dir"
they're all simply of date. There's just no there there at drupal/recommended-project or the others. 8.8.0-alpha1 is the oldest available through those. It's ridiculous, but not surprising, that Drupal documentation is so far off.
The advice in previous comments to download the tarball of the version you need is OK. That "trash" post has reasonable direction. It took less that a minute from download to /install.php load to test successfully. The error message you're reporting suggests an incompatible PHP version. What are you using? I used PHP 7.2, MySQL 5.7, NGINX 1.25 (and Composer 1.10.26) to install 8.7.14.
If you can't test on your server, try something like Indigo or MAMP to test locally.
After you get setup, you can modify the composer.json to your project. FWIW, if you upgrade to +8.8.x you can use those aforementioned projects to clean up your install. It looks like Composer has been in use since 8.0, but project templates came around at 8.8.0 → .
@Grevil
Wondering if you can provide more context around "5 commits behind" in regards to what was current at the time of your post.
Was the patch meant to be applied to branch from Jan 2023? I've applied patch-22 to the (apparently current) 1.0.x-dev branch from 3 Jan 2023. Patching succeeds, but module fails in use:
[error] TypeError: array_search(): Argument #2 ($haystack) must be of type array, null given in array_search() (line 124 of .../web/modules/contrib/filefield_to_mediafield/src/FileToMedia.php) #0 .../web/modules/contrib/filefield_to_mediafield/src/FileToMedia.php(124): array_search('5306cdc328dbe0c...', NULL)
+1. Also interested in seeing this come to be. From the screenshot alone, it appears to be far more accessible than other image-to-media solutions currently available.