I just did a test upgrade of a CWIS site from version 2.4.0 to 3.0.2.
On the Access tab of the Metadata Field Editor, the rightmost three privilige columns now contain this message in every cell:
Warning: array_key_exists() [function.array-key-exists]: The first argument should be either a string or an integer in /objects/HumanMetadataField.php on line 1013
On the live site running the older version of CWIS (the site which I cloned to make this test site that I upgraded), the page and tab work as expected, containing values in those cells instead of error messages.
I've tried to drill into this and figure out what is going wrong, but everything is nested in a sea of object orientation. I think I've reached my brain's limit, at least for today ... any pointers as to what might be the culprit?
There shouldn't be an "Access" tab anymore in 3.0.2. When I install 2.4.0 in a sandbox and then upgrade it to 3.0.2, the access tab goes away, as expected.
Is it possible that you have a customized interface for EditMetadataField?
Anything's possible ...
I just replaced /local/interface/{theme}/EditMetadataField.html with the file that was in interface/default, but the tab and the errors are still there. Should I be looking elsewhere?
1) Have you cleared you browser cache?
2) Have you customized that page? If not, then there's no need to have a copy in local/interface/{theme}.
1. Yes
2. I've removed the local copy of EditMetadataField.html now and the tab and errors are still there (yes, after browser cache empty).
It would also be good to check DBEditor.html. EditMetadataField is the editor for individual fields, whereas DBEditor is the master list where the 'Access' tab was removed.
Hi Greg! In general it's best to have only the files in the
local/interfacetree that you've specifically customized for the site. That will help a great deal in avoiding backward compatibility issues going forward, particularly for back end pages like this, which are usually implemented under the assumption that they are unlikely to be customized.Copying all of the files from
interface/defaultinto alocal/interfacesubdirectory will work fine until the next upgrade, which will unfortunately almost certainly cause things to start to gratuitously break. (We probably need to emphasize this more strongly in the documentation.)Hi Ed. I agree! I plead that I did not originally set up this site ...
Well, I tried renaming /local/interface/{themename}/DBEditor.html to see what would happen - to see if it would use the default file.
I got:
failed to open stream: No such file or directory in {path}/lib/ScoutLib/ApplicationFramework.php on line 728
So I assume there must be a sort of chaining effect when you local override some admin files? It is looking for a local copy of DBEditor.html and failing to find it.
This is probably because it has the old location of the file still cached. (Need to cache interface file locations to keep the file system checks to a reasonable level.) If you go into the System Configuration page and set Template Location Cache Expiration to 0, that should disable caching and resolve the problem.
(Make sure you set it back to some higher value for any production system; those file system calls can really bog down a busy site.)
That did it - the Access tab is now gone!