Then I tried a Repair for DPL and this resulted in the deletion of both the export and import plugins in the Modules folder of Lightroom. I re-installed the plugins by using C:\Program Files\DxO\DxO PhotoLab 1\Plug-ins\Export\lightroom-export.exe . This restored the plugins but the initial error is still there.
Note that this problem is similar to a problem that occurred last year. See http://forum.dxo.com/index.php?topic=13562.0 . I had suggested a workaround that worked but this time, it’s apparently not enough.
Also, note that this error puts LR in an unstable state. When you quit LR, the lightroom.exe process is not terminated and you can’t relaunch it without manually killing the process.
LR 7.5 has moved the Presets folder. This breaks the LR executable detection routine of DPL. This also breaks the plugin installer. There are 2 problems to fix.
If you have run a Repair of DPL, you should follow these steps :
Open C:\Users<user>\AppData\Roaming\Adobe\Lightroom\Modules\dxo-exporter-dpl1.lrplugin\PluginData.lua
Check whether the third line says : dxoExecPath = “invalid”,
If this is the case, replace “invalid” with “C:\\Program Files\\DxO\\DxO PhotoLab 1\\DxO.PhotoLab.exe” or whatever the dxo executable path might be (beware the double backslash)
Save
Then there is a LUA routine in the plugin that must be modified. Do this only if you are in a hurry. Otherwise, wait for the fix from DxO.
Make a backup copy of (or rename) C:\Users<user>\AppData\Roaming\Adobe\Lightroom\Modules\dxo-exporter-dpl1.lrplugin\DxOOpen.lua
The above also applies to the MacOS but the file paths are different (the modified LUA file should be correct). So the whole procedure must be adapted.
If you have lost the plugin files during a Repair operation, you don’t need to re-install. Just run C:\Program Files\DxO\DxO PhotoLab 1\Plug-ins\Export\lightroom-export.exe. This should re-install the plugins only.
That’s VERY helpful, Pat … I figured it wouldn’t do any harm to try - and I was delighted to find that It worked on my installation of PS Elements too (which, previously, was not recognising installation of Nik Collection)
While fixing the LUA script is rather simple, there’s another problem on the DxO side with the DPL installer that should be handled. Some of us have noticed that the Repair operation launched from the DPL installer resulted in deleted LR plugins. In some cases, even the Modules folder of LR has been deleted. I think, this is due to the way the DPL installer (and/or the MSI service) operates.
Apparently, when the Repair process is launched, the files are not checked for validity but merely replaced. That is, they are deleted and then re-installed. This is the brute force approach. So, when it comes to installing the LR plugins, they are first deleted and then “re-installed”. But if the routine determining in which folder they should be copied fails, nothing happens and the installation process stops without reporting any error. So, as a result, the plugins are merely deleted and that’s it. I guess that if no other plugins were present in the Modules folder, this folder is itself deleted.
I have not used MSI since a while and I can’t remember whether there’s an option allowing to avoid such a problem. Also, I admit that error management in LUA is a mess (why on earth did they use this language when developing Lightroom ?). But this should be fixed because not all DPL users are aware that they can re-install the plugins by running C:\Program Files\DxO\DxO PhotoLab 1\Plug-ins\Export\lightroom-export.exe.
Relying on the folder structure of Lightroom in order to determine the location of lightroom.exe is not safe. They are constantly changing it and this will happen again. We already had the same problem last year, it re-appeared this year and you can be sure that this will happen again.
I don’t know for the Mac, but for Windows, there are many other ways to determine the location of the LR executable. In the registry in the first place. But there are other sources for this information (examining the startup menu for example).
In this case, the LUA script I have made available aboce may fail. The Modules folder might have been deleted if the only plugins installed in LR are the two DPL export/import plugins. In this case, just manually re-create this folder (C:\Users\AppData\Roaming\Adobe\Lightroom\Modules).
Another good source for finding Adobe installation folders and executable locations is C:\Program Files (x86)\Common Files\Adobe\caps\hdpim.db. This is a SQLite database. All the necessary information is there.
The error message “attempt to index field ‘_pathForFolder’ (a nil value)” is caused by a bug introduced in Lightroom 7.5 that affects a number of plugins. An Adobe employee has acknowledged the bug and said it will be fixed in the next release. There is a simple workaround available to the plugin developers.
Thanks for the information. Regarding the problem in the DxO plugin, both DPL and LR are faulty. In previous versions, the folder returned by LrApplication.developPresetFolders() was one level higher in the folder hierarchy. The routine used by DxO to locate lightroom.exe is rather strange. Now, bubbling up 3 levels (as they did with versions 7.3 and 7.4) instead of 4 bring them to the Resources folder instead of the Lightroom folder. This method is not reliable, that’s why I have recommended using another mechanism to determine the location of the lightroom executable.
So, in that case, the bug in DxOOpen.lua is not due to a failing call to getpath but to a call to getLightroomExecutablePath() in LrTasks.startAsyncTask that actually returns nothing. A true programming language wouldn’t allow a function to have an exit path not returning a result.