Hi,
I can't seem to get this message to disappear from my site's status report:
"DOMPDF font cache directory - Non-writable permissions-You must change the modules/print/lib/dompdf/lib/fonts permissions to be writable, as dompdf requires write-access to that directory."
I have tried to setting write permissions to add both "group" and "world" in addition to what seem to be the default write permissions of just the user. But the dang error message won't disappear. I've also flushed all caches and still get the same thing. I don't like the idea of giving any directory folder "world" write access either. I'm going to go back to the original 755 write permissions originally on the directory/folder, the PDF page print function seems to still work fine. I should also note that this error seemed to appear right after I updated the site to Drupal 6.19.
Any help would be greatly appreciated.
Thank you.
Comments
Comment #1
jcnventuraThis warning is introduced by the new version (6.x-1.11), as dompdf only works properly if it has write access to that folder. That folder needs to have the same permissions has your sites/default/files folder.
Those permissions are checked when loading the status report page, so if you change the permissions of the modules/print/lib/dompdf/lib/fonts and then refresh the page it should disappear.
João
Comment #2
zap-admin commentedHi João,
Thanks for the info. My sites/default/file folder has permissions of 755, but the module itself is in sites/all/modules/print....etc. In each folder leading to the font folder the permissions are 755. But none of this is in the sites/default/files folder. The sites/default permissions is different. It is in fact 555. Could that be the cause of this? Or have I put all my non-systems modules in the wrong directory when I put them in sites/all/modules? Sorry if I'm missing the connection here.
Thanks,
Jeffrey
Comment #3
jcnventuraNo, the reason why I mention the "sites/default/files" directory is that the code used to check if that is writable is the same that is used to check if the lib/fonts directory is writable. So, if your drupal isn't complaining about one, it shouldn't complain about the other if the permissions are the same.
So, as long as the owner and group of both directories is the same, if you set it to 755 you should be OK.
One other thing, you should install contributed modules in sites/all/modules and not in modules, as your original message seems to suggest.
João
Comment #4
zap-admin commentedHello João,
I double checked and sites/default/files and sites/all/modules/print.../fonts both are 755. I just tried adding the group write permission to both of these directories changing them to 775, then I ran update.php but I'm still showing the same error. I tried going up one level as well. Changing permissions on sites/default from 555 to 755 before I changed things to 775.... but cPanel doesn't seem to want to take the permissions change. I'm wondering if this is because the settings.php file is in the sites/default directory and changing 555 to 755 somehow breaks the protection that is supposed to secure the settings.php file. ****Actually just figured out that cPanel will accept when change of sites/default directory to 755 from 555..... but as soon as cron runs(every 2 hours for me) it knocks permissions back to "555" for the sites/default directory
it looks like this will have to remain unresolved for me for the time being since we can't seem to make this work right. Not a big deal since it doesn't seem to be affecting the function of the site.
As for your final item. You are correct that I have all my contributed modules in the "sites/all/modules" directory. I originally had been installing all my modules in the public_html/modules directory but have now moved all modules on most of my sites now. Started realizing the error of my ways after a couple of major site updates where I screwed up and overwrote some of the theme files I need to make my sites function a certain way because some of their code was modified.
Thank you very much for your time and help João, I really appreciate it.
Jeffrey
Comment #5
jcnventuraOne other possibility that I've wondered is whether the mentioned path even exists. That error will only show up if dompdf is selected as the PDF tool, and either:
1) the path doesn't exist
2) it exists, but is not a directory or is not writable by the Web server that's executing Drupal.
It's possible that you had dompdf installed before in modules/print/lib/dompdf, and updated the module moving it to sites/all/modules/print/lib/dompdf. The module doesn't detect that the tool changed paths (maybe it should..), as that information is stored in a Drupal variable and re-used when necessary. If that's the case, you simply have to go to admin/settings/print/pdf and select the new path.
Failing that, I am totally out of ideas on why this may be happening to you.
Comment #6
zap-admin commentedFIXED IT..... kind of
Thanks for the info JCNVentura. I couldn't find the exact kind of field you were describing. One whereby I could give a path to a file or series of files. However, In looking for what you had described I found something.
In the "Printer, e=mail and PDF Versions" admin screen..... I found "PDF Generation tool"...it was a radio button selection of one item only. It pointed to sites/all/modules/print/lib/dompdf/dompdf_config.inc.php It wasn't selected so I selected it and hit "Save Configuration" Well.... this got rid of the error showing in the status report.
But then I took a look at one of my nodes/pages and noticed there was no PDF link there. Just "printer friendly version" and "email to a friend" links.
I went back to the admin page for this module and selected the PDF Version Link to show up in the links area. Went back to the product page and the button/link now showed. I clicked on it to test it and then got what almost looks like a site crash:
"Fatal error: Uncaught exception 'DOMPDF_Internal_Exception' with message 'Frame not found in cellmap' in /home/controlm/public_html/sites/all/modules/print/lib/dompdf/include/cellmap.cls.php:224 Stack trace: #0 /home/controlm/public_html/sites/all/modules/print/lib/dompdf/include/table_cell_renderer.cls.php(74): Cellmap->get_spanned_cells(Object(Table_Cell_Frame_Decorator)) #1 /home/controlm/public_html/sites/all/modules/print/lib/dompdf/include/renderer.cls.php(233): Table_Cell_Renderer->render(Object(Table_Cell_Frame_Decorator)) #2 /home/controlm/public_html/sites/all/modules/print/lib/dompdf/include/renderer.cls.php(110): Renderer->_render_frame('table-cell', Object(Table_Cell_Frame_Decorator)) #3 /home/controlm/public_html/sites/all/modules/print/lib/dompdf/include/renderer.cls.php(150): Renderer->render(Object(Table_Cell_Frame_Decorator)) #4 /home/controlm/public_html/sites/all/modules/print/lib/dompdf/include/renderer.cls.php(150): Renderer->render(Object(Table_Row_Frame_Decorator)) #5 /home/controlm/public_html/sit in /home/controlm/public_html/sites/all/modules/print/lib/dompdf/include/cellmap.cls.php on line 224"
The other two links "print friendly" and "email a friend" are both working so I'm in the clear really. And I also got rid of my error in the status report which makes me feel a little better about it. I don't really need to be able to creat PDF's of the product pages for this site. There's already a PDF datasheet for each product that users can download. I removed the PDF button/link and just left the other two for now.
Thank you for your help and time. It at least led me to being able to get rid of the error.
Jeffrey
Comment #7
jcnventuraThat's exactly what would happen if you configured the PDF tool in modules/print and then moved it to
sites/all/modules/print.
The reason it was complaining wasn't about the permissions, but about the fact that the path didn't even exist. I will add something to check if the currently configured PDF tool is still present and display an appropriate error if it isn't.
If you're able to use it, try wkhtmltopdf.. It will give you 100% perfect copies of your page content in PDF.
João
Comment #8
zap-admin commentedCool..... I'll give that a try here soon. I just fixed a bunch of issues I was having with ddblock... YEAH!....LOL.
I figured I was likely to run into a couple few issues moving all those non-systems modules into the new directory. Was my bad move from the get go. Thanks again for all your help Joao.... I really appreciate it.
Jeffrey