Skip to main content

GravityKit\GravityMigrate\Exporters\AnalysisContext

What the field report needs to describe the fields of a form being exported.

An exporter's analysis names its fields by label and says nothing about what KIND of field each one is, because the source of an export is always Gravity Forms and one lookup therefore serves every provider. That lookup used to live inside the AJAX controller, which meant it existed for the wizard and for nothing else -- and wp gk migrate to --dry-run prints the same table.

Static because it reads the form and the platform definitions and holds nothing: two callers, one answer.

Since: %ver%

Source: src/Exporters/AnalysisContext.php:28

Details

  • Kind: class
  • Namespace: GravityKit\GravityMigrate\Exporters

Methods

MethodDescription
attach()Attaches what the field report needs to describe a form's fields, to one analysis.
map_by_label()Pairs of label and value as a map, dropping any label that names two different values.
readable_field_type()What to call a field type in the report.

Method Reference

attach()

public static function attach( array $result, $form_id, string $provider ): array

Attaches what the field report needs to describe a form's fields, to one analysis.

Both the single-form and the batch route go through here, and both must: the client falls back to a neutral word when it cannot find a field's type, so an analysis that arrives without this reports "Headshot is a form field" where the other route says "Headshot is a Post Image field". Same form, same verdict, told two different ways depending on how many forms the operator happened to select.

Parameters

NameTypeDefaultDescription
$resultarrayThe adapter's analysis.
$form_idmixedGravity Forms form ID.
$providerstringDestination provider slug.

Returns

  • array

Since: %ver%

Source: src/Exporters/AnalysisContext.php:47

map_by_label()

public static function map_by_label( array $pairs ): array

Pairs of label and value as a map, dropping any label that names two different values.

The export report describes fields by label, and labels are not unique. Where two fields share one, saying either value beside the other states something false, so the label is dropped and the row is left plain.

Four maps are built this way -- the source form's readable types, universal types and furniture, and the prepared form's universal types -- and they did not agree: the readable type dropped an ambiguous label while the universal type kept whichever field came last, so a verdict could be computed from another field's type and a row read "Stays the same" about a field that had changed. One rule here, called by all four, so they cannot drift apart again. A copy of the rule beside a caller is the same bug waiting: the prepared form's map kept one, and a suite that tests the rule cannot tell whether a caller reaches it.

Parameters

NameTypeDefaultDescription
$pairsarray

Returns

  • array<string, — string>

Since: %ver%

Source: src/Exporters/AnalysisContext.php:268

readable_field_type()

public static function readable_field_type( string $type, string $title ): string

What to call a field type in the report.

Gravity Forms names its own types, and its wording wins: "Single Line Text" reads better than anything derived from text. But the title comes from a registered field object, and a type belonging to an add-on that is not installed here resolves to nothing -- a survey field on a site without the Survey add-on, which is exactly the form somebody is most likely to be moving. The label was dropped from the report entirely, so the field table named the field with an empty type beside it: the column that exists so a reader can check the verdict.

Parameters

NameTypeDefaultDescription
$typestringThe field's own type slug.
$titlestringWhat Gravity Forms calls it, where it can.

Returns

  • string

Since: %ver%

Source: src/Exporters/AnalysisContext.php:314