Page 1 of 1
Heads up for plugin authors in V7
Posted: 28 Jan 2021 11:02
by ColeValleyGirl
FH7 has included the most commonly used Lua libraries in the installation (they're in C:\Program Files (x86)\Family Historian\Program\Lua).
These libraries that were installed on demand in FH5/6 (using the FHUG-written loadrequire mechanism) into C:\ProgramData\Calico Pie\Family Historian\Plugins
Some libraries have different versions for FH5/6 and 7.
I've had a couple of instances running plugins in V7 recently where the library has been picked up from ProgramData (which is the first location searched) and not Program Files, which has caused the plugin to fail because the library version is wrong.
I suggest the long term solution is a one-off plugin for V7 users that cleans out all the libraries installed by loadrequire in ProgramData, but in the meantime, if one of your users gets an error like:

- Screenshot 2021-01-28 110013.png (65.78 KiB) Viewed 5455 times
you advise them how to delete the old library (which will consist of a file e.g. md5.lua and possible a sub-directory e.g. md5).
Somebody may of course have a better idea.
Re: Heads up for plugin authors in V7
Posted: 28 Jan 2021 11:24
by tatewise
Since it is FH V7 that has pre-installed the libraries, and it is the FH V7 installation process that migrates from FH V6, then should the installation process remove such libraries from ProgramData automatically, or at least hide them in a sub-folder.
It is essentially similar to dealing with any other customisations that conflict with FH V7.
FH V7 should automatically prevent old libraries that match its pre-installed libraries from taking precedence.
An alternative is for FH V7 to check C:\Program Files (x86)\Family Historian\Program\Lua before C:\ProgramData\... when performing a require.
Re: Heads up for plugin authors in V7
Posted: 28 Jan 2021 11:41
by ColeValleyGirl
It wasn't FH/CP that installed the libraries via loadrequire, Mike. Remind me, who wrote the loadrequire code? It isn't in the FH API. And since CP didn't write the code to download the libraries into ProgramData, it's hard for me to understand why they should be involved in deleting them.
I have already explored the possibility of changing the search order for libraries, but putting Program Files before Program Data prevents users of libraries that they've modified from using them. For example, I have a modified version of fhUtils for my own use within private plugins... your suggestion renders that unusable. (It would also make testing new versions of libraries before proposing them to CP impossible).
Re: Heads up for plugin authors in V7
Posted: 28 Jan 2021 12:02
by tatewise
OK, OK, OK. Keep your hair on!
Remind me, Helen, where
loadrequire gets its library modules from?
It is
http://www.family-historian.co.uk/lnk/g ... module.php? where Calico Pie place the precompiled module.
So maybe it is not in the API but it seems that CP had a hand in providing them. They supplied all the modules for FH V6.
I believe Plugin Authors requested popular modules to be compiled for FH V6 and CP obliged.
Therefore, in my book, CP should resolve the conflict resulting from installing the updated modules with FH V7.
Re: Heads up for plugin authors in V7
Posted: 28 Jan 2021 12:12
by ColeValleyGirl
We'll agree to disagree, Mike. I'm grateful that CP listened to those of us who asked for them to be installed with V7 -- and that they agreed to host them for V6.
Given that it's our problem to solve (whether you like it or not), do you have any additional suggestions? On the table so far:
- A one-off plugin
- Wait for users to have problems and coach them to delete the old libraries manually. (This has the disadvantage that users trying a new plugin might see it not work and walk away rather than ask for help).
I don't think it wise for individual plugins to 'tidy up' the stuff that might trip them up, at least not without checking with users -- which might cause more problems than it cures. (This is also not a good idea because of the workload it would place on you).
Re: Heads up for plugin authors in V7
Posted: 28 Jan 2021 13:46
by Jane
My fault I am afraid, I wrote the loadrequire and it's backend php and asked nicely for CP to host them to keep them out of FHUG.
The simplest solution as Helen suggests is a plugin/function to simply delete all modules hosted for V6 on a V7 system, by using the logic in loadrequire to get the mod files down and then delete the matching files.
I much prefer the order the search sequence is in as it means if we need to test a newer library, iup for example it can simply be dropped into the Program data folder.
Re: Heads up for plugin authors in V7
Posted: 28 Jan 2021 15:19
by tatewise
Well! I find the whole involvement of CP in this quite confusing.
I had two support ticket discussions with Ros at CP back in October 2017.
Lua Socket Library Problems #590979
This reported a problem with the socket library file structure and was quickly corrected by Ros in FH V6.2.5.
Lua Sec SSL Library for https #123878
This attempted to add a library to support the secure HTTPS protocol but Ros could not get the Windows version to work with FH V6.
So are you saying that CP did not get involved with library modules, because those support tickets suggest otherwise.
They give the impression that CP did more than just passively host they library modules.
Anyway, do CP want to encourage a community of Plugin Authors and support their activities or not?
IMO it is in the interest of CP to fix this problem and not expect Plugin Authors to do so.
Re: Heads up for plugin authors in V7
Posted: 28 Jan 2021 16:09
by ColeValleyGirl
Perhaps Ros was just a go-between, talking to somebody else who actually resolved the issues? I suspect that if you report a problem with the two libraries I recently shepherded into availability, I might get an email from Ros...
Re: Heads up for plugin authors in V7
Posted: 14 May 2021 13:27
by tatewise
This topic has stagnated without a solution to the problem of deleting FH v6 library modules from the Plugins folder that are superseded by the FH v7 auto-installed later versions.
See
plugin question after update to FH 7 (19194) and
Backup Plugin throws error after update to v3.1 (19410).
I have also just had an email from a Plugin user with the same problem.
I believe the options for deleting the old FH v6 library modules are:
- FH v7 installation process
- Publish a Plugin
- FHUG KB advice page
- Coach users who report a problem
As was mentioned earlier, the disadvantage with all but the first option is that users trying a new Plugin might see it not work and walk away rather than look for a solution.
Re: Heads up for plugin authors in V7
Posted: 16 May 2021 11:35
by tatewise
I have given in to temptation and updated the Install Library Modules plugin such that it disables those library modules when run in FH v7 and only installs the library modules in FH v6.
It disables the module folders and files by renaming them with fh6 inserted into the file extension rather than delete them.
At least this gives us a plugin we can advise users to run after upgrading from FH v6 to FH v7.
If nobody has any objections I will publish this update next week.
It cannot be attached here as even a ZIP file version is too big (715KB).
Re: Heads up for plugin authors in V7
Posted: 16 May 2021 11:44
by ColeValleyGirl
I knew there was a good reason for creating a list of plugin work-in-progress... which only works however if people record what they're working on.
Mea culpa for not recording it, but it looks like we'll have two methods when the plugin somebody else is working on is published... I tested it towards the end of last week, and there's one minor tweak needed, and then it will be published. It takes the list of modules/files available for loadrequire and uses it to delete the corresponding files in the Plugins folder.
Re: Heads up for plugin authors in V7
Posted: 16 May 2021 12:06
by tatewise
I only decided to work on this as I had some spare time this morning and no alternatives were forthcoming.
Below is the self-contained function that I used to disable the modules.
I chose to rename rather than delete in case the user had a need for the modules as was expressed earlier in this thread.
How does it compare to the alternative?
Where does that plugin find the list of modules/files available for loadrequire?
Does that include the compat53 folder and compat53.lua & zip.dll files?
I also chose to use an existing Plugin as its usage will be short-lived rather than a brand new plugin.
If the other Plugin is preferable then I don't need to publish mine.
Code: Select all
require("lfs")
function DisableModules()
local arrFile = { }
-- List of library module folder/file names
local arrName = { "loadrequire"; "luasql"; "ltn12"; "md5"; "mime"; "pl"; "socket"; "compat53"; "utf8"; "zip"; }
local arrType = {
{ Old=""; New=".fh6"; Mode="directory"; }; -- List of old and new file extensions
{ Old=".lua"; New=".fh6_lua"; Mode="file"; };
{ Old=".dll"; New=".fh6_dll"; Mode="file"; };
}
local dirData = fhGetContextInfo("CI_APP_DATA_FOLDER").."\\Plugins\\"
for _, dicType in ipairs (arrType) do
for _, strName in ipairs (arrName) do -- Rename any library module folder or file from old to new
local strOld = dirData..strName..dicType.Old
local strNew = dirData..strName..dicType.New
if lfs.attributes(strOld,"mode") == dicType.Mode then
local isOK, strErr = os.rename(strOld,strNew)
if isOK then
table.insert(arrFile,strOld) -- Log disabled renamed folder or file
else
fhMessageBox("\nModule disablement rename failed for:\n"..strOld.."\n"..(strErr or ""))
end
end
end
end
if #arrFile > 0 then
fhMessageBox("\nThe following FH v6 library folders and files have been disabled\nby inserting 'fh6' into each of their filenames:\n\n"..table.concat(arrFile,"\n"))
else
fhMessageBox("\nNo FH v6 library module folders or files needed to be disabled.\n")
end
end -- function DisableModules
Re: Heads up for plugin authors in V7
Posted: 21 Jun 2021 13:25
by David Potter
Hi All
I found this post(s) by following links related to the same issue. I get the error when running Mike's Backup and Restore Plugin. The error occurred in 7.0.5.0 and having just upgraded to 7.0.7.0 it occurs there also.
Sorry but I have tried to follow what to do with FH legacy files and folders from FH6 but it became confusing.
Is there a definitive list of actions somewhere that one of you could post or point me to please.
Thank you...
Re: Heads up for plugin authors in V7
Posted: 21 Jun 2021 13:39
by Jane
Have you downloaded and run
https://pluginstore.family-historian.co ... dule-files
and still having problems with old code?
Re: Heads up for plugin authors in V7
Posted: 21 Jun 2021 13:42
by David Potter
I found a post which Bill had started and had instructions from Helen on what to remove. Did that and it fixed the problem with the error message for Mike's Backup and Restore Plugin.
Then I noticed I have a Plugin Data folder, see screen shot. Can this be removed?
Thank you.
Re: Heads up for plugin authors in V7
Posted: 21 Jun 2021 13:42
by David Potter
Hi Jane
I missed that one somehow. I have just downloaded it now. Thank you.
Re: Heads up for plugin authors in V7
Posted: 21 Jun 2021 16:49
by tatewise
David, do NOT remove that Plugin Data folder unless you really want to disrupt all your Plugins.
Re: Heads up for plugin authors in V7
Posted: 21 Jun 2021 17:02
by David Potter
Thank you Mike - Duly noted.