Questions and discussion about developing processes and programming in PHP, JavaScript, web services & REST API.

Moderator: amosbatto

Forum rules: Please search to see if a question has already asked before creating a new topic. Please don't post the same question in multiple forums.
#824856
Hi.

I am hoping someone can assist me :D .

This is my first time posting, however I have been a frequent visitor of these forums for the last two years.
Usually I can always figure out a solution to any of my problems from existing posts, however it seems I am stuck for once.

I have a process where the users have .docx files and I want to convert them into .pdf.
Now I never expected ProcessMaker to have this functionality built in but I decided to look into PHP and command-line solutions

Originally I looked at other options, but they all had conversion issues where the formatting and style would be lost from the original docx. Eventually I came across LibreOffice's headless mode where via the command line it could do the conversion. It is slower than I would like, but the results are good.

I am running ProcessMaker on top of FreeBSD (open-source Unix-like operating system) and in the FreeBSD environment I can use this command to do the conversion:

Code: Select all

// libreoffice --headless --convert-to pdf --outdir $outputDirHere $docxFullPath
libreoffice --headless --convert-to pdf --outdir /usr/home/pmvm/pdf_temp /usr/home/pmvm/pdf_temp/testDoc.docx


This works flawlessly, however when I try to run it through PHP in ProcessMaker using the exec() command it doesn't work:

Code: Select all

$command = 'libreoffice --headless --convert-to pdf --outdir /usr/home/pmvm/pdf_temp /usr/home/pmvm/pdf_temp /testDoc.docx';

$output = exec($command, @@test);

:roll:
I have tried many variations including the 'unoconv' port in command-line which anyway requires Libreoffice to be installed.

I tried debugging through ProcessMaker to see what it runs the code under. the 'env' command yields the following array:
Array (
[0] => PATH=/sbin:/bin:/usr/sbin:/usr/bin
[1] => LD_LIBRARY_PATH=/usr/local/lib
[2] => PWD=/usr/local/processmaker/workflow/public_html
[3] => HOME=/ [4] => RC_PID=22 )

:?


And the 'whoami' command yields this.

Array ( [0] => www)

This led me to the assumption that this had to do with the php code executing the exec() command as the Apache user 'www' in my operating system.
Looking at other forums people have mentioned issues running this command from PHP through Apache due to their either being no home or temporary directory for the conversion to take place.

I tried these fixes such as setting the HOME environment variable to a tmp directory of my choosing, however I can't seem to figure out if they are taking affect as the arrays returned are generally empty.
Code: Select all

$command =  'setenv HOME tmp && libreoffice --headless --convert-to pdf --outdir /usr/home/pmvm/pdf_temp /usr/home/pmvm/pdf_temp /testDoc.docx';

$output = exec($command, @@test);




Does anyone know if they can run this command from ProcessMaker, and if so how?
Or perhaps another solution to this problem?

I apologise for the length of this post, but I didn't want to leave out any possibly important details. I am still new to UNIX systems so I have had to learn a lot in the past few weeks.


Any help would be greatly appreciated. :mrgreen:
#824858
This is likely due to user permissions. The context that exec is running user is "www" and probably does not have access to the pmvm folder.

I am not super strong on FreeBSD but you could try running the command as elevated from the EXEC command.

Another valid option would be provide www access to the users folders as needed.
Code: Select all
$command = 'echo 'MYPASSWORD' | sudo -S -u pmvm libreoffice --headless --convert-to pdf --outdir /usr/home/pmvm/pdf_temp /usr/home/pmvm/pdf_temp/testDoc.docx';

$output = exec($command, @@test);
#824861
Thanks for the response.

In regards to the user permissions I actually used the gulliver guide to make a plugin making a directory that ProcessMaker could access without issue or wiping the contents during upgrades.
My directories I listed are actually me trying to make my question simpler, but I didn't think it through that that would possible make it more confusing :?

The actual directory for the output and source looks more like this :

/usr/local/plugins/PLUGIN_NAME/PLUGIN_NAME/public_html/workflow/documents/output_documents/
All the folders in the plugin directory has the user:group www:wheel.

I am also not very good with FreeBSD but I am trying my best to learn it due to a pre-existing system. It is actually my first unix/linux distribution I am learning so it has been quite a learning curve for me.

I tried to see if I could edit your command to work with FreeBSD and I ended up with this:

Code: Select all

$command = 'echo password | su - root /usr/local/bin/soffice --headless --convert-to pdf --outdir PLUGIN_DIRECTORY PLUGIN_DIRECTORY/testDoc.docx';


Honestly no idea if this is the correct syntax. This is a test system so my password is actually 'password' here.

Running it in ProcessMaker yields no results, however running it directly in command-line as a standard user gives out this error:
LC_ALL: Undefined variable.
Which google tells me "forces applications to use the default language for output" and I tried setting it so the environment variables give me shows LC_ALL=C, yet it still states it as undefined.

I'm still experimenting with it to see if I am using the correct syntax geek
#824862
This command seems to only run as root. I think I previously had it working under the normal user using 'unoconv'.

If I run the command that worked in root as the normal user I get this error in the console:

libreoffice --headless --convert-to pdf --outdir /usr/local/plugins/PLUGIN_NAME/PLUGIN_NAME/public_html/workflow/documents/output_documents/PROCESS_UID/APP_UID /usr/local/plugins/PLUGIN_NAME/PLUGIN_NAME/public_html/workflow/documents/output_documents/PROCESS_UID/APP_UID/2.docx
convert /usr/local/plugins/PLUGIN_NAME/PLUGIN_NAME/public_html/workflow/documents/output_documents/PROCESS_UID/APP_UID/2.docx -> /usr/local/plugins/PLUGIN_NAME/PLUGIN_NAME/public_html/workflow/documents/output_documents/PROCESS_UID/APP_UID/2.pdf using filter : writer_pdf_Export
Error: Please verify input parameters... (SfxBaseModel::impl_store <file:///usr/local/plugins/PLUGIN_NAME/PLUGIN_NAME/public_html/workflow/documents/output_documents/PROCESS_UID/APP_UID/2.pdf> failed: 0x507(Error Area:Io Class:Access Code:7))
No clue if this helps.
#824865
In Linux, you can set the environmental variable and then execute a command at the same time, like this:
Code: Select all
$command = "LC_ALL=en_US.UTF-8 /usr/local/bin/soffice --headless --convert-to pdf --outdir PLUGIN_DIRECTORY PLUGIN_DIRECTORY/testDoc.docx";
exec($command, $output);
If you don't know your locale, then use the locale command when logged in as a normal user to figure it out.

It probably works the same in FreeBSD.

Also check whether the issue is that you can't overwrite the existing file. You may have to delete the existing file, before creating a new file:
Code: Select all
if (file_exists("PLUGIN_DIRECTORY/testDoc.docx")) {
    unlink("PLUGIN_DIRECTORY/testDoc.docx");
}
$command = "LC_ALL=en_US.UTF-8 /usr/local/bin/soffice --headless --convert-to pdf --outdir PLUGIN_DIRECTORY PLUGIN_DIRECTORY/testDoc.docx";
exec($command, $output);
#824876
Hi Amosbatto.

When I run the locale command I get the following
locale
LANG=
LC_CTYPE="C"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=
I attempted running the following through ProcessMaker:
Code: Select all
$command =  'setenv LC_ALL C | /usr/local/bin/soffice --headless --convert-to pdf --outdir '.$save_dir.'/pdf '.$save_dir.'/'.$doc_filename.'';
In command-line as root it sets the 'LC_ALL' to 'C' and then does the file conversion. Again it runs fine, until I try running it through ProcessMaker (can't see any errors) or as the non-root user in command-line (I get the same '(Error Area:Io Class:Access Code:7)' error as in my previous post).
I also tried it with 'setenv LC_ALL en_US.UTF-8' just in case and the same result.

The original code would just generate the testDoc.pdf next to the testDoc.docx without overwriting issues, but I decided to just double check and added a extra directory called 'pdf' with the same www:wheel permissions to prevent any possible overwriting issues and set that as the output directory.

I couldn't delete the existing file as it is needed in the command to do the conversion.

This sadly didn't yield any results either.

I tried installing unoconv, but it gives out the same error. Still experimenting.
#824890
When you login as root and issue the locale command, what do you see?

The "C" locale is basically no locale information.

Find out what locales you have installed:
locale -a

Then, pick one which provides both a language and a country and a character set.
#824936
Hi Amosbatto.

I apologise, I have been away for work.

when I login as root and issue the login command I get this :

[email protected]:/home/pmvm # locale
LANG=
LC_CTYPE="C"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=
It took me some time to figure out but I managed to get it set for all users :


[email protected]:/home/pmvm # locale
LANG=en_GB.UTF-8
LC_CTYPE="en_GB.UTF-8"
LC_COLLATE=C
LC_TIME="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_ALL=
I then ran the same code in command-line without the setenv :

$command = '/usr/local/bin/soffice --headless --convert-to pdf --outdir '.$save_dir.'/pdf '.$save_dir.'/'.$doc_filename.'';
And still nothing happening.
Taking the command and running it directly as a normal user still gives the same error :
Code: Select all

Error: Please verify input parameters... (SfxBaseModel::impl_store <file:///usr/local/plugins/PLUGINNAME/PLUGINNAME/public_html/workflow/documents/output_documents/1845123185c8c417aa16838067113853/3900725965d0232faf1ca18087543797/pdf/2.pdf> failed: 0x507(Error Area:Io Class:Access Code:7))

I assumed this was an access permission so I changed the owner:group from www:wheel to my pmvm:wheel user with
cd /usr/local/plugins/PLUGINNAME/PLUGINNAME/public_html/workflow/documents/output_documents/1845123185c8c417aa16838067113853/

chown -R pmvm:wheel 3900725965d0232faf1ca18087543797
And running the same pdf command it works! However still not through ProcessMaker.
So I tried impersonating a user and I am not sure if I am using it correctly, but I tried the following two options
Code: Select all

su -m www -c && /usr/local/bin/soffice --headless --convert-to pdf --outdir /usr/local/plugins/PLUGINPATH/PLUGINPATH/public_html/workflow/documents/output_documents/1845123185c8c417aa16838067113853/3900725965d0232faf1ca18087543797/pdf /usr/local/plugins/docMancer/docMancer/public_html/workflow/documents/output_documents/1845123185c8c417aa16838067113853/3900725965d0232faf1ca18087543797/2.docx

and
Code: Select all

su -m www -c | /usr/local/bin/soffice --headless --convert-to pdf --outdir /usr/local/plugins/PLUGINPATH/PLUGINPATH/public_html/workflow/documents/output_documents/1845123185c8c417aa16838067113853/3900725965d0232faf1ca18087543797/pdf /usr/local/plugins/docMancer/docMancer/public_html/workflow/documents/output_documents/1845123185c8c417aa16838067113853/3900725965d0232faf1ca18087543797/2.docx

Both work, despite the file permissions still being for my pmvm user. Changed it back to www and same result. So I am not sure if doing the impersonate as root is still taking precedence somehow.

Either way running those above codes through ProcessMaker still doesn't yield a result.
I also added the "setenv HOME tmp" and "setenv HOME /tmp" just in case and still nothing is returned.

I am really stumped. :?
#824951
You should ask your questions on a FreeBSD forum, since they know how their system works. I only use Debian, Ubuntu and CentOS.

Check if the "www" user has write permissions to the /usr/local/plugins/docMancer/docMancer/public_html/workflow/documents/output_documents/1845123185c8c417aa16838067113853/3900725965d0232faf1ca18087543797/ directory.

chown -R www /usr/local/plugins/docMancer/public_html/workflow/documents

Also check if the "/usr/local/bin/soffice --headless --convert-to pdf" command is able to overwrite the file if it already exists. You want it to be able overwrite.

What I recommend is that you execute the command as the root user. If FreeBSD doesn't already have the sudo command installed, then install it:
https://www.cyberciti.biz/faq/freebsd-i ... o-command/

Then, issue this command:
visudo

Add this line:
www ALL=(root) NOPASSWD: /usr/local/bin/soffice

Then save.

Then, use this trigger code in ProcessMaker:
Code: Select all
$command = "sudo /usr/local/bin/soffice --headless --convert-to pdf --outdir $save_dir/pdf $save_dir/$doc_filename";
exec($command, @=output);
Does that work?
#825030
Thanks Amosbatto.

I think you are right and I will see if I can get some answers from the FreeBSD Forums. I know that not many use this system fomr ProcessMaker so it would be challenging.

I attempted your recommendations, I ensured that indeed www had permissions to the folder and ran your chown command again just to make sure.

The "/usr/local/bin/soffice --headless --convert-to pdf" command could indeed overwrite any files made before and reflected new changes without issues. I decided to keep the source and output folder separate anyways as the directory felt neater.

I installed sudo and edited the visudo file to reflect the following :

##
## User privilege specification
##
root ALL=(ALL) ALL

www ALL=(root) NOPASSWD: /usr/local/bin/soffice
I ran your trigger code and it doesnt work in ProcessMaker, however it does in command-line.

I feel this is on the right track and will keep playing with it. I attempted to give the www a tmp directory using the following
setenv HOME /tmp &&
added to the beginning of your command, but still nothing.

Yeah That will be very helpful :) Thank you

variable in external libs

Ohhh I tried this thing before but didn't work tha[…]

Limit List box

Hello Amos, The following solution is working. $[…]

It looks like jquery.masknumber.js has problems in[…]