Published in 1.2.2.
Published in 1.1.1.
Fixed in 3.1.0.
Shipped in version 3.1.0.
Committed first version to 3.0.x-dev
Was just checking the code in the ConfigFormBase class and was wondering if it's safe to fully remove the method?
/**
* Returns the typed config manager service.
*
* @return \Drupal\Core\Config\TypedConfigManagerInterface
* The typed config manager service.
*/
protected function typedConfigManager(): TypedConfigManagerInterface {
if ($this->typedConfigManager instanceof TypedConfigManagerInterface) {
return $this->typedConfigManager;
}
return \Drupal::service('config.typed');
}Would it be safer to keep to just remove the condition and turn it into a getter to avoid breaking contrib or custom modules that could be using it? Like so:
/**
* Returns the typed config manager service.
*
* @return \Drupal\Core\Config\TypedConfigManagerInterface
* The typed config manager service.
*/
protected function typedConfigManager(): TypedConfigManagerInterface {
return $this->typedConfigManager;
}Just want to make sure!
Adjusted formulation of text surrounding loading order to avoid confusion.
Good to go in release 1.0.0-alpha2.
We can open a new issue if what was discussed in #2 & #4 becomes a need down the line.
That's fine! I've gone ahead and opened a merge request with the work done so far. I think it's a good first version to at least support field group integration.
Took a look, tested it, and I think what was done was already sufficient.
When choosing to render a field group as a component, I don't think we need to look for files for each field. This is because the group as a whole will be rendered as the component, and all needed preprocessing should be able to be achieved within the one file. In the loaded file we'll have access to all props and slots for the given group.
Did you think of a use case where individual files would be needed? I might be missing something.
Will be closing this now, it's merged into 1.0.x-alpha1!
This is a good idea since field_group is a popular module and is used often with SDC.
I'll continue off what you started and perform some tests.
Comparison looks good to me. Green light for a merge request to be created!
I'll be taking this as part of a Symetris contribution workshop.
Added section explaining that files are loaded from modules as well.
Slight modification to the title of this page to fit with the menu link title.
2.x will be abandoned. This error should not occur in 3.x and above.
2.x will be abandoned unfortunately in favor of 3.x, where test modules will be completely rewritten.
That being said, thank you for the work so many months ago.
Will focus on coding features into this module instead as the core methods to achieve the functionality is much different than Preprocess albeit the same goal being achieved.
Taking this issue as part of a Symetris contrib session.
Released as part of 1.0.0-rc2.
Released as part of version 1.0.3.
Looks good! Will be merging this shortly.
Thank you!
Good catch. Change has been committed in the fork.
Will be merging this soon.
ksere → made their first commit to this issue’s fork.
Released as part of 1.0.0-rc1.
Released as part of 1.0.0-rc1.
Released as part of 1.0.0-rc1.
Help hook has been added with base documentation.
Help hook will be added shortly.
Committed a fix into 1.0.x for this.
.idea has been removed and there are no longer line lengths
Tested and pushed fix into 1.0.x.
The module now declares a dependency on versions 4, 5 or 6 of symfony/filesystem via its own composer.json file.
PHPCS is treating the README file like a PHP file. Autofixing will add unwanted code and changes to the README.
I will however remove .idea and reduce lines to below 80.
This is due to a missing dependency on the symfony/filesystem package.
I will include a composer.json file to address this.
Got a working solution that fits the proposed resolution.
Note that Users and Profiles are two distinct entity types.
For Profile entity types, the terminology profile type is used as that is the name of the bundle.
For User entity types, there is no bundle. I've opted to default to entity type for this case. It's generic and is still appropriate Drupal terminology.
New Status Messages
User
The field Test has been deleted from the User entity type
Profile Types
The field Testhas been deleted from the Main profile type.
Block Types
The field Testhas been deleted from the Basic block type.
Comment Types
The field Testhas been deleted from the Default comments comment type.
Content Types (Unchanged)
The field Testhas been deleted from the Article content type.
Media Types
The field Testhas been deleted from the Audio media type.
Vocabularies
The field Testhas been deleted from the Tags taxonomy vocabulary.
Simply rebased the branch @bcgreen created for now.
2.x has been discontinued. 3.x & 4.x are successfully compatible with D10.
Closing this as wontfix.