Fixing PDF export issues when using a Scriptcase grid application
If you often use Scriptcase to quickly develop CRUD applications in PHP, you must definitely have used the Export feature from a Grid application, and most likely find it very useful as it can export in many different formats such as Office, PDF or event XML:
For most users, the export usually works out of the box and requires little configuration. However, recently in one of my projects, I came across an issue where the exported PDF file was either empty or had very small size such as 37 bytes which contained only the PDF header and was therefore corrupted. The web user interface did not show any useful messages, other than “PDF generation finished.”, and exporting to all other formats still worked well.
To investigate this problem, I checked the Scriptcase temporary folder, which is usually at the /_lib/tmp subdirectory. The full path to the log folder is also indicated in the “Configure production environment” menu after you log in to the Scriptcase production environment, by appending /_lib/prod to the site address.
The following is the screenshot of the configuration settings for Scriptcase v6:
Checking the temporary folder reveals the following files:
The .log file contains the following command, which presumably was used to generate the PDF file. Filenames and related information have been removed for security reasons.
java -Xms128m -Xmx256m -Djava.awt.headless=true -cp .:pd4ml.jar Pd4Php http://www.example.com/_lib/tmp/sc_grid_html_a8647dfca9a1a7861f93ca687eeb1c57.html 800 LETTER -orientation PORTRAIT -permissions 2076 > /home/example/_lib/tmp/sc_pdf_20151208170941_771_grid.pdf
Executing this command by connecting to the web host via SSH, which is a CentOS 6 VPS, result in the following error:
-bash: java: command not found
At this point it is clear what caused the issue. When the user requests to export a grid to PDF, Scriptcase first generates the corresponding HTML document for the grid, then executes pd4ml.jar with the help of Java to convert the HTML file to PDF. The conversion failed simply because Java was not installed on the server.
To fix this, we need to install Java. Take note that the following command is just an example, you might need to customize it based on your further needs, for example which version of Java needs to be installed and whether you will just need the Java Runtime Environment (JRE) or the full development kit (JDK). In our case, just the JRE is needed to execute the Scriptcase jar program. We proceed by installing the default Java package that comes with the OS:
sudo yum install java
Once installation is completed, try again – PDF export should work. If it doesn’t, check the URL that was passed in to pd4ml.jar (e.g. http://www.example.com/_lib/tmp/sc_grid_html_a8647dfca9a1a7861f93ca687eeb1c57.html) and make sure that you can download from it. If the URL is not correct, check the “PDF Server IP” field in the Scriptcase configuration settings. Contrary to what the name of the field may tell you, this has to be the root address of the server where the site is deployed, which can be an IP address (for test servers), or a domain name (for production servers). For example, if the deployed URL is http://www.example.com/script_case_app, enter www.example.com into the “PDF Server IP” field.
If it still doesn’t work, try to run the export command directly on your server to find out the exact error message. You might need to field in the full path to Java for the “Path for Java binary” and the “Java Binary” fields, although in my case I can just leave them as default since Java is in the system path.
If you are using Scriptcase v8, you will notice that the Java-related fields are removed from the configuration screen:
The export command now instead calls a tool named wkhtmltopdf directly to perform the conversion:
./wkhtmltopdf-amd64 --page-size Letter --orientation Landscape --outline-depth 0 --header-right "[page]" http://example.com/myapp/_lib/tmp/sc_grid_html_2fbff2b18e8a12a76de439a72c7907a1.html /home/example/public_html/_lib/tmp/sc_pdf_20151208173442_943_grid.pdf
The wkhtmltopdf tool is located in the _lib/prod/third/wkhtmltopdf folder, with different versions for different operating systems (Linux, OS X, Windows) and helps remove the need for Java, which may not be possible for users on shared web hosting services. If you still cannot export to PDF on Scriptcase v8 despite setting correct value for the “PDF Server IP” field, try to set the permissions of the wkhtmltopdf utility to 777, e.g. allow all read/write/execute permissions for everyone. This can be done by connecting to the server via SSH, or by using an FTP client such as FileZilla that supports setting file permissions.
Interestingly, exporting to other format such as Word, Excel or RTF does not require setting up the permissions or installing Java, at least for my case, even though the Scriptcase tools folder contains phpexcel and similar utilities, presumably for exporting purposes. I also found out that the exported documents are generally well-formatted, except when the grid has too many columns, in which case the page orientation of the Word document may need to be changed to landscape. For PDF documents, there is no easy way to change the page orientation and this is something I hope will be improved in the next Scriptcase version, for example, by allowing users to select between portait/landscape orientation before exporting.
In my SC8.1, Ubuntu 14.04, Oracle Java8 environment, the solution simply was
apt-get install libxrender1
(because this package wa missing.
Hi Adnan, thanks for sharing
Thank you, has been solved perfectly with this tutorial, very good!
how to merge the exported pdfs (say, its a 2-page invoices)?
Thank you , great solution for a common problem on Scriptcase 8.
I am currently using scriptcase 9.1.001, I have the same issue. The PDF is getting generated properly in my Development Environment. I use MySQL as the database. The problem is in Production. When I export the Grid to Excel it works perfectly in Production. However if I export to PDF, then I am getting the message unable to open PDF as the file size is Zero. Also when I click View PDF I am getting the following Error
The requested URL /home/_lib/tmp/sc_pdf_20180515015554_360_non_member_ledger.pdf was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
I have made sure the following
My Production Environment is updated with proper tmp folder and also PDF Server IP is properly set to my shared hosting IP (I tried with IP as well as hostname both does not work)
My /home/lib/tmp folder has 777 permission
My /home/lib/prod/third/wkhtml2pdf has 777 permission
I don’t know what else to do
Any help would be highly appreciated.
Hi,
Try to check the Scriptcase log to find out the actual command that is used to generate the PDF file, and check whether the URL to the HTML file passed by Scriptcase to the PDF tool is actually accessible.
if you are on a shared hosting service, you must use a domain name. Entering IP won’t work as shared hosting used virtual host configuration and many sites could be sharing the same IP address. Additionally, make sure that whatever folder Scriptcase decides to create the temporary files in is actually accessible via http. For example, if your site is http://www.example.com which points to /home, and the Scriptcase attempts to create the temporary files (HTML, PDF) in /home/lib/tmp, make sure that all files under that folder is accessible from http://www.example.com/lib/tmp.
Hope this helps.
Hi, This is really helpful and I have now entered the domain name. But this is in https://my-domain.org (not the actual name). Now I can see some progress bar moving when the PDF is generated. But nothing got generated. I have checked if /home/_lib/tmp path is accessible by appending back to my domain. Yes it is going there and showing the list of files. Here is the log
./wkhtmltopdf-amd64 –page-size A4 –orientation Landscape –outline-depth 0 –header-right “[page]” https://my-domain.org/home/_lib/tmp/sc_non_member_ledger_html_cbd4be1c4c63c166d9e7684124bbc4ee.html /home/incredi1/public_html/home/_lib/tmp/sc_pdf_20180515173011_842_non_member_ledger.pdf
My host provider told me that they are running in CentOS 6, I don’t know if the above /wkhtmltopdf-amd64 is CentOS, also they told me they don’t support Java. Where Can I get the /wkhtmltopdf-amd64 for CentOS 6? Will it be an issue if Java is not installed in my host provider?
Thank you so much, I think I am nearing to the solution. If you can answer the above may be I will be able to figure out and resolve my issue.
Hi,
Does your shared hosting provider support SSH? If yes, you can SSH into the machine, try to run the exact wkhtmltopdf command used by Scriptcase and see what happens. Otherwise, you can write a simple PHP page that uses exec() (see http://php.net/manual/en/function.exec.php) to call the same command. Upload that page to the shared host, preferably to the folder containing wkhtmltopdf-amd64, and check if there are any error messages returned when running the command.
wkhtmltopdf binary is universal (which is usually the case for most Linux command-line binaries) and does not require a particular Linux distro to run. It also does not require Java and will work as long as your Linux is 64-bit. I have personally generated PDF files using Scriptcase on 64-bit CentOS with no issues.
Try to give 777 permission to any other library files or dependencies in the “third” folder as well, since these files might be needed by wkhtmltopdf.
A possible problem I see from your log is that Scriptcase passes the absolute path to the PDF file (/home/incredi1/public_html/home/_lib/tmp/sc_pdf_20180515173011_842_non_member_ledger.pdf) to the wkhtmltopdf tool. This might not work if your shared host has some access restrictions. However, you can try to set 777 permission for each of the parent directories and see if this makes any difference. Otherwise, a workaround is to hide the default PDF export button by Scriptcase and create your own button that calls wkhtmltopdf with a relative path, which should work.
Hi,
Finally it is working now. This is what I have done. I had copied the Binary from the below location
https://github.com/h4cc/wkhtmltopdf-amd64/tree/master/bin
This came as .dmg file. I have renamed the existing file under /public_html/home/_lib/prod/third/wkhtmltopdf/linux-amd64 folder and then copied this file and removed the .dmg extension (by renaming).
Set 777 rights to this file.
Now PDF is getting generated perfectly :). Thank you very much for all your help. I would not have nailed down without your hints / help. Appreciate your time. A Big THANK U
Glad to hear you’ve got it working. Cheers
Muchisimas Gracias solucionó mi problema con https y pdf
Thank you so much solved my problem with https and pdf