This would appear to be a parts editor bug. Parts editor wasn’t finished when development ceased so it has both bugs and parts that are incomplete (that is part of why I don’t use it). It doesn’t support a number of elements: bendable legs for one, split copper0 and copper1, and probably others I don’t know or remember at the moment. Hopefully with development restarted this will improve. That said, I don’t remember hearing of this particular fault before.
I expect the only way is to edit the fzp file with either an editor or a script that will change all the sequence of connectors back to what they should be (on a large part that is a lot of work unless scripted!) I tend to delete the connectors entirely and replace them with boiler plate generated by this python script.
You can do that in the fzp file and nothing I know of but the parts check script objects. The part file format does however specify that connectors should start at zero and be sequentiaI, so something may break if that isn’t true (but I don’t know of anything, many of the eagle2fritzing parts start on non zero pins, and are not sequential and appear to work fine. I think the reason here (but no one that would have known was still around when I joined Fritzing) is C++ array addressing (which starts at 0) against common pin numbering (which starts at 1.) For internal storage, pins starts at 0. (so you don’t waste the first array slot in every part.) For external display it starts at what ever pin number you set. If the pins are not sequential (possibly only in parts with subparts because that is the only place I’ve seen it happen), the “hover on the pin and get the description” function screws up. For pin sequence (internal) 0, 1, 3, 4, 0 and 1 display correctly, 3 gives random garbage and if I recall correctly 4 gives the data for 5 (it has been a couple of years since I discovered this) and it recovers on 5. I think I tried to reproduce it on non subpart part and failed so it may need subparts to fail.