0

I currently have the following code in a D8 module:

$sql = 'CREATE TABLE `comment__field_follow_up_date` (' .
  "`bundle` varchar(128) CHARACTER SET ascii NOT NULL DEFAULT '' COMMENT 'The field instance bundle to which this row belongs, used when deleting a field instance.'," .
  "`deleted` tinyint(4) NOT NULL DEFAULT '0' COMMENT 'A boolean indicating whether this data item has been deleted.'," .
  "`entity_id` int(10) unsigned NOT NULL COMMENT 'The entity id this data is attached to.'," .
  "`revision_id` int(10) unsigned NOT NULL COMMENT 'The entity revision id this data is attached to, which for an unversioned entity type is the same as the entity id.'," .
  "`langcode` varchar(32) CHARACTER SET ascii NOT NULL DEFAULT '' COMMENT 'The language code for this data item.'," .
  "`delta` int(10) unsigned NOT NULL COMMENT 'The sequence number for this data item, used for multi-value fields.'," .
  "`field_follow_up_date_value` longtext NOT NULL COMMENT 'The actual value that is stored in the field.'" .
  ") ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='Data storage for comment field field_follow_up_date.'";

if ($dbConn->query($sql)) {
  echo "'comment__field_follow_up_date' " .
    "table (re)created successfully.\n";
} else {
  echo "Error (re)creating 'comment__field_follow_" .
    "up_date' table: " . $dbConn->error . "\n";
  exit();
}

$sql = 'ALTER TABLE `comment__field_follow_up_date` ' .
  'ADD PRIMARY KEY (`entity_id`,`deleted`,`delta`,`langcode`), ' .
  'ADD KEY `bundle` (`bundle`), ' .
  'ADD KEY `revision_id` (`revision_id`)';
if ($dbConn->query($sql)) {
  echo "Keys successfully added to 'comment__" .
    "field_follow_up_date' table.\n";
} else {
  echo "Error adding keys to 'comment__field_follow_" .
    "up_date' table: " . $dbConn->error . "\n";
  exit();
}

It seems to work, but upon inspecting the DB changes made when doing this through the UI, I have noticed another seven tables that are modified in some way, just by adding a single comment field!

So I am worried that I am not doing this the "proper" way, and that things will fall apart when we eventually upgrade to D9 (currently in the middle of a D6 - D8 upgrade and data migration).

Is there an official way to do this in code? I am not interested in doing it through the UI for each and every field I have to add (23 in total!) and all of my Googling attempts have only come up with articles related to that. MTIA! :D

10
  • 3
    You don't want to do it this way. See this drupal.stackexchange.com/a/222296/57
    – Kevin
    Apr 22, 2020 at 3:43
  • 2
    Before you start export the current configuration to yaml files drush cex. Then add one field in UI as example and export again drush cex. The command will list the files which have changed. Copy the field config and the field storage config under a different field name and make adjustments in the files content. The other yaml files changed are form modes and view modes of the content type. In those you need to copy and paste the section added for the field and make adjustments as well. Finally, import the yaml files and so generate the database tables automatically: drush cim.
    – 4uk4
    Apr 22, 2020 at 6:35
  • 1
    Hmm very interesting @4k4...that might be easier than writing a module, but a module would assumably be able to migrate the old data across as well. I'll discuss both approaches with my boss and see what he thinks. Thanks! :D
    – Kenny83
    Apr 22, 2020 at 6:44
  • 1
    After finishing the configuration (in a mix of UI and yaml file editing of your choice) you can export the entire content type config to a module install folder. See drupal.stackexchange.com/a/284924/47547. There are a lot of ways to improvise if you know all the tools you have available.
    – 4uk4
    Apr 22, 2020 at 6:47
  • 1
    Yes I'm aware of the whole concept of config management @leymannx, as well as the drush cex and drush cim commands. We have used them extensively to migrate config and content from an old D6 site to the new D8 one that we're building. Which is why 4k4's suggestions could be fairly-easily integrated into the workflow we've already established for replicating the site across dev/staging/prod environments.
    – Kenny83
    Apr 22, 2020 at 6:48

0

Browse other questions tagged or ask your own question.