Zotero 7 not auto changing title of PDF with metadata rename...

edward.henry

One of the bugs I'm seeing in Zotero 7 is that the title of a document will not be renamed from parent metadata when the name of the file is renamed from parent metadata. One has to copy and paste the filename to change the title of the PDF. In Zotero 6 the title of the PDF was automatically changed when the title of the PDF was extracted from the metadata. See image with red arrows for example post-metadata extraction of filename.

The Zotero 6 auto-change saved some time. Can we get this back?

https://s3.amazonaws.com/zotero.org/images/forums/u1122284/yjrnjrqs7fps6zq88qwc.png

dstillman

https://www.zotero.org/support/kb/attachment_title_vs_filename

thejoemaya

Facing the same

poettli

@thejoemaya Same answer as above

aborel

In other words, for people who don't follow the links given as answers: Zotero not changing the attachment title to the same value as the file name is the intended behavior.
I for one was surprised at first, but now I really agree with the developers. I used to prefer a more meaningful attachment title, but I have realized that its main consequence for me was to cause a duplication of search results without adding any real value.

poettli

I was also surprised when this change first appeared in the betas. But most of the time, I even don't expand the item, because I have all the information I need in the main window and in the item pane. I just need to double-click to open the associated pdf.

AidaMSmith

When I manually select the "Rename file from parent Metadata" option on a PDF, I'd like to see the renamed file displaced within in Zotero as well as in Zotero 6. Am I missing something?

I'd also like the file auto rename feature back.

scotto

I remember that zotero devs considered an option to make the attachment title the same as the attachment filename, but that was a long time ago -- is that feature still going to be implemented? I'm hoping for it, and here's why.

After upgrading to zotero 7, I realized that my workflow had a hard dependence upon the attachment title being the same as the basename in the attachment file path.

First, I'm running zotero on several computers, some windows and some MacOS, and on each, I need to connect to a single, common, shared pdf folder, which is mounted below a tree outside of the zotero file structure. This is unique to whatever shared computer I'm using at the time. To make this work, I pointed to the machine-specific shared pdf folder using Zotero's "Linked Attachment Base Directory" setting, and I also used zotfile, which always made the attachment title == the basename. Of course, zotfile doesn't work on zotero 7.

Second, I use Obsidian's "zotero integration" plugin to create literature notes. Since the zotero API sets attachment.path to the full path (usually wrong for the computer I happen to be running on), I got the attachment basename from the zotero 6 attachment title. This made it tractable to reach the right file, under wherever "Linked Attachment Base Directory" happened to be on a given machine.

After I updated to zotero 7, I tinkered for hours with obsidian "zotero integration" plugin templates, trying to extract a basename from attachment.path. But I haven't found a reliable method using the rudimentary nunjucks template language.

So that's my use case for title == filename. I'm sure that others who want that capability back have similarly hairy setups, or maybe even harrier.

tim820

@scotto for Zotfile linked file functionality in Zotero v7, use zotmoov or attanger.

I have not tested all the move/rename functions for both those plugins, but I do know that zotmoov matches the title to the filename (renamed according to v7 rules) like Zotfile did, for *newly downloaded attachment files* (eg via the Zotero connector).

There is currently a zotmoov issue for replicating Zotfile's right-click Rename&Move on *existing* linked files. That zotmoov operation does not currently change the title/filename if the file is not being moved (ie if its current location and the 'move to' folder are the same). Zotfile did do that, and it was how many people renamed existing linked files; and it also matched the title to the filename. However that zotmoov issue is tagged to be fixed soon. So that would allow you to match the title and filename on existing linked files.
https://github.com/wileyyugioh/zotmoov/issues/56
I am not sure what attanger does in the same situation.

If you are still using linked files under v7, your Linked Attachment Base Directory setting *on each computer* will tell you where Zotero has been set to *look* for linked files (eg when you ask it to open a PDF). The LABD setting has no effect on where such files get stored. So whether those linked files are actually *at* the LABD folder location depends on whether you or a plugin (zotfile/zotmoov/attanger) put them there.

scotto

@tim820, Thanks! I just tried out zotmoov, and it's a good start -- I'll watch for progress on the bug you pointed out.

I also noticed, though, that html snapshot files aren't renamed when first downloaded, but maybe that's a function of zotero itself, which in its renaming settings, has no tickbox for .html. (I made a zotero topic on html renaming)

The zotmoov "allowed file extensions" do include .html so you'd think that, when its "automatically move/copy files when added" setting is turned on, then html files would be renamed and the title matched. In this case, files really are moved (I made a zotmoov .html renaming issue)

tim820

@scotto some aspects of zotmoov's handling of html files have previously been discussed - see issue below. I believe it does now work correctly for right-click move/rename from local Zotero storage to the linked file storage folder (including updating Zotero's location data for the file). But maybe not for newly downloaded/attached html snapshots if that's what you found ?
https://github.com/wileyyugioh/zotmoov/issues/33

Incidentally, I did recently find that I could move/rename html files to linked files with Zotfile's Rename&Move (in Zotero 6), if html is in its extensions list (which I hadn't realized was possible before).

scotto

@tim820, good to know. Thanks, I'll watch that bug too.