Error on save when using qTranslate

Hmmm…

First, thanks for your kind words!

Next, I’m so sorry to hear that you have this issue. When you say “save pages,” I’m guessing that you are referring to clicking the icon to generate the PDF. Is this correct?

Does this happen on all pages or just a select few? Normally, this error indicates some issue with the intermediate HTML being fed to TCPDF to render the PDF. I’m wondering whether one of your plugins might be triggering this (we may not be handling custom fields very well, yet).

Please advise as to which version of the (this) plugin you are using, and which version of PHP you are using, as well. I’ll have a look over the weekend.

Thanks!

Lewis

Hi Lewis,

I’m on PHP 5.3.5 – everything else is uptodate – Plugins / WP – it’s a new localhost site I’m developing.

By save pages – I mean literally saving pages inside the admin – seemed a bit strange to me that the pdf creation was trying to run at this point.

There are also a few small isset issues – I’m editing these as I find them and could send over an edited version when I’m done – or you tell me how best you’d like to do this.

I use Query Monitor plugin to pick up and find the issues – another excellent plugin.

Cheers!

Q

No doubt more than a few isset issues. I’ve been nailing them down also, as I come to them (remember, this project was forked). Please do email your changes to me; much appreciated. While you may always contact me through the contact form on my blog, feel free to use lgrosenthal at 2rosenthals dot com.

Thanks for the tip about Query Monitor; I’ll check into that.

Good to know that you’re using PHP 5.3 and seeing this, as it makes it somewhat easier for me at the moment to compare against my sandbox. I also agree that it’s odd that we’re trying to fire off a command to TCPDF when saving options in the admin area; this is definitely a bug.

Cheers to you too, and thanks much for your input and thorough reporting!

Lewis

I’ve sent you an updated version of the plugin via email – I can no longer replicate the issue, but I doubt the small fixes I made solved the problem.

However, I’ll mark this as resolved for now – Thanks!

Q

Hi Lewis,

How are you?

The PDF plugin is giving me some errors on saving pages – in this instance I have polylang, ACF and gravityforms installed – but I’m not which is causing the issue.

I do know how to ( temporarily ) solve the issue:

wp-post-to-pdf-enhanced.php:62

#add_action(‘post_updated’, array(&$this, ‘generate_pdf_file’));

By commenting out this action hook, I stop getting this error:

TCPDF ERROR: Please explicitly set action attribute path!

Without looking too far into the code – it seems that the plugin is trying to remake the PDF on each page save – and that something is a miss – the error stops the page saving..

I’ve not run into this problem editing or saving custom post types – which are selected to use the plugin – post and pages are not set to create pdf – perhaps that is the clue to solve the issue?

Any help would be warmly welcomed – as I plan to use the plugin on a site I’m launching soon!

Cheers – Ray

Hi, Ray…

Thanks for the additional info. I’ll look into this ASAP. That action hook predates my work, so I’ll need to look at the code around it, as well as TCPDF (please have a look and tell me which version of the plugin you have, and also, if you can have a peek at the README.TXT in the tcpdf directory to confirm the version, that would be helpful).

I’ll have a look at this as soon as I can. Meanwhile, stick with your workaround, if you see no ill effect from it.

Cheers

Lewis

Hi Lewis,

Thanks for your reply.

Both the main plugin file and the readme.txt confirm this as version 1.0.2 – the same version I sent to you I believe ??

R

I think I see the issue, Ray, but I’ll need to install those plugins in my sandbox and play with this. With any luck, that will be along about Sunday (been a rough week so far).

The relevant code in TCPDF appears to be in the main class, along about line 18859:

// Form fields (since 4.8.000 - 2009-09-07)
case 'form': {
	if (isset($tag['attribute']['action'])) {
		$this->form_action = $tag['attribute']['action'];
	} else {
		$this->Error('Please explicitly set action attribute path!');
	}
	if (isset($tag['attribute']['enctype'])) {
		$this->form_enctype = $tag['attribute']['enctype'];
	} else {
		$this->form_enctype = 'application/x-www-form-urlencoded';
	}
	if (isset($tag['attribute']['method'])) {
		$this->form_mode = $tag['attribute']['method'];
	} else {
		$this->form_mode = 'post';
	}
	break;
}

I need to do some more sleuthing, but I should be able to find a cleaner way of handling this.

Cheers

Lewis

Hi Lewis,

That’s the same place I picked up the error notice – so I’m guessing this is correct – looking at the conditional check, it’s failing because of that $tag variable – best place to start might be with a few var_dumps.. and see what’s going on!

Cheers and good luck!

Ray

Just a quick note to let you know that I haven’t completely forgotten this one, Ray.

I want to bump the TCPDF version in the trunk build, and that will be a good chance to see if this might resolve itself at that point.

Cheers

Lewis

Thanks Lewis,

I upgraded and used the same temp fix to get around the problem for now.

Ray ??

It may be that this is another one of those places where we think we should be updating a cached PDF (we trigger the action, as you see, when a post is updated), but where we really shouldn’t (such as when editing the navigation menus). I’ve added code to specifically not add the action hook when we’re on the navigation menu, but perhaps I need to go about it from the opposite direction, and only add the action when editing a page or post, and not from any other screen which could possibly trigger a post_updated event.

I guess until I looked at the nav-menu issue, this (firing an action hook on a “post_updated” event which really isn’t an update to the content included in the PDF) never occurred to me (or to Neerav, who wrote that piece of code, originally).

I really do need to install those plugins and see what’s happening in this regard. TCPDF may merely be reacting to us not handing off enough information because we are firing at the wrong time.

Cheers

Thanks Lewis,

In my case the issue happens when saving pages – but not custom post types ( in this case all the CPT’s have been configured to use WP Post to PDF Enhanced, but the pages not ) – my wild guess is that’s the best place to start looking for the issue – caused by the hook into the post_updated action.

Cheers!

Ray

Hmmm… So, you are configured to not generate PDFs for pages, but when editing a page and saving it, because we have the action hook set, we try to “update” the PDF of the page (which should not exist), and the error gets thrown.

I would agree that the logic is failing in this instance. I need to see how to discern between updating a post and updating a page, as I would suspect that if the options were set the other way ’round, we’d see the same issue in reverse (error thrown when updating a post).

What is confusing to me is why we don’t see this unless one or all of those plugins are active along with us, as I am fairly certain that I don’t see this issue in my sandbox. Back to the var dump thing again. ??

If I am missing something obvious, here, please kick me.

Thanks, Ray.

Cheers

Lewis

Hi Lewis,

Thanks for your persistence – I have in mind a few simple tests – such as disabling some or all of those stated plugins – to be honest my feeling is that I’ll still see the error – but as you’ve said you’re not seeing it.

I’m going to be away until Friday – but when I get back I’ll find some time to give some of these theories a shot and I’ll be sure to update this thread with the results.

Have a good one

Ray