Add Export to Word Support

I do like this idea, initially I was always going to make this module a generic print module but as you point out, I've moved towards been specific to PDF, given I think we should replace Print in D8, i'd like to formalise a proper way forward.

I'm on holiday until 4th June so I have limited availability until then but I will definitely come back to this in the next week or two.

I have a couple of questions that will help architect this change:

1. Do all formats convert from HTML to destination format? That's how the PDF ones work now, but maybe we'll need a new abstraction?
2. We already provide the PdfEngine as a plugin type, so we could provide a new plugin type per rendering destination. E.g. WordDocEngine, EpubEngine this would solve our only 1 per type issue. If these plugins worked with HTML, we'd be able to re-use all the current Rendering* interfaces for converting from entities to HTML.
3. Can we make a list of all the proposed formats and at least one common library for each?
4. Shall we create a new meta issue for introducing new formats and make this a child issue specific for Word?

This is a pretty exciting change, thanks for suggesting it, we may have to create an 8.x-2.x branch, i'm not sure yet.

What's the URL you're trying to hit?

@jordanpagewhite now we have the config and the renderer refactoring in, do you want to try re-roll this?

I can try helping with this but can anyone give me an update on how to apply these? It looks like these were against the early stages of 2735875 which has massively changed?

You have two options, either checkout a commit close to when this was last applied and then rebase/merge HEAD and resolve the conflicts or you can just copy and paste the relevant parts out of the above patch into your project and construct a new patch from scratch.

Thanks for chipping in.

I looked at the patch and there was lot of stuff that has already been committed so I pulled out just the plugin into a new patch. I tested quickly and the code executes but the outputted document seems to empty, i'm not familiar with the library and didn't look any further.

I think we should leave the new actions to #2762093: Provide VBO actions for each export type

I've also moved the deliver method into the try/catch to make sure we gracefully handle any errors from the print engines.

Fix test.

Okay I tried it out and here is my feedback:

Breaking issues:
- Breaks with twig debug on! (PhpWord complains Warning: DOMDocument::loadXML(): Double hyphen within comment:

-> )

Some other notes that I have. These are more minor:
- Cannot use php7 (upstream issue, but it's broken with the version that's recomended to install) - see https://github.com/PHPOffice/PHPWord/issues/736
- Another issue that I"m pretty sure is just an upstream issue, but right now when I export a node the

To elaborate on the issue regarding the HTML tag, it appears that PHPWord uses DOMDocument::loadXML to parse the node. But, loadXML has limited support for HTML5. In many instances during my testing, the parser was unable to read the source code, and the Word document failed to generate.

Dompdf uses the html5lib parser and does not seem to have the same issues as PHPWord.

As a solution, would it make sense to clean the HTML prior to sending to PHPWord? Or at a minimum validate that the file can be parsed by loadXML prior to sending to PHPWord?

I'd be open to trying to detect breakages here for now but ideally PHPWord would throw errors that we could catch in all cases where the parsing fails and then we'd make an upstream PR to replace their using of ::loadXML with html5lib?

I agree that PR would be best. I've opened an issue with PHPWord (https://github.com/PHPOffice/PHPWord/issues/836) to see if they would be willing to replace the parser.

In the meantime, for those interested, I was successful in altering PHPWorld/Shared/HTML to use the Masterminds\HTML5 library to parse the HTML content and generate a Word document.

Woops I also forgot this in my notes but it sounds like it would be fixed if upstream expands to html5 but this is a quick one:

- Was complaining about meta tag not being closed in entity-print.html.twig (<meta charset="utf-8"> -> <meta charset="utf-8"/>)

Let me know if you don't have time to tackle anything and I'll help out with it

Feel free to create a new issue for the meta tag and we can get that fixed.

Also, i'm happy to accept workarounds if that is possible to get the PHPWord integration committed, the upstream issue could take a while.

Support for the HTML conversion is limited with PhpWord. Here are a few challenges that I'm currently facing:

• No support for HTML5
• No support for CSS
• Limited support for inline styles

No support for HTML5
I believe this issue should be resolved in PhpWord, not this module. As mentioned above, introducing a new HTML5 parser (Masterminds) to PhpWord seems to be a good first step. More work needs to be done to fully replace the existing parser. If you want to fix the issue within this module, we will need to convert the HTML created in RendererBase prior to sending to PhpWord.

No support for CSS
PhpWord has a //todo in their HTML reader to create a stylesheet parser. In the meantime, there is no support for CSS. The entity-print.css file is never processed by PhpWord.

Limited support for inline styles
There is an inline CSS parser in PhpWord, although it has limited support for most style types. I've been able to introduce Emogrifier (https://github.com/jjriv/emogrifier) into this module, which converts CSS stylesheets into inline style attributes in the HTML code before sending to PhpWord. I'd like to get your thoughts on this approach. I believe it could be a good approach for handling styling in Word, but also PDF and any other export formats we may want to print in the future.

@benjy - The meta tag issue is related to this issue - it's causing issues with phpword.

@chris.smith In terms of the limited html -> css conversion, I don't think that's as much as an issue if we provide ways to hook into the system and create the docx from the entity instead of using the html -> css conversion. With some notes on this as well as long as each type gets it's own display mode (I noted this is #26, but essentially right now it's using the pdf display mode I think)

I don't think that's as much as an issue if we provide ways to hook into the system and create the docx from the entity instead of using the html

That is against the architecture of this module, I think if you're going that route then this module doesn't really offer you anything. Simply add the composer libraries you want and go it alone.

Based on chris.smith's comments i'm wondering we either don't add PHPWord at all or we add it with an experimental warning and document the current issues?

Eh, I would argue not having having a hook would be against Drupal's architecture. Not using a module because you want to tweak the output a bit because the program doesn't support ALL of what you want and just some of it is not the correct way to do it.

Drupal is all about contributing functionality back - I plan to use this module for a project but then implement more functionality to also save the files to the disk. Under that attitude I wouldn't contribute it back because I shouldn't have used this module to begin with because it's possible I need to fix the output?

Not using a module because you want to tweak the output a bit

This isn't what was suggested, building the printed document from the entity is far from tweaking the output (there are already events for that). If you understood the architecture of this module I think you'd see what I mean.

1. This module providers renderers that handle converting any entity into a renderable array.
2. This module provides a thin wrapper around print libraries that up until now, accept HTML and then handle the conversion or pass to a binary that handles this conversion. HTML is our generic input format to those print plugins if we didn't have a generic input format we'd need our own abstraction for building these documents.
3. PrintBuilder is the class that grabs the renderer, renders the HTML, loads the correct plugin and triggers the sending of the printed object.

If you wanted to use the entity directly then the controllers, renderers, print plugins and PrintBuilder are all useless to you, what you need is your own route, and an instance of the PHPWord object to build your output document.

If you see somewhere we can simply add a hook and your use case works, then absolutely, create an issue and we'll add it. However, make it an event, Drupal is moving away from hooks.

Finally, the last feature you mentioned has an existing issue if you want to contribute: #2571725: Rules action to save PDF to server

Yeah the use case I'm talking about would be altering it during the (2) item (after it gives the external lib the html but before it returns it - generally altering the third party library).

I used hook in a loose term - Also as far as I knew the main reason they aren't more in D8 is because of the speed of them (Hooks are a lot faster) so I'm hoping we can move everything to events but I agree this one should be since it's not called often.

Thanks for the link to the relevant issue, I'll take a look there.

So I think the only things that should be done for this ticket that are left:

1) Close the html tag in that template since it stops it from working. @chris.smith did this not cause an issue for you?
2) @chris.smith Did we ever workout a fix for the twig debugging? Maybe a quick fix for now is to disable twig debugging for the rendering somehow?
3) Mark this is experimental

Then after this is merged in I'll look into:
1) Multiple display modes per library, @benjy any thoughts on this? RIght now it looks like there's only "pdf" and for backwards compatibility I guess we shouldn't change that. Is there a way to have separate twig/display modes files somehow else?
2) Maybe adding a hook/Event to modify the third party plugin before it returns the document

Yeah the use case I'm talking about would be altering it during the (2) item (after it gives the external lib the html but before it returns it

This is already supported see the PreSendPrintEvent which is trigged via PrintEvents::PRE_SEND in PrintBuilder.

Multiple display modes per library, @benjy any thoughts on this? RIght now it looks like there's only "pdf" and for backwards compatibility I guess we shouldn't change that. Is there a way to have separate twig/display modes files somehow else?

The 2.x branch has never had a release and we already have lots of API changes from 1.x so not too worried about that. I think we could easily make a view mode per export type on install and then try and use that? We already do many other things per export type.

@benjy Thanks for that! I actually found this and have been writing down more notes. What I found is that this phpdoc library is very buggy (Doesn't support tables even though there's code for it because of bugs, doesn't support images). I had to patch a few things in it sadly that were fixed in issues. But that's not the point of this thread.

The `PreSendPrintEvent` worked pretty good for the most part. The only issue is that there are two properties on the Doc build print and section that need to be public. Once we do that then I think my request for that is fine.

One major but quick issue I found when running xdebug: The Doc Builder is saving the file as 'tmp-file'in the root of the drupal site when building which is a security concern. Should be moved to the true tmp directory.

The last annoying thing is that at the very least I wanted to find a work around for the twig debugging issue and disable twig debugging and then re-enable it after. Not sure how easy that is and it can probably be moved to a new bug after this is released if you wanted to mark this as experimental.

The view mode something is something i'd recommend doing as well but is there a way that in the node/entity rendering process to tell if it's being printed in entity print and by what builder? That may work as well but since there's already the pdf view mode we might as well just add the others or deprecate 'pdf' and switch to a display mode that's standard for all prints and then just provide a way to see the builder somehow in case developers need this

is there a php library for word doc support ?

The documentation claims that this feature is in "active development". Any progress?

Is any working libarary available for .docx(word ).Please share any developing/developed library for the same.

This is far from critical.

Could someone provide us the status? Are we able export to word like pdf with this module currently?

@benjy in addPage method
public function addPage($content) {
// @TODO, this only supports adding one page?

Html::addHtml($this->section, $content, TRUE);

}
only supports one page html document.how can we add multiple page??

Patch #25 is outdated
I've tried to make it works and didn't get success.
More over I got at least incompatibility code issue. Methods getPrintObject and getBlob has to be implemented accordingly to PrintEngineInterface.

I've also faced with issue that PHPWord library return empty document when it's trying to convert.

Please check rerolled patch.

Is it just me or has anyone else noticed that text in heading tags e.g. H2, H3, etc, don't get converted to headings in Word, and that there appears to be quite a bit of white-space, I'm assuming these are issues with the underlying library but wondered if anyone else had overcome this?

Thanks

Please, can you explain how to test this patch?

I´ve tried to install the entity_print 8.x-2.x-dev, install the PHPWord by Composer, applied the patch #47 (but with error), and no options to Word Document engine for printing.

[# entity_print]$ patch < 2733781-47.patch
patching file EntityPrintPHPWord.php
patching file WordDocx.php
can't find file to patch at input line 154
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/tests/src/Kernel/EntityPrintPluginManagerTest.php b/tests/src/Kernel/EntityPrintPluginManagerTest.php
|index 9dda0cb..fd4f204 100644
|--- a/tests/src/Kernel/EntityPrintPluginManagerTest.php
|+++ b/tests/src/Kernel/EntityPrintPluginManagerTest.php
--------------------------
File to patch:
Skip this patch? [y] y

Please try apply patch like here
patch -p1 < path/file.patch

will this patch be committed to the stable version?

I has patched with 2733781-47.patch the entity_print 8.x-2.x-dev version.
When I select in admin/config/content/entityprint Word Document = Word docx;
Here is the error message :

Notice: unserialize(): Error at offset 1992 of 13583 bytes in Drupal\Component\Serialization\PhpSerialize::decode() (line 21 of core/lib/Drupal/Component/Serialization/PhpSerialize.php).
Drupal\Component\Serialization\PhpSerialize::decode('a:9:{s:10:"build_info";a:4:{s:4:"args";a:1:{i:0;O:40:"Symfony\Component\HttpFoundation\Request":23:

Then a fieldgroup appears "Word Docx Settings" but there is nothing inside...

Export to Word works fine for me using latest Entity Print 8.x-2.2 with PHPWord 0.18.1 - also the "Word Docx Settings" fieldgroup is empty.

#47 worked for me, but only with the latest phpword library, so running composer require "phpoffice/phpword" seemed to do the trick by accessing /print/word_docx/node/NID after configuring the engine.

How create template for docx?

Patch applied to 8.x-2.4 and prints docs from entity on D 9.2.9. Thank you.
(Haven't tested views, yet)

#57 activating the PDF display mode breaks the print for word.

 	Drupal\entity_print\PrintEngineException: Invalid parameters passed. in Drupal\entity_print\Plugin\EntityPrint\PrintEngine\WordDocx->send() (line 74 of /html/modules/contrib/entity_print/src/Plugin/EntityPrint/PrintEngine/WordDocx.php).

There is no display mode for WORD?

Patch from #47 is outdated and doesn't apply to Entity Print 8.x-2.4. Should this work out of the box now with PHPWord 0.18.3? "Word Docx Settings" fieldgroup is empty for me and I get:

Drupal\entity_print\PrintEngineException: Please configure a word_docx print engine

Patch from #47 is outdated and doesn't apply to ... if you have previously applied the patch 2 of the files already exist.
Errors are only that they cannot be regenerated, because they are already there.

This is a re-roll of the patch in #47, with one or two minor bugs fixed, and brought up to Drupal coding standards (more or less). It applies cleanly to version 2.5.

Thank you Daniel_j.
That patch is applying well.

I tried #61 and added a word export to a view.
It generates a Word document - but an empty one.

The word may come out empty if you have controls that are not standard fields - in my experience.
But I never had the time to thoroughly investigate the issues.

Based on #61, I added the fact if no <body> is present.

I do not see any of the settings when I select the Word Docx library.

I have applied the patch #69 and selected the engine for word export.

But got this error while exporting the entity as a Word doc.

TypeError: Cannot assign array to property DOMDocument::$preserveWhiteSpace of type bool in PhpOffice\PhpWord\Shared\Html::addHtml() (line 83 of

Added the output escaping option and removed the problematic code related to the styling to fix the error from #71.

When I try to set the Word Document engine to Word Docx and submit the settings form, I am greeted with the following error on Drupal 9.5.4 on PHP 8.0.27:

TypeError: Illegal offset type in Drupal\Core\Entity\EntityStorageBase->load() (line 297 of core/lib/Drupal/Core/Entity/EntityStorageBase.php).
Drupal\Core\Entity\EntityStorageBase->load(Array) (Line: 262)
Drupal\entity_print\Form\SettingsForm->loadConfigEntity(Array) (Line: 214)
Drupal\entity_print\Form\SettingsForm->validateForm(Array, Object)
call_user_func_array(Array, Array) (Line: 82)
Drupal\Core\Form\FormValidator->executeValidateHandlers(Array, Object) (Line: 275)
Drupal\Core\Form\FormValidator->doValidateForm(Array, Object, 'entity_print_admin_settings_form') (Line: 118)
Drupal\Core\Form\FormValidator->validateForm('entity_print_admin_settings_form', Array, Object) (Line: 591)
Drupal\Core\Form\FormBuilder->processForm('entity_print_admin_settings_form', Array, Object) (Line: 323)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 169)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 718)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

I assume there's something missing in entity_print.schema.yml.

entity-print-2733781-export-word-72.patch isn't working for me, I get this error:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "Array" plugin does not exist. Valid plugin IDs for Drupal\entity_print\Plugin\EntityPrintPluginManager are: tcpdfv1, phpwkhtmltopdf, dompdf, word_docx in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of /var/www/html/docroot/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

actually it works, but it breaks this page on submit: /admin/config/content/entityprint

Patch #72 caused these errors on saving default `Word Document` at /admin/config/content/entityprint

TypeError: Illegal offset type in Drupal\Core\Entity\EntityStorageBase->load() (line 263 of
 pathto\web\core\lib\Drupal\Core\Entity\EntityStorageBase.php).

Warning: array_flip(): Can only flip string and integer values, entry skipped in Drupal\Core\Entity\EntityStorageBase->loadMultiple() (line 278 of pathto\web\core\lib\Drupal\Core\Entity\EntityStorageBase.php).

form Error The submitted value 1 in the Word Document element is not allowed.

Drupal 10.1.2
entity_print 8.x-2.x-dev
php 8.1.10

Patch 72 on entity_print:2.x-dev on Drupal 9.5.10 and PHP 8.1.21 add the Word Docx engine, but saving the configuration at admin/config/content/entityprint produces 3 errors

1. TypeError: Illegal offset type in Drupal\Core\Entity\EntityStorageBase->load() (line 297 of /mnt/www/html/umnpcid8stg/docroot/core/lib/Drupal/Core/Entity/EntityStorageBase.php)
2. Warning: array_flip(): Can only flip string and integer values, entry skipped in Drupal\Core\Entity\EntityStorageBase->loadMultiple() (line 312 of /mnt/www/html/umnpcid8stg/docroot/core/lib/Drupal/Core/Entity/EntityStorageBase.php)
3. Illegal choice 1 in Word Document element.

Patch #72 on entity_print:2.x-dev, Drupal 9.5.10 and PHP 8.1.21 adds the Word Docx engine, but saving the configuration at admin/config/content/entityprint produces 3 errors

1. TypeError: Illegal offset type in Drupal\Core\Entity\EntityStorageBase->load() (line 297 of /mnt/www/html/umnpcid8stg/docroot/core/lib/Drupal/Core/Entity/EntityStorageBase.php)
2. Warning: array_flip(): Can only flip string and integer values, entry skipped in Drupal\Core\Entity\EntityStorageBase->loadMultiple() (line 312 of /mnt/www/html/umnpcid8stg/docroot/core/lib/Drupal/Core/Entity/EntityStorageBase.php)
3. Illegal choice 1 in Word Document element.

I get the same errors as rimbu002 mentioned. Is there any update on this?

Thanks

I'm working with Patch #72 on entity_print:2.x-dev, Drupal 10.2.1 and PHP 8.1.26.

After installing phpoffice/phpword:^1.0 per installation prompts, I set the Word engine, but threw a "The website encountered an unexpected error. Try again later." error on the config page that would not clear. I uninstalled both Entity Print and Entity Print Views, then reinstalled. Now I can't set the word engine at all - when I click save, it throws the same error on the page, but while I can now refresh, none of the changes are saved.

This produces similar errors to the previous folk, with some differences:

TypeError: Illegal offset type in Drupal\Core\Entity\EntityStorageBase->load() (line 263 of /code/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php).

Warning: Array to string conversion in Drupal\Core\Entity\EntityStorageBase->loadMultiple() (line 281 of /code/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php)

The submitted value 1 in the Word Document element is not allowed.

I retried Patch #72 after upgrading to Drupal 10.2.2. Now I'm down to 1 error:

TypeError: Cannot access offset of type string on string in Drupal\Component\Utility\NestedArray::setValue() (line 155 of /code/web/core/lib/Drupal/Component/Utility/NestedArray.php).

Looking at the console inspector, I also found the following (which does not exist without the patch):

[DOM] Found 2 elements with non-unique id #edit-submit: (More info: https://goo.gl/9p2vKq) <input data-drupal-selector=​"edit-submit" type=​"submit" id=​"edit-submit" name=​"op" value=​"Save configuration" class=​"button button--primary js-form-submit form-submit">

I'm back to the errors I reported in #80.

Has anyone found a solution yet?

patch #72 throws the error as reported above.

However, I did get it to work like this, clearly a workaround.

1) Install entity_print and the word engine.
2) Install patch #69
3) configure the word print-engine in the interface.
4) SAVE
5) (if you print now, it has the previous errors as reported in #71)
6) NOW after you turned on the engine, SWITCH the patch to #72.
7) If you visit the configuration page, it still shows the engine as turned on, with an extra config.
8) Now you can print the doc.

So the point is: you must have the word print engine installed and set in the intetface BEFORE you install patch #72.

Clearly only a workaround.

Took me a while to circle back, but #83 works great. Thanks so much.

Don't know if this is in scope for this issue. But have updated the #72 patch to support inline styles.

This patch have pelago/emogrifier as a suggestion, and if added to the project, it will parse the html and convert css to inline styles.

#83 ist a good workaround, but in Drupal10.3 does not work.

I got an error in this function of WOrdDocx.php

  public function __construct(array $configuration, $plugin_id, $plugin_definition, ExportTypeInterface $export_type) {
    parent::__construct($configuration, $plugin_id, $plugin_definition, $export_type);
    $this->print = new EntityPrintPhpWord();
    $this->section = $this->print->addSection();
    Settings::setOutputEscapingEnabled($this->configuration['enable_output_escaping']);
  }

For testing i used "TCPDF();" instead of "EntityPrintPhpWord();" and the config-site of module entityprint worked for me:
/admin/config/content/entityprint

Did anyone tested it in Drupal10 ?

For Drupal 10.4.3, the latest version of this module and #85 patch does not work. Even both running composer require phpoffice/phpword under the Drupal project root and this module folder, still no options can be selected for the field "Word Document" on the /admin/config/content/entityprint

I've just re-rolled patch from 85 #85 so it works with 8.x-2.x branch. I've also renamed the plugin id and class name because it were conflicting in the settings form producing fatal errors. Now it works fine.

With the patch I've just attached I can successfully enable phpword plugin and also export it to docx.

Please review, thanks!

I created a MR from the patch in #88, with a little bit of coding-standards cleanup. If this gets merged, please be sure to credit @omarlopesino.

I used patch #88 on but it had errors when some HTML items weren't properly closed as required to convert to XML, and images without the path on the server generated PHPWord errors. That's why I added this code to patch #88.

developed on
drupal core: 10.6.2
php ext: tidy
PhpWord: 1.4.0