Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add field:create command #4853

Merged
merged 19 commits into from Dec 2, 2021
Merged

Conversation

DieterHolvoet
Copy link
Contributor

@DieterHolvoet DieterHolvoet commented Oct 7, 2021

Original PR here: #3528


This PR adds a command to create fields, similar to the field-create command that was present in Drush 8. It has already been used in multiple projects at the company I work at, and is in my opinion stable enough to be considered to be merged in Drush. The original PR was closed becaused generate field was supposedly similar, but it's not. This command adds a new field to an entity type, it doesn't create a new field type.

Tests

There is no test coverage yet.

Naming

I named the class FieldCreateCommands instead of FieldCommands because I think future (smaller) field-related commands should be kept seperate from the field-create command. The class is already almost 700 lines long and adding other commands would make it a bit too cluttered.

@DieterHolvoet DieterHolvoet changed the title Add field:create command WIP: Add field:create command Oct 7, 2021
@DieterHolvoet DieterHolvoet marked this pull request as draft October 7, 2021 09:51
@DieterHolvoet DieterHolvoet changed the title WIP: Add field:create command Add field:create command Oct 7, 2021
@weitzman
Copy link
Member

weitzman commented Oct 7, 2021

Thanks for contributing this. The code looks very high quality. It occurs to me that some of the questions might better belong in an interact() method. I'm not sure how feasible that is. Lets also add a test of type 'integration' for this.

This does look like a different use case from gen field, which creates a field type and an instance. This command creates an instance of an existing type. Neither approach do what I like to do which is to add a base field (i.e. non-configurable field) to a bundle. Overall, I think we could improve the naming and descriptions of these two commands. I'm not sure how though. Input welcome

/cc @Chi-teck

@Chi-teck
Copy link
Collaborator

Chi-teck commented Oct 7, 2021

I agree, field-create and gen field are completely different things. If you run drush create:field command in Drush 10 you will get the following message.

field-create has been removed. Please try generate field command.

Defently, this message should not suggest generate field command.

@Chi-teck
Copy link
Collaborator

Chi-teck commented Oct 7, 2021

the field-create command that was present in Drush 8

Yes and no. Because that command only worked with Drupal 7. We failed to update it to support Drupal 8. The relevant issue is still open. #230

Note that field-create was just one of field related commands that existed in Drush 8.

  • field-clone Clone a field and all its instances.
  • field-create Create fields and instances. Returns urls for field editing.
  • field-delete Delete a field and its instances.
  • field-info View information about fields, field_types, and widgets.
  • field-update Return URL for field editing web page.

@DieterHolvoet
Copy link
Contributor Author

It occurs to me that some of the questions might better belong in an interact() method. I'm not sure how feasible that is.

I used the @interact hook in a previous version, but I deliberately removed it. I can't remember the exact reason, it might have been because of certain issues I was having or it might have been the result of trying to simplify the code. This is the commit in which the change was done.

I do remember it being hard to completely finish the interactive part before the @command method, since some questions can only be asked after parts of the logic have been executed. No logic can be executed in the @interact hook since it is not being executed in non-interactive contexts.

If it's okay for you, I'd like to leave this as is. I will make sure that the command works perfectly when passing the --no-interaction option, which might not always be the case right now.

Lets also add a test of type 'integration' for this.

I don't have much experience with automatic testing but I'll try to get to this.

Neither approach do what I like to do which is to add a base field (i.e. non-configurable field) to a bundle.

I don't have any code lying around that does this. This sounds like a case for a generate subcommand since this will generate code.

Overall, I think we could improve the naming and descriptions of these two commands. I'm not sure how though. Input welcome

I thing renaming generate field to generate field-type is a start. Personally, I think field:create is the right name for this command.

Definitely, this message should not suggest generate field command.

I removed that placeholder command in this PR since we now have an actual replacement.

Note that field-create was just one of field related commands that existed in Drush 8.

I know, and we have replacements for pretty much every one of them in our wmscaffold repo:

  • field:create: Create a new field
  • field:delete: Delete a field
  • field:info: List all fields of an entity bundle
  • field:update: No command yet, but the required code is present in FieldCreateCommands::logResult.

Additionally, we have two commands to deal with base fields

  • base-field:info: List all base fields of an entity type
  • base-field-override:create: Create a new base field override

I'll create PR's for these commands later.

@Chi-teck
Copy link
Collaborator

Chi-teck commented Oct 11, 2021

I thing renaming generate field to generate field-type is a start.

drush generate field-type already exists.

@DieterHolvoet
Copy link
Contributor Author

drush generate field-type already exists.

The output seems similar, are both necessary? In any case, the naming of those generators seems out of scope for this issue. Feel free to let me know if you don't agree with the naming of field:create.

@weitzman
Copy link
Member

Those answers make sense to me. Thanks. Please fix code style issues that are failing the test suite now. You can see them locally with composer cs

Copy link
Member

@weitzman weitzman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've fixed test failures. Just one minor question remaining.

* @aliases field-create,fc
*
* @validate-entity-type-argument entityType
* @validate-optional-bundle-argument entityType bundle
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do these two annotations do anything? I dont see what checks them.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's still a leftover from where I took the command, it's an abstraction for validating entity type/bundle arguments: https://github.com/wieni/wmscaffold/blob/release/v1/src/Commands/ValidatorsCommands.php

It's used in other commands I mentioned before: field:delete, field:info, base-field:info, base-field-override:create. If we're planning on incorporating those commands as well, it might be worth it to keep it abstract, if not we can copy/paste it into the class.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are no changes to ValidatorsCommands in the PR so those annotations don't yet do anything. I'm OK with the abstraction, I just think they should have their corresponding code in Drush.

@weitzman weitzman added this to the drush11 milestone Oct 30, 2021
@DieterHolvoet
Copy link
Contributor Author

@weitzman and I discussed this PR on Slack. Some things that need to be done before merging:

@DieterHolvoet
Copy link
Contributor Author

DieterHolvoet commented Nov 24, 2021

Some test scenarios given a node type article without fields. Still working on the other stuff listed above.

Entity types with bundles

  • drush fc node should ask for a bundle
  • drush fc node --no-interaction should complain about a missing bundle

Entity types without bundles

  • drush fc user should not let you choose a bundle and continue with the other questions instead
  • drush fc user user should not let you choose a bundle and continue with the other questions instead
  • drush fc user --no-interaction should not complain about a missing/invalid bundle argument
  • drush fc user user --no-interaction should not complain about a missing/invalid bundle argument

Existing field storages

  • drush fc node article --existing interactively lists existing node fields, eg. body
  • drush fc node article --no-interaction --existing-field-name="body" --field-label=Body --field-widget=text_textarea_with_summary successfully adds the body field
    • When calling the same command a second time, it should complain about the field already existing.
  • drush fc node article --existing-field-name="body" --field-label=Body --field-widget=text_textarea_with_summary asks for optional fields before successfully adding the body field

New field storage

  • drush fc node article --field-name=body should complain about the field storage already existing
  • drush fc node article --field-type=entity_reference should at some point ask for Referenced entity type
  • drush fc node article --no-interaction --field-label=Test --field-name=field_test --field-type=entity_reference --field-widget=entity_reference_autocomplete --cardinality=-1 should complain about the missing target-type option
  • drush fc node article --field-label=Test --field-name=field_test --field-type=entity_reference --field-widget=entity_reference_autocomplete --cardinality=-1 --target-type=node should at some point ask for Referenced bundles, allowing me to choose multiple bundles. The target_bundles handler setting should change after.
  • drush fc node article --no-interaction --field-label=Test --field-name=field_test --field-type=entity_reference --field-widget=entity_reference_autocomplete --cardinality=-1 --target-type=node --target-bundle=article, the target_bundles handler setting should change

LinkHooks, field-create-set-options & field-create-field-config events

  • drush fc node article --field-type=link should at some point ask for Allowed link type and Allow link text, title and link_type should be in field settings config

Output

  • a summary containing field name, entity type and bundle should be printed
  • if the Field UI module is installed, a link to the field edit form should be printed

@DieterHolvoet
Copy link
Contributor Author

@weitzman I did some final polishing of the code and I wrote out some test scenarios. This is ready to go from my side!

Something small I noticed: I don't really like the fact that the Cancel option is prepended to every choice list, why is this necessary if you can just Ctrl+C to exit like with every other command?

@weitzman
Copy link
Member

Thanks for the tests scenarios. We cant easily test interactive behavior because the process hangs waiting for input. I will get as much coverage as I can.

That cancel choice has been there so long I don't recall its justification. I think you are the first person to actually call it out. I bet others have silently grumbled. Lets discuss in a different PR.

I will look into the unrelated test failure on drupal 9.3

src/Commands/ValidatorsCommands.php Outdated Show resolved Hide resolved
- Fix issues when command is called non-interactively
- Improve handling of entity types without bundles
@weitzman
Copy link
Member

weitzman commented Dec 2, 2021

I finally added as many tests as I could.

We are not validating referenced bundles AFAICT. I've commented out the test for that. Not urgent.

Sorry about unrelated changes added to the PR.

@weitzman weitzman marked this pull request as ready for review December 2, 2021 17:25
@weitzman weitzman merged commit 0b5ab2b into drush-ops:11.x Dec 2, 2021
@weitzman
Copy link
Member

weitzman commented Dec 2, 2021

Its in! Thanks @DieterHolvoet.

@DieterHolvoet
Copy link
Contributor Author

Its in! Thanks @DieterHolvoet.

Yay! Thanks for writing the tests 🥳

We are not validating referenced bundles AFAICT. I've commented out the test for that. Not urgent.

I created a follow up issue: #4912

@DieterHolvoet DieterHolvoet deleted the field-create branch December 3, 2021 11:22
@DieterHolvoet
Copy link
Contributor Author

@weitzman did we forget to update this page of the docs, or does that happen automatically? https://www.drush.org/latest/commands/all/

@DieterHolvoet
Copy link
Contributor Author

I added a merge request to the Allowed Formats module. I'm afraid it's not going to get merged anytime soon though, since the project has the Maintenance fixes only status.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants