WKHTMLTOPDF wrong processor type

Scriptcase 8 Bugs
#1

Hello happy scriptcas’ers

I may be wrong but I can’t make pdf export morking in production when hosted by a provider :

  • It works perfectly on my PC ( in prod environment) linux 86 based
  • but when hosted in a provider, The HTML files is created fine, then wkhtmltopdf is invoked and I get a 500 errore telling that “Request exceeded the limit of 10 internal redirects …”

Looking at the log, I can see that :
-in prod environment locally , wkhtmltopdf is invoked with an 86 processor argument so it works but
-in prod environment hosted in my provider , wkhtmltopdf is invoked with an amd 64 (wkhtmltopdf-amd64) while the server I am hosted in is an x86_64 processor
So it can’t work! and there may be a bug somewhere

Now my question to get a workaround waiting for a correction :"is the invoked wkhtmltopdf the right one and Is there a way in scriptcase to force the processor type when invoking wkhtmltopdf ? "

Thanks for your reading

Regards
Gilles BONNET

#2

Hello Gilles,

This problem is due to environmental settings, specifically the Apache.
For this case, i need to be informed of all your environment settings that are happening this problem to be able to simulate.
unfortunately there isn’t a way for the Scriptcase to force the processor type when invoking the wkhtmltopdf.

#3

thanks for your reply Gustavo
Let me spend a bit more time to better track what’s happening : Ill let you know whatever I find or not the error (I agree with you its an environmental issue)
Write to you soon (hope successfully)
Gilles

#4

I did more indepth analysis. I now get rid of the 500 error. Now I have a non existing pdf file error message (was a config error from hosting)
Also checked all permissions and executable /tmp and /third as well.
I always get the html but never get the pdf
“funny” thing is that wkhtmltopdf program is not launched at all : I even renamed all of them to be sure and there has been no change !!!

So I guess there is a path problem to reach the wkhtmltopdf program

What I dont know is how launching a program with ./my_program the system is able to locate it in /my_absolute_path/_lib/prod/third/…
Error log from my provider does’nt help me

Regards

Gilles

#5

Hello Gilles,

How are you?
Can you send me a printscreen showing how the error is appearing, please?

#6

hello
I have gone through the php code for debugging and traced the wkhtmltopdf .
Everything went fine but the pdf file was always missing in tmp directory

At the end I found that the wkhtmltopdf program located in /third/… could not be executed because it was not allowed by my service provider (only basics such as shell commands are allowed)

As far as I know, he claims that servers are hosting web applications but not compiling or executable apps (!)
(btw- i Tried to put the program in other areas than /www and patch the php code butstill unable to exec())

… And i think this is the reason why some others complain against the pdf export : there are other providers that disallow to exec() …

Now I have not so many options :

  • find another service provider ( I am currently using OVH in France) but this is a customer decision
  • find a kind of pdf server machine but I dont know if scriptase easily works with a remote server (and how it is built)
  • try to find an htmltopdf which is not a binary (i heard about fpdf or like) but am not aware of those tools and I think scriptcase is not meant to use an external built for creating pdf
    soooo am a bit pessimistic

topic closed…

Gilles Bonnet

#7

Hello

Finally, I made it work !! Here is what I have found and what I did :

  1. I did carefully checked the permissions of the wkhtmltopdf : mainly the execution (rwxr-xr-x) of the biraries (-i_86 end amd-64)

  2. Wrong processor type
    My service provider uses the virtual machine concept so Scriptcas was detecting a 64 bits processor whereas the right one is a 32 bits

So Idid the dollowing hack : I renamed the binary (_lib/prod/third/ linux-amd64/wkhtmltopdf/wkhtmltopdf-amd6 into a .SAV and copied the 86 one in place of the amd64…
Of course this has to be done for each deployement

  1. and at last, I made a diff between the uploaded and the local binaries and there was discrepancies : yjis was due to my ftp client program which did upload in an ASCII instead of binary !! : this explains why wkhtmltopdf was correctly executed in local (files are locally unzipped) but was wrong after uploading files in a server !!

Then, the pdf went fine !

Hope it help
Enjoy
Gilles Bonnet