Could be added some new method then?
There is an use case → for getting values from particular Views row programatically.
The patch provided at that issue contains source code, that calls this method (indirectly).
Maybe there can be a new public method like i.e. Drupal\views\Plugin\views\field\FieldHandlerInterface::getRowValue that would quarantee, that result contains just values from particular row?
@mkalkbrenner:
Default Content is designed to deploy default content once, for example when a module or profile gets installed or updated.
Default Content Deploy is designed for continuously "synchronizing" content between multiple systems.
Do these scenarios require different formats?
I think, the event itself is not an issue. It is only about to add Drush command (or event, hook) to execute export/import on another situation.
Maybe there can be done some deeper analysis to compare both these modules, and join forces to work on one of them ;)
Both modules have their own Importer and Exporter classes, I haven't inspecting them further.
tomas.teicher → created an issue.
For me, the #5 solution works OK, but not for multivalue field. When I start to type a text in the textfield, and this text is found in some particular entity, it returns all field values from an entity as one text, where field values are separated with comma.
Example:
Entity A has field values:
- Paris
- London
- New York
Start typing "Lond" in entity B, and autocomplete will return: "Paris, London, New York". This happens even when "Display all values in the same row" option is unchecked in View field settings.
The problem is in Views itself, in particular in Drupal\views\Plugin\views\field\FieldPluginBase::getValue method. it ignores "same row" option and always returns all field values (from particular entity) in the same row.
When using "advancedRender" method, as it is done in this patch, then the mentioned problematic Views method is called, too.
I have no idea, how to solve it, without changing something in Views, anyway.
tomas.teicher → created an issue.
As I mentioned in task description, the same feature is offered by "default_content" module.
Is it even suitable to duplicate the feature within this module?
I have unasigned from this issue for now, can be explained difference to similar module explained first?
There is an existing issue for modules comparison:
https://www.drupal.org/project/default_content_deploy/issues/3407201
💬
Some comparison and usage befit with similar module
Active
Maybe the task can be generalized to compare multiple deploy modules, i.e. https://www.drupal.org/project/default_content →
In fact, there is quote a bunch of content deploy modules:
https://www.drupal.org/docs/comparison-of-contributed-modules/comparison... →
Hi @mkalkbrenner
I have already pushed the code to fork branch, can you pls check?
(I don't have permission to create merge request).
I have mistakenly created another branch (3474673-drush-command-entity-option). I didn't notice you have created one before. The branch (3474673-drush-command-entity-option can be removed then.
tomas.teicher → changed the visibility of the branch 3474673-drush-command-entity-option to hidden.
tomas.teicher → created an issue.
tomas.teicher → created an issue.
Maybe the feature can be generalized to export all entities that match result of some specific view? Then the filter by some particular field can be set inside this view.
Sorry, my bad, everything works OK, I misunderstood $access->isAllowed() method.
Issue can be closed (works as designed).
tomas.teicher → created an issue.
"...having a multilingual site with 20 languages, and 30 vocabularies, leads to 600 pattern rules...."
Not necessarilly, one pattern can be applied to multiple languages. There is "Languages" field in pattern edit form. The problem, you described, occurs in specific situation, when pattern contains some static string (not just tokens).
#16 patch works OK, but it is checking integrity only on entity edit forms.
I have added some functionality to cover integrity checking, when unpublishing is executing by two other ways:
- by Drupal Action (i.e. when content is unpublishing by Views bulk operation)
- When content is unpublishing programatically (I have added check by hook_entity_presave() implementation.
I have added some new classes to the patch. The code can be further simplified but it can be solved by some another issue after some discussion, how to achieve it). I think, the code for checking integrity should be in separated class and not in action plugins. but it can be solved in some another issue.
Why is the list on /admin/modules page not enough? You can just focus on not-installed modules there.
It looks like issue not related to this module. It is probably related to "Field UI" module - it has its own routes with following pattern:
entity.{$entity_type_id}.field_ui_fields
Where "paragraph_types" is one of entity types.