* ATTN Users of Mike Tate's "Order Facts by Sort Date" plugin

[ColeValleyGirl]

If you open a project where you've used the 'Order Facts by Sort Date' plugin in the latest version of FH7 (7.0.1.2) you'll be told you have some media-handling issues:

Screenshot 2021-01-23 095416.png (10.33 KiB) Viewed 5266 times

This is a result of a change in FH7.0.1.2:

If you open a project that contains embedded images or local media objects, you will be prompted to run Validate (e.g. File > Validate). The Validate process now checks for media issues and has an extra option to correct media issues found. ‘Media issues’ means local media objects or embedded media. The Validate process will report on both. If the option to correct media issues is ticked, local media objects will be converted to use media records, and embedded media will be converted to project media files.

If you run Validate and allow FH to correct the issues, your FH6 sort dates will be converted into Media records.

I recommend you do not select Validate but open the file without validation and download and run the latest version of 'Order Facts by Sort Date' which will copy your 'Mike Tate'-style sort dates into FH7 sort dates.

You'll still get the Validation error next time you start up, because the latest version of the plugin doesn't delete the old-style sort dates. If you accept the prompt to validate this time (assuming you have no use for the old style sort dates) you need to go to the Media Records List, sort it descending by Record ID, select all the 'Sort Date' media items and add them to an empty Named List, then select the named list, right click and Delete Listed Records.

Mike, perhaps you should incorporate some or all of this advice into Help for the plugin?

[tatewise]

Thank you for the feedback.
It has made me review the Plugin, which should not only remove all LMO after conversion to Sort Date, but also cope with LMO converted to Media records, so whether the user Validates or not everything should have been OK.

However, I found a flaw in the logic and it only processes the first LMO/Media Sort Date per person and skips the rest.
So I will correct the Plugin ASAP.

Nevertheless, no harm should come from Validating and running the Plugin before or after.

This is an unfortunate continuation of the issues with LMO.
In FH V6 when a GEDCOM with LMO was imported or merged all LMO were unconditionally converted to Media records.
Such unconditional changes go completely against what FH usually does in retaining data unaltered.
That had an undesirable effect on LMO Sort Dates, which I reported and CP agreed to fix.
In FH V7 when a GEDCOM with LMO is imported they are all still unconditionally converted to Media records.
But if such a GEDCOM is File Merged (or updated from FH V6) its LMO are all retained.
This new Validation message does not make it clear that it refers to LMO so is less useful than it could have been.
CP must be well aware of LMO Sort Dates and yet do little to accommodate them.
So I spend unnecessary effort modifying my Plugin to cope with the CP disregard of LMO Sort Dates.

[ColeValleyGirl]

It's unreasonable to expect CP to take into account everything done by plugin authors.

Your use of LMOs for sort dates was creative, but not what they were intended for, surely, and so always likely to be affected by a new release of the program (especially as CP has always preferred Media Records to LMOs.)

[NickWalker]

I'm not commenting on the particular issue, but actually I don't think it is unreasonable at all for CP to take into account things done by plugin authors. Mike is one of only a tiny number of people who have created almost all the plugins in the store. He adds functionality to FH that has benefitted 1000s of FH users. He's almost like an unpaid member of the programming team and certainly if I was in CP's position I'd try to respond to his requirements. Adding a feature that helps a plugin author will ultimately improve FH for lots of their end users. If there were hundreds of plugin authors I would agree, but keeping this small number of authors happy doesn't seem unreasonable.

[Mark1834]

Particularly as their policy and expectation is that plugins (including DEAs) come from the community...

[tatewise]

I have been considering whether I want or need to upgrade to FH V7 and just leave my plugins as a legacy.

[ColeValleyGirl]

No commercial software developer could allow their product to be constrained by what the (volunteer) authors of add-on software did.

Should they not have included DEAs and Source Templates because of AS, and Shelley Coopers Add Source from Template plugin? Research Notes because of my Research Planner template? Sort Dates because of Mike's plugin?

Of course they should!

This particular plugin has been downloaded only 173 times since it was written and makes a non-standard use of a Gedcom feature (using a structure designed to hold information about media to hold something else entirely.) It was a very useful plugin (I may even have been involved in prompting Mike to write it) but CP have superseded it and Mike coded a migration solution (unfortunately with a bug). It's unfortunate that there wasn't somewhere else to park the relevant data that was in line with CP's evident strategy for handling media, but there wasn't, so Mike had to take the risk.

Plugins using Gedcom structure as they are intended to be used are much less likely to run into difficulties, as are plugins using the FH API as designed rather than rummaging around in configuration files (I have some checking to do on a number of my plugins that parse or construct various files directly -- and it they're broken, that's my problem.)

[ColeValleyGirl]

Mike, the updated plugin works fine.

[jbtapscott]

Referring to the initial post here - I had already run the V7 version of the Sort Plugin and thus encountered the warning mentioned in the penultimate paragraph of the first post here after I installed 7.0.1.2 yesterday. I followed the FH prompts / suggested actions and subsequently added the records (9,000+) to a Named List and then deleted them. Other than the time it took to highlight all the records and then add them to the list, everything worked fine. [Edit: Sorry, posting of my comments crossed with Helen's last responses!]

[ColeValleyGirl]

Brent, have you checked that the LMOs have been deleted? Otherwise it will be Groundhog day when you re-open the same project.

[jbtapscott]

First thing I did Helen! All deleted and the Gedcom file itself dropped slightly in size (as would be expected) based on the multiple backups I took before starting the upgrade and the "Sort" resolution processes.

[shoshk]

Mike, you sound tired.

[goodwin2]

I'm really curious about Mike Tate's remark saying he might not switch to V.7. Since most of us regard Mike as the head guru answering all our questions about Family Historian, I'm surprised that he would not have been the first to upgrade to V.7.

I've said in a previous post that I will be going back to V.6 as I see nothing in V.7 that would be of particular help to my research efforts or the way I manage and record my data. I'm in the US so it is likely that some of the data that I would gather and display would differ from that in the UK.

I'm hoping that all the queries [as well has all the rest in my database] that I had in V.6 will be restored when I reinstall V.6.

Will still be looking to the good folks in FHUG for answers/suggestions.

[tatewise]

The quote in Helen's first posting suggests the media-handling issue is triggered by any Local Media Objects (LMO) and not particularly the novel but valid Sort Date usage with no file link.
That quote also suggests there is an "option to correct media issues" which presumably can be unticked to inhibit the validation message every time the project is opened. Can anyone please confirm.

[ColeValleyGirl]

Mike, yes I believe it's all LMOS not just Sort Dates. (And I agree your Sort Dates were valid Gedcom by the letter of the standard, just not aligned with CP's apparent strategy for Media). I suspect that most people won't encounter an issue because LMOs are so rarely used -- to create one in FH takes a plugin (like yours) or ferreting around in the All tab. (Embedded media are also being converted to Media Records in this tidy-up).

If you accept the offer to Validate the file which precedes the message I screenshotted, but then untick the option to correct media issues, you get presented with the same message every time you open the file (i.e. the validation message isn't inhibited).

However, if you decline the offer to Validate the file, you get an option to 'Disable future-warnings about media-handling in this projects (not recommended)?'

[tatewise]

LMO might be rarely used in FH but the majority of the rest of the genealogy world use them rather than Media records.
With those products, only LMO offer all the available features such as choosing a primary photo and face frames.
In GEDCOM 5.5, LMO provide the only valid way to link external media files without using a non-standard tag.
So any user migrating from those products will be faced with the LMO dilemma.

If a user needs to migrate a GEDCOM from those products into FH they have two options:

1. File > Project Window > New Project
   This unconditionally converts all LMO to Media records and goes against the usual FH policy of keeping all imported data.
   However, there are several unfortunate side-effects that have been reported but not fixed as far as I know...
   The Title of each LMO is discarded.
   If several LMO link to the same file then multiple copies of that file get imported with (n) filename suffixes.
   If multiple LMO are identical in all respects they still produce multiple identical Media records (except for filename) and the user will have to merge them.
2. File > Merge/Compare File
   This retains all LMO (which is a change from FH V6 that unconditionally converted them as above).
   But now that suffers the Validation message. So that is a mixed message ~ are LMO allowed or not?
   Can anyone confirm if the Validation conversion to Media records keeps the LMO Title and do multiple copies of the same file get created and do multiple copies of identical LMO result in multiple identical Media records?

IMO: LMO are a much neater implementation of Media.
All the necessary custom features such as selecting the primary image, face frames, exclude from Diagrams/Reports, etc, are all held subsidiary to the OBJE tag near the TITL, FILE, FORM, NOTE fields. There is no complicated linkage to Media records.
Even FH V7 has recognised the benefits of that approach by putting those custom feature fields subsidiary to the OBJE tag although it still links to a Media record.

[ColeValleyGirl]

The Title of each LMO is discarded.

Fixed, I believe.
Can't see anything about the other issues -- I assume somebody reported them in V7?

I don't have any files with LMOs in them to test.

So that is a mixed message ~ are LMO allowed or not?

I read the messaging to say they're 'not recommended',

[tatewise]

Yes, I reported it in July 2015 and again during FH V7 beta testing but as that was pulled without notice I have no log of the beta test report.

New Project Imports Duplicated Media [#761088]
http://www.calico-pie.com/osticket/view ... o0Xw%3D%3D Jul’15
This is related to the FHUG Importing and Exporting Forum, Importing from Legacy posting, and also the FHUG Plugin Discussions Forum, Duplicate Media Records posting.

It affects File > Project Window > New Project > Import a GEDCOM file with default options ticked.
When various Local Media Objects &/or Media Records all link to the same file then multiple copies of that file are imported to the Media folder but with (9) style suffixes on their filename.
Also each Local Media Object becomes a new Media Record even when all the parameters are identical.

I have easily repeated the same symptoms using a test GEDCOM file.

Where the linked file folder path and filename are identical, and that file already exists in the Media folder, then another copy of the same file should NOT be created.

When converting Local Media Objects into Media Records on import, if the parameters are identical to an existing record then it should be employed instead of creating a duplicate record.

This behaviour is a real annoyance to anyone migrating from many other popular products.

How do users discover what is fixed other than by a longwinded process of trial and error?
Have you got some privy access to a list of issues that we mere mortals don't have?

[NickWalker]

Fixed, I believe.
Can't see anything about the other issues -- I assume somebody reported them in V7?

What is that you're looking at which lists the issues reported and shows what is fixed? It would be useful to see that but I assumed we'd have to wait for the update to be officially released to see what was fixed and I didn't think we ever got to see issues reported but not fixed.

[ColeValleyGirl]

I was sent a link to a page listing the fixes in 7.0.1.2 (and the previous versions) when I received a link to the software to download, so that I could check which issues I'd logged are supposed to be fixed... I'm not sure if it's supposed to be made more widely available, as it isn't discoverable on the FH website, but I assume that anyone who has been asked to check that an issue has been fixed has received the link. It doesn't include any info about issues reported but not fixed, just about fixes.

[NickWalker]

Ah OK that makes sense thanks.

[RS3100]

Helen, I only received a link that gave me a direct download of the build that CP believed had fixed the bug I reported. I've just looked at the email again in case I missed it and there's no link to a list of fixed bugs, so you must be "special"

[ColeValleyGirl]

Maybe it was easier to send me a link than list all all the fixes I was interested in... I have reported quite a few things, including stuff that hasn't been mentioned here on the forums.

[tatewise]

It is a shame that CP only send such details to the people who reported a problem.
Users are regularly dissuaded from reporting similar problems repeatedly after it has been reported once.
So the user who first reported the problem gets to know what was fixed but everyone else is left wondering.

[ColeValleyGirl]

It is a shame that CP only send such details to the people who reported a problem.

As a by-product of asking the people who reported the problem to test that any fix relevant to them is working.

However, the existence of a list suggests it might be made more widely available, so maybe your reiterated complaints have borne fruit, Mike.