jmee → created an issue.
jmee → created an issue. See original summary → .
As far as I can tell, this is likely an issue with the way that Commerce builds the route - I notice that there's an attempt to build the link to the entity creation page in content_entity_clone.module, which notes that there is no consistent way that this is done.
In Commerce, I think that there is an 'add-form' link defined in Drupal\commerce_product\Entity (in the product submodule), not sure if there's a straight foward way to account for commerce products here.
Here's my 10 minute workaround - add a link in a block using a view with a contextual filter :
langcode: en
status: true
dependencies:
module:
- commerce
- commerce_product
- user
id: product_clone_button
label: 'Product Clone Button'
module: views
description: 'This view is a workaround for https://www.drupal.org/project/content_entity_clone/issues/3344584'
tag: ''
base_table: commerce_product_field_data
base_field: product_id
display:
default:
id: default
display_title: Default
display_plugin: default
position: 0
display_options:
title: 'Product Clone Button'
fields:
title:
id: title
table: commerce_product_field_data
field: title
relationship: none
group_type: group
admin_label: ''
entity_type: null
entity_field: title
plugin_id: field
label: ''
exclude: true
alter:
alter_text: false
text: ''
make_link: false
path: ''
absolute: false
external: false
replace_spaces: false
path_case: none
trim_whitespace: false
alt: ''
rel: ''
link_class: ''
prefix: ''
suffix: ''
target: ''
nl2br: false
max_length: 0
word_boundary: true
ellipsis: true
more_link: false
more_link_text: ''
more_link_path: ''
strip_tags: false
trim: false
preserve_tags: ''
html: false
element_type: ''
element_class: ''
element_label_type: ''
element_label_class: ''
element_label_colon: false
element_wrapper_type: ''
element_wrapper_class: ''
element_default_classes: true
empty: ''
hide_empty: false
empty_zero: false
hide_alter_empty: true
click_sort_column: value
type: string
settings:
link_to_entity: false
group_column: value
group_columns: { }
group_rows: true
delta_limit: 0
delta_offset: 0
delta_reversed: false
delta_first_last: false
multi_type: separator
separator: ', '
field_api_classes: false
type:
id: type
table: commerce_product_field_data
field: type
relationship: none
group_type: group
admin_label: ''
entity_type: commerce_product
entity_field: type
plugin_id: commerce_entity_bundle
label: ''
exclude: true
alter:
alter_text: true
text: '{{ type__target_id }}'
make_link: false
path: ''
absolute: false
external: false
replace_spaces: false
path_case: none
trim_whitespace: true
alt: ''
rel: ''
link_class: ''
prefix: ''
suffix: ''
target: ''
nl2br: false
max_length: 0
word_boundary: true
ellipsis: true
more_link: false
more_link_text: ''
more_link_path: ''
strip_tags: false
trim: false
preserve_tags: ''
html: false
element_type: ''
element_class: ''
element_label_type: ''
element_label_class: ''
element_label_colon: false
element_wrapper_type: ''
element_wrapper_class: ''
element_default_classes: true
empty: ''
hide_empty: false
empty_zero: false
hide_alter_empty: true
click_sort_column: target_id
type: entity_reference_label
settings:
link: false
group_column: target_id
group_columns: { }
group_rows: true
delta_limit: 0
delta_offset: 0
delta_reversed: false
delta_first_last: false
multi_type: separator
separator: ', '
field_api_classes: false
hide_single_bundle: false
product_id:
id: product_id
table: commerce_product_field_data
field: product_id
relationship: none
group_type: group
admin_label: ''
entity_type: commerce_product
entity_field: product_id
plugin_id: field
label: ''
exclude: false
alter:
alter_text: true
text: '<a href="/product/add/{{ type }}?content_entity_clone={{ product_id }}" class="btn btn-primary">Clone</a>'
make_link: false
path: ''
absolute: false
external: false
replace_spaces: false
path_case: none
trim_whitespace: false
alt: ''
rel: ''
link_class: ''
prefix: ''
suffix: ''
target: ''
nl2br: false
max_length: 0
word_boundary: true
ellipsis: true
more_link: false
more_link_text: ''
more_link_path: ''
strip_tags: false
trim: false
preserve_tags: ''
html: false
element_type: ''
element_class: ''
element_label_type: ''
element_label_class: ''
element_label_colon: false
element_wrapper_type: ''
element_wrapper_class: ''
element_default_classes: true
empty: ''
hide_empty: false
empty_zero: false
hide_alter_empty: true
click_sort_column: value
type: number_integer
settings:
thousand_separator: ''
prefix_suffix: false
group_column: value
group_columns: { }
group_rows: true
delta_limit: 0
delta_offset: 0
delta_reversed: false
delta_first_last: false
multi_type: separator
separator: ', '
field_api_classes: false
pager:
type: none
options:
offset: 0
items_per_page: 0
exposed_form:
type: basic
options:
submit_button: Apply
reset_button: false
reset_button_label: Reset
exposed_sorts_label: 'Sort by'
expose_sort_order: true
sort_asc_label: Asc
sort_desc_label: Desc
access:
type: perm
options:
perm: 'clone content entities'
cache:
type: tag
options: { }
empty: { }
sorts: { }
arguments:
product_id:
id: product_id
table: commerce_product_field_data
field: product_id
relationship: none
group_type: group
admin_label: ''
entity_type: commerce_product
entity_field: product_id
plugin_id: numeric
default_action: default
exception:
value: all
title_enable: false
title: All
title_enable: false
title: ''
default_argument_type: product
default_argument_options: { }
default_argument_skip_url: false
summary_options:
base_path: ''
count: true
override: false
items_per_page: 25
summary:
sort_order: asc
number_of_records: 0
format: default_summary
specify_validation: false
validate:
type: none
fail: 'not found'
validate_options: { }
break_phrase: false
not: false
filters:
status:
id: status
table: commerce_product_field_data
field: status
entity_type: commerce_product
entity_field: status
plugin_id: boolean
value: '1'
group: 1
expose:
operator: ''
operator_limit_selection: false
operator_list: { }
style:
type: default
row:
type: fields
query:
type: views_query
options:
query_comment: ''
disable_sql_rewrite: false
distinct: false
replica: false
query_tags: { }
relationships: { }
header: { }
footer: { }
display_extenders: { }
cache_metadata:
max-age: -1
contexts:
- 'languages:language_content'
- 'languages:language_interface'
- url
- user.permissions
tags: { }
block_1:
id: block_1
display_title: Block
display_plugin: block
position: 1
display_options:
display_extenders: { }
block_hide_empty: true
allow:
items_per_page: false
cache_metadata:
max-age: -1
contexts:
- 'languages:language_content'
- 'languages:language_interface'
- url
- user.permissions
tags: { }
I'm having the same issue (Drupal 9.5.9, PHP8.1, content_entity_clone 1.0.2)
After enabling and configuring cloning for a Product bundle, there aren't any changes to the UI (no clone tab while viewing a single product, no clone task for the operations in the drop button while looking at the product overview).
If I manually construct the link, like https://example.com/product/add/default?content_entity_clone=12345, everything works perfectly as expected, so that's great! We're just missing a way for content editors to get there.
Just applied the patch and find the changes for "Commerce order" to work pretty much as expected, awesome! Thanks for this patch!
I'm having issues trying to use the new "Commerce order" policy type, it seems that the email is using the commerce_order.html.twig template, which is the default entity display for the order entity.
My use case: I have a functioning template in my theme called commerce-order-receipt.html.twig and I was hoping to use a mailer policy to customize the BCC and Subject depending on the order type, but to continue using the Body from my custom template (ie. not add a body element to the policy).
In the theme debug:
THEME HOOK: 'commerce_order'
FILE NAME SUGGESTIONS:
* commerce-order--5--email.html.twig
* commerce-order--5.html.twig
* commerce-order--download--email.html.twig
* commerce-order--download.html.twig
* commerce-order--email.html.twig
x commerce-order.html.twig
If I customize any of these templates, I'll be changing how the site displays orders. I also don't have access to the same variables as the commerce-order-receipt template.
This template is called by email.html.twig:
THEME HOOK: 'email'
FILE NAME SUGGESTIONS:
* email--commerce-order-type--resend-receipt--download.html.twig
* email--commerce-order-type--resend-receipt.html.twig
* email--commerce-order-type.html.twig
x email.html.twig
Again, not really a feasible option.
It seems like the intended use case for this patch is new users of Commerce, so existing users of commerce and symfony_mailer may have a hard time taking advantage of the features. In order to use the Commerce order policy type, the body content *must* be added as a policy element and it is not possible to use a twig template -- is that correct ?
If so, I think there's a good argument to change this behaviour and instead fall back to the default commerce-order-receipt template
in mailchimp version 2.2.0, composer.json and ludwig.json differ:
composer.json requires 3.0.0-rc4 :
],
"require": {
"thinkshout/mailchimp-api-php": "3.0.0-rc4"
}
}
ludwig.json requires 2.0.0 :
{
"require": {
"thinkshout/mailchimp-api-php": {
"version": "v2.0.0",
"url": "https://github.com/thinkshout/mailchimp-api-php/archive/v2.0.0.zip"
}
}
}
thank you for taking the time to respond here! I thought I understood by now I'm more lost. It sounded like a user needs to enter a value from the render array, but now it seems that is wrong as well.
Is it possible to explain what a user is supposed to enter in the Field name field on this action in order for the action to run ?
If it's not something that can be explained, or if it's something that changes drastically depending on the situation, then there's not a field label or help text or even documentation that will solve the issue. If this is the case, I'd lean towards identifying this as a bug, rather than a documentation issue.
Changing the help text / documentation seems like the minimum here. Using submit would have been my first guess, but the way it is currently written is actively misleading.
The field label here ('Field name') is also pretty ambiguous. There's nothing here that is actually telling a user what is needed.
If this action needs the input's #name key from the form render array, why not just say that ?
Thanks again! I'd love to better understand this topic.
Changing the value in "Field name" on the eca_form_field_disable to `submit` worked, thanks for that tip!
Maybe the help text could be improved, I wouldn't have thought that `op` was correct if not for a message in the ui telling me to use the name attribute.
The current help text is:
The input name of the form field. This is mostly found in the "name" attribute of an form element. This property supports tokens.
And the input element is:
<input data-drupal-selector="edit-submit" type="submit" id="edit-submit" name="op" value="Save" class="button button--primary js-form-submit form-submit">
In this situation the type attribute was what worked. Is this always the case, or are there situations where we would need to use a different attribute value ?
Thank you for such a quick response!
jmee → created an issue.
I think that this is related to issues with the actual files on the server - corrupted files that cannot be read, extensions that are not allowed, etc. In my case, this is an old site and it's not surprising that there are issues with some files, and I'm running into issues when trying to look at unmanaged files with other modules (like unmanaged_files and fancy_file_delete).
However, the media_library_importer behaviour is the same whether or not 'Import unmanaged files' is selected.
I've also tried changing the path in the 'Import from folder' field to a directory that only contains valid files with a few different results. In one case, I pointed the import to a folder that contained a png and a pdf with the same result as above. There were journal entries for "Checking existence of" for both files, but only one success message for "Adding file.png to queue for new media entity creation" (for the png file).
When I pointed it to a folder that contained only mp4 files, the imported worked! It seems like the import fails for pdfs, even though that is an allowed file type.
@mhespanhol that's awesome!
I'll chime in to provide some more information on potential use cases for this module / ckeditor4 content templates plugin!
My use of this module has always required the ability to add formatted content within templates, so ckeditor5_embedded_content isn't a replacement. I'd argue that Embedded Content provides a different feature, though I can understand how some uses of content templates could overlap.
One, fairly typical, use case for us is to format columns via templates. This means adding a few divs with specific classes (usually using bootstrap row + column markup) and the client replaces the placeholder text with their own content. Media can be embedded within the template using the Media Library and other templates can even be nested. We'll often create a template for a 'boxed' section (aka a div with classes that add a border, background colour, or padding, etc.) which could be used within a column, or a row of columns could be inserted within the 'boxed' section.
It's a fairly straightforward way to make the layout of a page more interesting and give the client a bit more control over their content, though it is of course a feature only requested by clients who are working with their site regularly and are motivated to experiment a little bit. Sometimes, it's just a way for us to get someone using tables as layouts to kick that habit. These templates can't be added as styles, they're just a little too complex for that, but are still simple markup that can easily be integrated in a new theme when the client wants to do a redesign.
Another way that we might use content templates is to reproduce layout components. If we're using a framework like bootstrap, we can add templates for alerts, cards, list groups, etc. to allow the user to take advantage of those components. In some cases this could be done with embedded media, but only with limitations, since we want the user to be able to format the text within these components.
Perhaps worth noting, right now the embedded content module requires a patch to core in order to function properly, which is not always possible (ie. in managed hosting environments): https://www.drupal.org/project/ckeditor5_embedded_content/issues/3306230 ✨ It is not possible to have the embedded content modal open another modal. Needs review
Which unfortunately makes it a poor replacement for a use case where the ability to embed media within templates is required.
Here are some examples where the migration definition file has been edited, but I think it would be better to use hook_migration_plugins_alter if you need to apply this change everywhere
In my example, the D7 source site's text formats weren't migrated properly when the site was upgrade to d7, so machine names are in the d6 format.
Node body field:
process:
body:
-
plugin: sub_process
source: body
process:
value: value
format:
-
plugin: static_map
bypass: true
source: format
map:
'1': 'basic_html'
'2': 'full_html'
'3': 'plain_text'
'4': 'plain_text'
default_value: 'basic_html'
Term description field:
process:
description/value:
-
plugin: get
source: description
description/format:
-
plugin: static_map
source: format
map:
'1': 'basic_html'
'2': 'full_html'
default_value: 'basic_html'
Or a simple default value also works:
process:
description/format:
-
plugin: default_value
default_value: 'basic_html'