They're there, maybe underneath the portal. If they don't all land in the portal row, they wont show, what Phil refers to as something like "the portal doesn't own the object (field)". This means drag them off.........drag them back on, one at a time. If you move the whole portal they might be underneath
From your screen shot, is the field suppose to be in the portal row or above it where the labels are. Also, is there any other objects in the portal row next to contactName?
The field is "falling through" the portal to be behind the portal. The behavior of portals and fields when doing this kind of field placement changed with the release of FileMaker 12 to be more like that of a tab control. From FileMaker 12 onward, portals need to "own" a field before the field is properly placed in the portal row and displays data correctly in each row of the portal.
If a portal "owns" a field properly, the field will move when you move the portal that owns it.
This means that you have to place new fields fully inside the boundaries of the portal row before you release the mouse. In the second screen shot shown, the borders of the field extend out of the portal and so the portal does not take ownership and the field falls through the portal. You may want to temporarily reduce the number of portal rows and enlarge the size of the portal row to make it easier to copy a block of fields to the portal row such that all field object borders are inside the portal row borders at the time you release the mouse button. You can then fine tune their placement individually before returning the portal to its original number of rows and row height.
Note also that you cannot use the inspector's alignment tools to "pull" a field from outside the portal into the portal such that the portal takes ownership. Attempting this will leave the field either floating above the portal or hidden behind it without the portal "owning" the field.
Hmm, come to think of it, I suspect that you have either a slide control, tab control or popover panel that contains and "owns" your portal as I haven't seen this "fall through" behavior with portals, but have seen it with popovers. The field has to be fully contained by the popover frame before I release the mouse of it falls through to the layout behind it. Note that all of these "containing objects" have the same "ownnership" (my jargon BTW) requirements.
The object is a tab control with 4 tabs. Each tab has an identical copy of the portal except for the sort.
When I copy/paste the entire portal from a 'master' held outside the displayable part of the layout, everything copies correctly.
When I tried just copying the row of data (to save having to reset the 'sort' on each tab), the first 3 and the last 3 of 9 fields (all with the same height and aligned on 'middlles' pasted correctly. The middle 3 'fell through'.
I tried reducing the number of rows in the portal and expanding the height of the row as suggested above. I copied/pasted one of the 3 fields that 'fell through' into the row - fully contained in the row - and the field fell through anyway. Something else is going on.
Unless something else can explain the behavior, I guess I will stick with copying the entire portal onto the 4 tabs and re-setting the sort if I need to make any changes to the content of the portal rowl.
BTW, when I 'select' a part of the layout that should show the fields that 'fell through', they don't. When I move the tab control there are no fields behind. When I delete the portal there are no fields behind it on the tab control.