BoldMinded

Publisher does not support the Fluid field type. Please do not contact asking when support will be available.

If you purchased an add-on from expressionengine.com, be sure to visit boldminded.com/claim to add the license to your account here on boldminded.com.

Ticket: Publisher causing custom field tags in Channel Form form to not be parsed

Status Resolved
Add-on / Version Publisher 1.4.2
Severity Critical
EE Version 2.8.1

Pete Heaney

Jul 24, 2014

Hi,

I have Publisher configured so that all channels except one are ignored in the settings.

I have a Channel Form form setup for one of the ignored channels (i.e. a channel that should not be affected by anything Publisher related).

I was previously using Publisher v1.4.0 and everything was fine with the form.  Since upgrading to Publisher v1.4.2 (to fix a different bug), the custom field tags inside the {exp:channel:form} tags are no longer being parsed.

Any ideas?

Thanks,
Pete

#1

BoldMinded (Brian)

Someone else reported a similar issue, but I have not had time to look into it. I might not have time until this weekend or early next week, but I’ll definitely make this top priority.

#2

BoldMinded (Brian)

Can you post the full template code behind that form?

#3

BoldMinded (Brian)

Pete, I’m using 2.9 and unable to replicate this. The form fields are working fine. What other add-ons do you have installed? Have you tried this with only Publisher installed and no other add-ons?

#4

Pete Heaney

I’ve just downgraded back to version 1.4.0 (I’ve just overwritten the module files. I didn’t uninstall and reinstall). This seems to have fixed the problem, so it’s definitely something related to 1.4.2.

I’m fast approaching the project deadline so I don’t really have time to start again with a clean EE install at the moment. Whatever it was, downgrading seems to have fixed it, which will have to be good enough.

In case you still want to have a look at the template code - there’s some embedding going here, so there are 3 templates + a layout template:

layouts/default - https://gist.github.com/petefusion/c50d368028acebe6fba8 user/ceremony-choices - https://gist.github.com/petefusion/2cb38a7b9759c8ab9831 user/_ceremony-choices-get-user - https://gist.github.com/petefusion/2241ab1760cb2985321b user/_ceremony-choices-form-1 - https://gist.github.com/petefusion/8c5dcab447112da4cbce

_ceremony-choices-form-1 is embedded in _ceremony-choices-get-user, which is embedded in ceremony-choices, which uses layouts/default as its layout.

#5

BoldMinded (Brian)

Pete, can upgrade to 1.4.2 again, but take the publisher_model.php file from version 1.4.1 or 1.4 and see what happens? If that doesn’t do anything grab the libraries/Publisher/Publisher_channel_categories.php file from 1.4.1 or 1.4 and see if that changes anything. Those are the only 2 files changed in 1.4.2 that may have any relevant change on the templates, even though I think its far fetched and I still can’t replicate this myself.

#6

Pete Heaney

I tried what you suggested - upgraded to 1.4.2, then used those files from the 1.4.1 version. The problem was still there. What’s weird is that when I returned back to v1.4.1, the problem still existed. So it appears that downgrading to v1.4.1 doesn’t actually solve the problem. I have no idea why it appeared the fix the problem before.

However… my colleague had a look at the extension.publisher.php file and has come up with a solution that appears to fix the issue.

Basically, we’ve changed the safecracker_entry_form_tagdata_start() function to this - https://gist.github.com/petefusion/9919175151e590fc0b82

It now checks to see if the channel is in the ignored_channels array and only continues if it’s not.

I’ve tested it and it seems to work, and not cause any unwanted side effects.

#7

BoldMinded (Brian)

Thanks for that gist. I’ll take a look tonight and see if I can think of any reason to not add this.

#8

BoldMinded (Brian)

I’ve added this to the source code but commented out for now. I’d rather some more testing be done on your side when you get a chance to see if another add-on is potentially messing things up instead. Check your exp_extensions table to see if anything else is using the safecracker_entry_form_tagdata_start or channel_form_entry_form_tagdata_start hooks, and if so disable them and see if the issue corrects itself. It seems odd that this sort of check would need to be done all of a sudden in this hook, where as before it worked fine (and currently does in 2 of my environments). I can add this fix, but would rather know if another add-on is getting screwy first before adding more code to my add-on.

#9

Pete Heaney

I completely understand if you don’t want to add this code without further testing.

I’ve checked my exp_extensions table and there are no other add-ons using either of those hooks.

But if no one else is reporting this problem, then I guess it wouldn’t hurt to leave it commented out for now.

#10

BoldMinded (Brian)

Yeah, I’ll keep an eye out for similar reports and eventually get to some more testing. At least I have a fix if someone has the same issue. Thanks again for contributing it. Going to go ahead and close this ticket out. If you guys upgrade and see the issue occurring again just go in and uncomment the code I added.

Login to reply