GET variables not working

[John E]

Is there any documentation on the GET variables? Is there some
configuration I need to do to get them to work?

Essentially, I have 2 servers. One has PHP4 (and the main body of my
code), and the other has PHP5. So in order to create PDF's, I have
installed dompdf on the PHP5 server with the intention of using the
GET variables rather than calling the functions directly.

No matter what I do with the URL, it will not print a PDF. All I get
is an empty html page. Since there's no output, I have no idea what's
going on inside the script, so... I'm stuck.

There doesn't seem to be a lot of documentation or group posts on the
web usage, so I thought I'd see if anyone has had similar issues. Any
help would be much appreciated. I know dompdf is working because it
works fine from the command line, I just need it to work from a URL.

All in all, this is an excellent piece of work, and if I can get it
working, it will save me so much time and headache. Thank you for
doing this!

[BrianS]

On Oct 26, 6:41 pm, John E <jaengl...@gmail.com> wrote:
> Is there any documentation on the GET variables?

Are you attempting to use dompdf.php? You can find basic installation
and usage information for DOMPDF on Benj's site (http://
digitaljunkies.ca/dompdf/) or mine (http://eclecticgeek.com/dompdf/
docs/).

This information at the above locations is specific to DOMPDF 0.5.1.
For the most up-to-date information visit the wiki at
http://code.google.com/p/dompdf/wiki/Introduction. I'm posting these
links, however, because the usage page is not yet available on the
wiki.

FYI, making dompdf.php accessible on your web server isn't recommended
if you're using DOMPDF 0.5.1 as it has a security vulnerability. Web
access to this script has been removed completely from the current
alpha. You'll need to create your own page that uses the DOMPDF class,
but the code you need is pretty simple.

Something along the lines of the following:

<?php
require_once("dompdf_config.inc.php");
$dompdf = new DOMPDF();
$dompdf->load_html($_GET['input_file']);
$dompdf->render();
$dompdf->stream("document.pdf");
?>

accessed via a URL such as http://www.example.com/pdf.php?input_file=http://www.example.com/pdf.htm

> Is there some configuration I need to do to get them to work?

You will probably need to set DOMPDF_ENABLE_REMOTE to true if you're
accessing document on another server.

> Essentially, I have 2 servers. One has PHP4 (and the main body of my
> code), and the other has PHP5. So in order to create PDF's, I have
> installed dompdf on the PHP5 server with the intention of using the
> GET variables rather than calling the functions directly.
>
> No matter what I do with the URL, it will not print a PDF. All I get
> is an empty html page. Since there's no output, I have no idea what's
> going on inside the script, so... I'm stuck.
>
> There doesn't seem to be a lot of documentation or group posts on the
> web usage, so I thought I'd see if anyone has had similar issues. Any
> help would be much appreciated. I know dompdf is working because it
> works fine from the command line, I just need it to work from a URL.
>
> All in all, this is an excellent piece of work, and if I can get it
> working, it will save me so much time and headache. Thank you for
> doing this!

Try my suggestions and let us know if you need anymore help.
-b

[John E]

Thanks, Brian.

I did read the usage docs, and as far as I can tell, I'm using it
correctly. I tried creating the script you suggested, and it does the
same thing. Just a blank html page.

Security isn't that much of a concern because I have a dedicated
subdomain for dompdf and static IP's on both servers. I can just
remove all access except from the one IP I'm calling it from. In fact,
I have separate internal and external IPs on those servers, so I can
just call the script across the local network instead of the
Internet.

I've set up the script here:
http://dompdf.ccrcmenus.com/render.php?input_file=http://dompdf.ccrcmenus.com/html/test.html

dompdf.php is also in that directory, and you can view the test file
and see that it's incredibly simple and accessible. I think it might
be a 500 error at this point. Is there some module I need to have
enabled on the server? As I said, it works fine from the command line,
so it has to be something with Apache, or maybe a configuration option
I forgot to set.

If I REALLY have to, I can do some hackery with it and set up a script
to run it command-line and toss the output onto an NFS share, but
that's a ridiculously roundabout way of doing things. Oddly enough
that wouldn't even be the most messed-up part of the code I have to
work with every day.
I was hoping to make this simple. ;)

Thanks again for your help, guys.

~j

On Oct 27, 12:23 pm, BrianS <eclecticg...@gmail.com> wrote:
> On Oct 26, 6:41 pm, John E <jaengl...@gmail.com> wrote:
>
> > Is there any documentation on the GET variables?
>
> Are you attempting to use dompdf.php? You can find basic installation
> and usage information for DOMPDF on Benj's site (http://
> digitaljunkies.ca/dompdf/) or mine (http://eclecticgeek.com/dompdf/
> docs/).
>
> This information at the above locations is specific to DOMPDF 0.5.1.

> For the most up-to-date information visit the wiki athttp://code.google.com/p/dompdf/wiki/Introduction. I'm posting these

> links, however, because the usage page is not yet available on the
> wiki.
>
> FYI, making dompdf.php accessible on your web server isn't recommended
> if you're using DOMPDF 0.5.1 as it has a security vulnerability. Web
> access to this script has been removed completely from the current
> alpha. You'll need to create your own page that uses the DOMPDF class,
> but the code you need is pretty simple.
>
> Something along the lines of the following:
>
> <?php
> require_once("dompdf_config.inc.php");
> $dompdf = new DOMPDF();
> $dompdf->load_html($_GET['input_file']);
> $dompdf->render();
> $dompdf->stream("document.pdf");
> ?>
>

> accessed via a URL such ashttp://www.example.com/pdf.php?input_file=http://www.example.com/pdf.htm

[BrianS]

On Oct 27, 4:43 pm, John E <jaengl...@gmail.com> wrote:
> Thanks, Brian.
>
> I did read the usage docs, and as far as I can tell, I'm using it
> correctly. I tried creating the script you suggested, and it does the
> same thing. Just a blank html page.
>
> Security isn't that much of a concern because I have a dedicated
> subdomain for dompdf and static IP's on both servers. I can just
> remove all access except from the one IP I'm calling it from. In fact,
> I have separate internal and external IPs on those servers, so I can
> just call the script across the local network instead of the
> Internet.
>

> I've set up the script here:http://dompdf.ccrcmenus.com/render.php?input_file=http://dompdf.ccrcm...

>
> dompdf.php is also in that directory, and you can view the test file
> and see that it's incredibly simple and accessible. I think it might
> be a 500 error at this point. Is there some module I need to have
> enabled on the server? As I said, it works fine from the command line,
> so it has to be something with Apache, or maybe a configuration option
> I forgot to set.

It seems to probably be a PHP error occurring before DOMPDF even has a
chance to render the document. You said DOMPDF was in the same
directory as your custom script so I accessed the www directory. The
index page loads fine, but when you attempt to access examples.php
nothing is displayed. Looking at the headers returned, your server is
definitely reporting a 500 error. Have you looked in your PHP
error.log? I'd start there since it might be an permission problem.

There have been occasional issues with CentOS so there could be an
incompatibility there, but let's start with PHP and see what we can
find.

> If I REALLY have to, I can do some hackery with it and set up a script
> to run it command-line and toss the output onto an NFS share, but
> that's a ridiculously roundabout way of doing things. Oddly enough
> that wouldn't even be the most messed-up part of the code I have to
> work with every day.
> I was hoping to make this simple. ;)

Hopefully we'll get there. Would truly suck to have to add yet another
layer of obscure code to your already messed-up work load ;)