neocreo

Hey Antti, yeah, been reading myself in on this. Can’t wait until they release their new version though. It apparently will have svg support.

As a work around though, I was wondering if it is possible to maybe render the SVG and convert it via javascript to a PNG? I am working with data-uri, and not physical files.

Or would I have to render the files on the server, as I have a feeling dompdf won’t run javascript.

What do you think, as a stab in the dark?

No ideas about this?

How would you go about creating your own theme? I have certain proprietary add ons that I would like to incorporate. In particular I want to post a form to a custom post type I have.
The custom post type is defined in my current theme.

However, even though my theme is responsive, I cannot see any preview of the pages. It is just blank.

Any help or documentation on this? Looked through the website and scoured the web, but found nothing.

I also had this warning in Chrome leading to this page: https://support.google.com/chrome/answer/6213033

This plugin is an essential part of an intranet system, so really need to know if there will be any further development to keep it compatible with Chrome and modern webbrowsers, including WP 4.4 and PHP 7 in the future.

OK,So I finally cracked it!

I just could not get the file_get_contents() to work.
So I have experimented with some other ways of retrieving the content as evidenced by my other posts.

The solution was actually using wp_remote_get() in combination with wp_remote_retrieve_body().

And bypassing the PHPSESSID cookie to allow me to get the contents behind this membership-plugin I use (all users have to be logged in to view content).

I hope this helps anyone encountering this issue, and I would like to suggest to move to the built in wp_remote functions rather than file_get_contents in future releases.

Full solution:

$fullink =  $link . (strpos($link, '?') === false ? '?' : '&') . 'pdf-template' ;
$cookies      = array();
foreach ( $_COOKIE as $name => $value ) {
if ( 'PHPSESSID' === $name )
continue;
$cookies[] = new WP_Http_Cookie( array( 'name' => $name, 'value' => $value ) );
}
	$filegetargs = array(
	'cookies' => $cookies,
	'sslverify'   => false,
	);

  	$response = wp_remote_get( $fullink, $filegetargs );
if(is_wp_error($response)){
	echo 'Error Found ( '.$response->get_error_message().' )';
}
if( is_array($response) ) {
	$html = wp_remote_retrieve_body( $response );
}

Hmmm, four weeks on and still no luck. However, I was just sitting and trying to get it to work when the following happened:
I wrote “/pdf-template/” instead of “/pdf-preview/”, and suddenly the page loaded.

I had before this reset the $html variable to fetch the contents the old fashioned way.

The preview and the pdf links still won’t work, but maybe that can help you point me in the right direction?

I have that defined already, but it still has problems loading the stream.

Hmmmm, maybe the request for the page is done before the cookies are completely set… I shall experiment.

OK, so some more details. This is a multisite set up where I have set the privacy option so that it is only visible to logged in users for that particular site. Though changing it to public still generates an error.

I have experimented with switching out the file_get_contents() with CURL

$ch = curl_init();
		curl_setopt($ch, CURLOPT_URL, $link . (strpos($link, '?') === false ? '?' : '&') . 'pdf-template');
		curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
		$file = curl_exec($ch);
		curl_close($ch);

		$html =  $file;

but run in to the same issues of the content not loading and now I am experimenting with wp_remote_retrieve_body()

Effectively changing
$html = file_get_contents($link . (strpos($link, '?') === false ? '?' : '&') . 'pdf-template', false, $context);
to

$getargs = array(
			'cookies' => $_COOKIE,
			);
        	$html = wp_remote_retrieve_body( wp_remote_get( $link . (strpos($link, '?') === false ? '?' : '&') . 'pdf-template', $getargs ) );

Yet it only works if I set the privacy option to publically visible.

This is driving me nuts.

I have just run into this problem after the latest update to WordPress 4.2.3. I mean, both the pdf and pdf-preview refuses to load and the server times out and shows Warning: file_get_contents(https://www.domain.com/mypage/?pdf-template): failed to open stream: HTTP request failed! in /?ink/to/content/wp-content/plugins/wp-pdf-templates/wp-pdf-templates.php on line 227

It worked perfectly before the update, and I have checked my phpinfo and nothing has changed on the server. No new plugins installed either. It just stopped.

Any ideas as to why this is?

Additional info. It seem to be a problem with activating the plugin in the network of my multi-site WordPress installation.

When I activate the plugin on individual site basis, then PDFs show correctly in the in-browser PDF-readers.

How very peculiar. Might want to take a look at this for the next version.

I tried the normal way that most browsers support – putting the content in a table with thead and tfoot.

However, it does not work like that in the DOMPDF. After a lot of trial and error, it actually is a lot better.
Add two divs to the body. Give them the ids pagehead and pagefoot respectively.

Add the following CSS:

body{
	padding: 30mm 10mm 20mm;

}
#pagehead {
 	position: fixed;
 	left: 0;
 	top: 0;
 	right: 0;
 	height: 15mm;
 	text-align: left;
 	border-bottom: 1px solid #000;
 	padding:10mm 10mm 0mm;
 }
    #pagefoot {
    	position: fixed;
    	left: 0;
    	bottom: 0;
    	right: 0;
    	height: 15mm;
    	padding: 5mm 10mm 0;
    }

So yeah, just divs with position: fixed.

Looks like it has something to do with the Alpha channel. If I flatten the PNG it will show up in the rendered PDF. Not a sustainable solution though. Why have transparent PNG’s stopped working?

Hi, I have the same problem with PNG logos not showing on the rendered PDF. JPGs work.
However, these logos worked in the previous version of WP Post to PDF Enhanced (1.0.5)). Just ran the update today, and needless to say, my client is pissed.

Btw, why not use the header image already uploaded for the website, or allow uploading in the plugin?

Argh, ignore this – apparently it didn’t save my default page for support in the settings.

Will mark this as fixed, and hopefully it might help someone else being a dope like me ??

This is not a permalink issue.
This is a question of the link to the file being wrong.

If you change the file type, all previous versions are assumed to have the same filetype – and then the links won’t work.

Why is it that when putting together the permalink that it can’t look on the mime-type and do the file ending from there? Or save the file ending in the post-meta, or even check the file that it links to and grab the file ending from there?

If you do not believe me, try it yourself – upload a .doc file, then upload a .xls file and finally a .pdf.

This is an issue that must be fixed.

I have traced this now to the function

function filename_rewrite( $file ) {

		//verify this is a document
		if ( !$this->verify_post_type( $_POST['post_id'] ) )
			return $file;

		//hash and replace filename, appending extension
		$file['name'] = md5( $file['name'] .time() ) . $this->get_extension( $file['name'] );

		$file = apply_filters( 'document_internal_filename', $file );

		return $file;

	}

in wp-document-revisions.php

$this->get_extension( $file['name'] ) seem to take the extension from the filename, and that filename is the name of the current version.

I am not a PHP-developer, but if anyone has a solution to this I would very much appreciate this.