PDF Export Application not using templates. Can´t update it

It stopped working as I updated my XWiki to 16.4. But before going there, let’s first explain what is happening

At the Administration Panel > PDF Export… I can select one or more templates. It doesn´t change anything.
image

Here is a screen showing the ModeloPDF template
image

When selecting to export any page, the option to choose the template doesn´t appear anymore
image

and when export is complete, it certainly didn´t use my template. Just check foot and headers. Btw, even if I remove the other templates, leaving only mine, it still doesn´t use it.
image

In fact, even I remove ALL templates, it still is able to export a PD, using the default XWiki template. When the Export PDF plugin page says removing all templates should disable PDF export.

Now, regarding extensions… when Updating to 16.4, I was unable to update the Flavor to 16.4. Got several errors.

This is what I get when in the Extensions
image

If I try to update PDF Export Application 16.4 (update to what?) I get several errors.

And it gets stuck.

So I did manually download the PDF Export App 16.4 and imported it.

Still shows to update 16.4.


ps: I tried uninstalling version 15.10.7… and it is just stuck like this for the past 40 minutes.

So my problems go deeper than just the PDF Export not working
image

Did you check the server logs too? May be useful to post them, if they contain errors.

apparently every time I try to export a PDF, it’s generating a similar error

2024-06-07 17:41:28,313 [http-nio-8080-exec-1 - http://192.168.0.95:8080/bin/export/XWiki/ModeloPDF/WebHome?format=pdf&pdfcover=1&pdfcover=0&pdftoc=1&pdftoc=0&pdfheader=1&pdfheader=0&pdffooter=1&pdffooter=0&comments=0&attachments=0] ERROR .f.l.AbstractBaseLayoutManager - Cannot find LM to handle given FO for LengthBase. (fo:table-cell, location: 70:102) 
2024-06-07 17:41:28,313 [http-nio-8080-exec-1 - http://192.168.0.95:8080/bin/export/XWiki/ModeloPDF/WebHome?format=pdf&pdfcover=1&pdfcover=0&pdftoc=1&pdftoc=0&pdfheader=1&pdfheader=0&pdffooter=1&pdffooter=0&comments=0&attachments=0] ERROR .f.l.AbstractBaseLayoutManager - Cannot find LM to handle given FO for LengthBase. (fo:table-cell, location: 73:102) 
2024-06-07 17:41:28,313 [http-nio-8080-exec-1 - http://192.168.0.95:8080/bin/export/XWiki/ModeloPDF/WebHome?format=pdf&pdfcover=1&pdfcover=0&pdftoc=1&pdftoc=0&pdfheader=1&pdfheader=0&pdffooter=1&pdffooter=0&comments=0&attachments=0] ERROR .f.l.AbstractBaseLayoutManager - Cannot find LM to handle given FO for LengthBase. (fo:table-cell, location: 76:121) 

and it seems this error was when I tried to update my PDF Export plugin

Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: The following artifacts could not be resolved: org.xwiki.platform:xwiki-platform-export-pdf-default:pom:16.4.0 (absent): Could not transfer artifact org.xwiki.platform:xwiki-platform-export-pdf-default:pom:16.4.0 from/to maven-xwiki (https://nexus.xwiki.org/nexus/content/groups/public): Connect to nexus.xwiki.org:443 [nexus.xwiki.org/92.222.135.198] failed: Read timed out
	at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:473)
	at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:261)
	at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:243)
	at org.xwiki.extension.repository.aether.internal.AetherExtensionRepository.downloadPom(AetherExtensionRepository.java:792)
	at org.xwiki.extension.repository.aether.internal.AetherExtensionRepository.resolveMaven(AetherExtensionRepository.java:573)
	... 264 common frames omitted
Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not transfer artifact org.xwiki.platform:xwiki-platform-export-pdf-default:pom:16.4.0 from/to maven-xwiki (https://nexus.xwiki.org/nexus/content/groups/public): Connect to nexus.xwiki.org:443 [nexus.xwiki.org/92.222.135.198] failed: Read timed out
	at org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:44)
	at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:417)
	at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:260)
	at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:537)
	at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:449)

do you want me to attach the whole file?

Do you get that all the time? Can you retry? It could have been a transient issue on nexus.xwiki.org.

Thx

It didn´t happen until a few weeks ago, around the time I updated XWiki to 16.4.0*

but since them, I have a hard time installing or updating anything

5 minutes already at this
image

I updated to 16.4 because I was facing some problems with the export.LiveTable to Excel. (which ended up not being caused by the WIki version)

EDIT: after a while
image

The fact that you have problems all the time suggests that the issue is possibly not coming directly from nexus.xwiki.org as we have lots of users using nexus.xwiki.org all the time and it seems to be working fine.

Maybe it’s caused by your IP being blocked. Could you tell us from what part of the world your XWiki instance is sending requests from?

Thx

Novo Hamburgo, Brazil
image

I resolved it… by a makeshift solution… it seems there really is some blocking of XWiki going on with our connection. The IT guy has not found yet where. And it all worked until some 2 weeks ago.

So what we did was idiotic, but it solved the problem in the short term. We connected the VM with the XWiki instance to a wifi routed by my own cell phone lol.

And it just worked. Updated every extension we needed to 16.4. Then we reconnected to the main internet connection. And as always, problems connecting to XWiki servers. So it’s really this. At least it’s updated now.

Maybe Kerio was the issue.

PS: after updating to the latest PDF Export version, it is working like it should again.