As I've mentioned, I just did a test upgrade of a CWIS site from version 2.4.0 to 3.0.2.
On Add New Resource:
/index.php?P=EditResource&ID=NEW
After the upgrade, There are a bunch of new field rows listed above the Title row.
- Postal Code
- State
- Country
- Phone Number
- City
- Address Line Two
- Web Site
- Name
- Address Line One
- User Account
They look like user fields. All are empty. The User Account field contains a bullet (an empty li tag).
There are no actual fields - nothing to enter or edit. Just the rows with the labels.
Looks like they might have something to do with metadata schems, but that is just a blob in the database.
Any suggestions to troubleshoot this?
When I perform a fresh install of 2.4.0 in a sandbox and upgrade it to 3.0.2, I don't see these fields on the Add New Resource page.
Is it possible that you've got a custom local interface for EditResource?
We did, but we replaced it with the default EditResource.html. The extra fields are still there.
Is there also a copy of interface/default/include/SPT--EditResourceCommon.html in your local interface? Has that been reset to the default as well?
There was a local copy of SPT--EditResourceCommon.html
I've replaced that with the default copy as well, and the extra fields unfortunately are still there.
We are unfortunately still having this issue (though now it is an upgrade to 3.1.0).
Any additional steps we can take to resolve it?
To reiterate the issue:
On Add New Resource:
/index.php?P=EditResource&ID=NEW
After the upgrade, There are a bunch of new field rows listed above the Title row.
They look like user fields. All are empty. The User Account field contains a bullet (an empty li tag).
There are no actual fields - nothing to enter or edit. Just the rows with the labels.
I would really appreciate some help with this. It is a showstopper.
Some pointers on where to look would be very helpful!
Have you removed files from your custom interface that were not modified, per the comments here and here ? Is there a chance that your local interface includes both SPT--EditResourceCommon.html and include/SPT--EditResourceCommon.html ?
Do you have a local/pages folder, and does it have an EditResource.php in it?
The list of fields on that page is coming from the PrintFieldTableWithGroups() function defined inside SPT--EditResourceCommon.html, but line 27 of that file restricts the output not to include the UserSchema.
Is there any chance you could email me (chalpin@scout.wisc.edu) a .zip of your local folder? If I had that, I could debug this issue with the same interface you're using. I've not been successful trying to replicate this by just upgrading a 2.4.0 install to 3.1.0, which complicates debugging somewhat.
Have you removed files from your custom interface that were not modified, per the comments here and here ?
I cannot do that in blanket fashion. We do not have a complete record of all customizations that were made, so I do not know ahead of time which local files I can delete. I am doing it piecemeal.
Is there a chance that your local interface includes both SPT--EditResourceCommon.html and include/SPT--EditResourceCommon.html ?
That file is not present in either /local/{theme} or /local/{theme}/include/. It was previously present in /local/{theme}/include/ but no longer is. Yet the problem persists.
Do you have a local/pages folder, and does it have an EditResource.php in it?
There is a /local/pages/ filder, but it does not have EditResource.php in it.
Is there any chance you could email me (chalpin@scout.wisc.edu) a .zip of your local folder?
Yes, on its way!
Excellent, thank you.
For what it's worth, a fairly simple shell script should be able to identify what files were changed. Prior to upgrading the site, you could do something like this:
for file in `find interface/default -type f`; dotgt=local/${file/default/YourInterfaceName}
[ -e $tgt ] && ( echo $tgt ; diff -q $file $tgt )
done
That script will output two lines for files that were changed (the name and "Files ... differ"), and just one line for files that were copied without modification.
For the archives (in case someone else is having similar issues), the following will silently remove files that were not changed and provide a list of the files that were changed:
for file in `find interface/default -type f`; dotgt=local/${file/default/YourInterfaceName}
[ -e $tgt ] && ( diff -q $file $tgt && rm $tgt )
done
Thank you for sending a copy of your database along. That proved to be invaluable in debugging this one as well.
The EditResource page uses the MetadataFieldOrdering object to decide which fields to list. I haven't yet entirely figured out how it's happening, but after an upgrade, those user fields are being pulled in to the order when they shouldn't be. For the moment, you can fix the issue by running this SQL query:
DELETE FROM FolderItemInts WHERE FolderId IN (1,2);This will clear current field ordering, resetting it to the default.
We'll have a fix for this issue in the 3.1.1 upgrade procedure.
Uh oh ... after I run this DELETE query, now there are no fields when I go to create a new resource or edit a resource..
Ack! Apologies. I left out a step in the directions. After the DELETE, visit the "Metadata Field Ordering" system administration page. This causes MetadataFieldOrder::MendIssues() to run, which restores the list of fields after the DELETE.
A very belated thanks; that worked! The good fields are there, the spurious ones are not.
(Forgot to come back and let you know at the time.)