These are chat archives for collectiveaccess/support

10th
Apr 2017
ericwm
@eriwm
Apr 10 2017 07:49
@murchmurch
If you have not solved this yet maybe this will help "On many (all?) Linux distributions, LibreOffice requires write access to the home directory of the user under which is it run. For a web application like CollectiveAccess, this means making sure that the home directory of the web server user is writeable by the web server user. Omitting this detail can result in frustrating silent failures. You have been warned :-) "
From CA Cookbook 7
murchmurch
@murchmurch
Apr 10 2017 08:33
@eriwm . Thanx, I have but im unsure where "the home directory of the web server user is writeable by the web server user" is. As i can see my apache is running under the www-data user.
murchmurch
@murchmurch
Apr 10 2017 08:52
@eriwm what i can understand its the /vaw/www folder. Ad it is owned by www-data user. I can als see that the wor files have been copied to the /tmp folder and renamed /tmp/php9a6dI5.docx . when i manually run "soffice --headless -convert-to pdf:writer_pdf_Export /tmp/php9a6dI5.docx -outdir /tmp" Everything works. Any ide where the $vs_tmp_dir_path is poining? If thats the problem? Any way to get detail logging on wha PHP stuff is goin on in the background?
ericwm
@eriwm
Apr 10 2017 09:51
@murchmurch The apache2 logs are found in /var/log/apache2. As for the permissions I set my Home directory to have the same ownership as /var/www.
I had a similar problem where I could run soffice manually and it worked ok but found that my gmagick extension was not installed properly - did you add the gmagick.so extension to the php.ini file and is it only docx that won't upload?
murchmurch
@murchmurch
Apr 10 2017 11:38
@eriwm JPG iles work as a charm! Its just the word (.docx) files that are the problem. PDF files work great as well. Nothing usefull in the loggs ;(
CollectiveAccess
@collectiveaccess
Apr 10 2017 12:33
@murchmurch If you're running LibreOffice 4 there's a LibreOffice "headless" package that needs to be installed on many Linux distributions. Without it LibreOffice can't be run on the command line. For LibreOffice 5 just installing the regular package should be ok.
Next make sure that the path to LibreOffice is correctly set and LibreOffice is being detected in Configuration Check
CollectiveAccess
@collectiveaccess
Apr 10 2017 12:42
The permissions for /var/www should be set to be writable by www-data
If all of that is good then it should work
I just checked a production system running Ubuntu 16.04 with a working LibreOffice/CA install
It's running LibreOffice 5.1.6.2
What version are you running?
murchmurch
@murchmurch
Apr 10 2017 13:00
@collectiveaccess @eriwm Threw debugining i have found that the problem seems to lye in the $ps_sig variable. When i chek my docx documents they seem to all start with PK and the isWordExcelorPPTXMLdoc($ps_filepath, $ps_sig) function assumes that they are ziped and tryes to uzip. The windows wersion didnt have thise problem I can easily import all those documents without a problem.. only slow..
murchmurch
@murchmurch
Apr 10 2017 13:10
I have now tried to open one of the files and save it as a .doc file and then the import works.. so its only my original docx files taht i cant import in ubuntu but works as a charm in windows..
@collectiveaccess LibreOffice 5.3.2.2 But i dont think its the conversion thats the problem. Its that CA dosent recognise the files as word xml files ;(
murchmurch
@murchmurch
Apr 10 2017 13:30
@collectiveaccess Ok.. so if i do a changein the office.php file, in the isWordExcelorPPTXMLdoc() function so that the
if (
substr($ps_sig, 0, 2) == 'PK' // is a PKZip file... so open it up
) {
Instead of trying to unzip the file it instead identifies it as a WORD file:
    if (
        substr($ps_sig, 0, 2) == 'PK'        // is a PKZip file... so open it up
    ) {

                    try {
                        $o_doc = Zend_Search_Lucene_Document_Docx::loadDocxFile($ps_filepath);
                        $this->opa_metadata = array('WORD' => array(
                                'title' => $o_doc->getFieldUtf8Value('title'),
                                'subject' => $o_doc->getFieldUtf8Value('subject'),
                                'creator' => $o_doc->getFieldUtf8Value('creator'),
                                'created' => $o_doc->getFieldUtf8Value('created'),
                                'modified' => $o_doc->getFieldUtf8Value('modified')
                            )
                        );
                        $this->handle['content'] = $o_doc->getFieldUtf8Value('body');
                    } catch (Exception $e) {
// noop
}
                    return 'WORD';
This works as a charm. And i will only have the same sort of docx files this will work as fix for me.. But it strange that the same file import works in windows but not in Ubuntu... Is there any other way to bypas this?
ericwm
@eriwm
Apr 10 2017 13:52
@murchmurch Now you are talking to the right person, hope you get it solved .
CollectiveAccess
@collectiveaccess
Apr 10 2017 14:09
Well that'll fail if you put PPTX or XLSX files through
I guess you're using the 1.6 code; this is all rewritten in 1.7
ericwm
@eriwm
Apr 10 2017 14:42
@murchmurch just a thought don't know whether this is relevant but do you have pk-zip installed this was recommended to me earlier on gitter
murchmurch
@murchmurch
Apr 10 2017 17:46
@eriwm How do i install it? Cant find anything online how to download pk-zip...
ericwm
@eriwm
Apr 10 2017 21:47
@murchmurch Had to go back in the forum to check this and found Id made a mistake it should be sudo apt-get install php-zip. This fixed a problem I had uploading XLS files - dont know if this will help with your problem but may e worth a try.