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
Add field:create command #4853
Conversation
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 /cc @Chi-teck |
I agree,
Defently, this message should not suggest |
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
|
I used the I do remember it being hard to completely finish the interactive part before the 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
I don't have much experience with automatic testing but I'll try to get to this.
I don't have any code lying around that does this. This sounds like a case for a
I thing renaming
I removed that placeholder command in this PR since we now have an actual replacement.
I know, and we have replacements for pretty much every one of them in our
Additionally, we have two commands to deal with base fields
I'll create PR's for these commands later. |
|
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 |
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 |
There was a problem hiding this 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 and I discussed this PR on Slack. Some things that need to be done before merging:
|
Some test scenarios given a node type Entity types with bundles
Entity types without bundles
Existing field storages
New field storage
|
cdec746
to
1730859
Compare
@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? |
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 |
- Fix issues when command is called non-interactively - Improve handling of entity types without bundles
aaced26
to
707d7ef
Compare
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. |
Its in! Thanks @DieterHolvoet. |
Yay! Thanks for writing the tests 🥳
I created a follow up issue: #4912 |
@weitzman did we forget to update this page of the docs, or does that happen automatically? https://www.drush.org/latest/commands/all/ |
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. |
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 ofFieldCommands
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.