Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
I think mpark has highlighted a massive opportunity to greatly improve the flexibility of this module without having to do any heavy lifting.
Rather than have the default template have a hard coded order detail table as it does currently, the module could include a View that is embedded in the email. This view can then be overridden/modified by end users who arent comfortable with code.
This would greatly increase the flexibility, and alleviate issues raised in other issues, such as the hard coded styling issues (http://drupal.org/node/1332698). People would no longer need to hack the module, and further they can include any custom product attributes, currency styling etc will also be properly handled (at present it doesnt pass through commerce_currency_format so doesnt pick up the proper currency formatting).
I think this path is far more aligned to the general approach of Commerce in maximising the use of views to display information and thus allow easy end user overriding.
All that would be required to implement this is to remove the entire
html from commerce-order-email.tpl.php and replace with
Hmma major stumbling bog for this may be permissions.
If a user is not logged in and processes an order, the view wont be able to access order information as anonymous can't view orders (for obvious reasons).
I would love to see this feature. It would be far easier to override and add fields which are not core to commerce line items.
essbee:- I'm not in a position to test, but from memory a fielded view with "disable sql rewriting" should be sufficient to bypass access issues. So long as the view does not declare a page it shouldn't really throw up any security issues, as this module would be the only point of execution.
If someone undertakes this i recommend highlighting the security issue in the description of the module, to prevent accidentally creating it as a page.
Comments
Comment #1
Prague man commentedsorry, if you have use vbo views, must write this function e.g.:
print views_embed_view("commerce_vbo_views_orders", "block_1", $order->order_number);
instead:
print views_embed_view("orders", "block_1", $order->order_number);
Comment #2
essbee commentedI think mpark has highlighted a massive opportunity to greatly improve the flexibility of this module without having to do any heavy lifting.
Rather than have the default template have a hard coded order detail table as it does currently, the module could include a View that is embedded in the email. This view can then be overridden/modified by end users who arent comfortable with code.
This would greatly increase the flexibility, and alleviate issues raised in other issues, such as the hard coded styling issues (http://drupal.org/node/1332698). People would no longer need to hack the module, and further they can include any custom product attributes, currency styling etc will also be properly handled (at present it doesnt pass through commerce_currency_format so doesnt pick up the proper currency formatting).
I think this path is far more aligned to the general approach of Commerce in maximising the use of views to display information and thus allow easy end user overriding.
All that would be required to implement this is to remove the entire
A default view named order_invoice_detail or similar would then be provided by the module.
Thoughts?
Comment #3
essbee commentedHmma major stumbling bog for this may be permissions.
If a user is not logged in and processes an order, the view wont be able to access order information as anonymous can't view orders (for obvious reasons).
Any thoughts?
Comment #4
Darren Shelley commentedI would love to see this feature. It would be far easier to override and add fields which are not core to commerce line items.
essbee:- I'm not in a position to test, but from memory a fielded view with "disable sql rewriting" should be sufficient to bypass access issues. So long as the view does not declare a page it shouldn't really throw up any security issues, as this module would be the only point of execution.
If someone undertakes this i recommend highlighting the security issue in the description of the module, to prevent accidentally creating it as a page.
Comment #5
geek-merlinpatch to test in #1508052: replace order token with view