Also, both of these modules have been around since EE2, and I rarely hear of conflicts between the two. Many people use them in combination, which is why I’m lead to believe its a configuration issue on your side. Try setting up a new EE 2 site with nothing but Publisher and Forms installed, and use the default settings of both but just create a 2nd language and enable url translation prefixes, then make a simple form and see if it submits as it does in my screencast.

TLDR; This isn’t a Publisher issue and I can’t fix it :/

The same thing is still true for when Structure is not available. The FormSubmission->handle_errors() method calls EE’s template parser before Publisher has a chance to do anything, so EE is thinking that the first segment which is the language code is a template group name, but it isn’t, so it can’t find a template to parse, thus it throws a 404. Its this code at the end of handle_errors() that is the problem. I’m always skeptical of add-ons that try to handle form submissions like this (a couple Solspace’s modules do this sort of thing too) and not let EE naturally do its thing. Its basically cutting Publisher out of the equation and not giving it a chance to do what it (or any other add-on) needs to do. I have a feeling the Transcribe module would do the same thing if you were using its language prefixing feature too.

ee()->load->library('template', NULL, 'TMPL');
                //ee()->TMPL = new EE_Template();
                ee()->TMPL->run_template_engine($template_group, $template);
                ee()->output->_display();
                exit();

Ok, lets try this. In the Service/Session.php file on line 272 you’ll see this:

if (REQ == 'PAGE' && !$this->url->isTriggerWord()) {
                $this->validateUrl();
            }

Change it to:

if (!$this->url->isTriggerWord()) {
                $this->validateUrl();
            }

Or change it to this, which may work too…

if (REQ == 'PAGE' || (REQ == 'ACTION' && !empty($_POST))) {
            // Create {page_uri:XX} and {publisher:*} vars
            ee()->load->model('publisher_site_pages');
            ee()->publisher_site_pages->create_page_uri_vars();
            $this->frontend->setGlobalVars();
        }

The reason it doesn’t work with template translations or routes is because the core_template_route hook is not fired when the form is submitted and when it tries to reload the page to show the error. Forms submits directly to an ?ACT url, which is fine, but it has code in it (mentioned above) that tries to determine if its a Page or Structure url, then goes on to call the run_template_engine method directly, which short cuts parts of EE out of its normal processes that determine how to render a page. I’m not a fan of how it is handling form submissions and returning error messages. It could easily cause conflicts with other add-ons since EE is not able to call the core_template_route hook (and potentially other hooks as well).

The Forms module should either post to the same url that the form is on, and then look at the POST array to determine what to do, or perform a redirect to the originating url after posting to the ?ACT url and display the error or success messages then. If it needs to perform a redirect and maintain the success or error messages it could save that data in a temporary flash variable.

I’m afraid there is nothing in Publisher I can change to make this work.

I may revert the change I made in the build I sent earlier because Publisher has been around for 5 years and I’ve never encountered a conflict like this with Forms before. I feel like that return parameter may be the key to this issue.

Who have you been talking too at DevDemon? I’ll reach out to them directly on this. I still feel like this is more of an issue on DevDemon’s side. Yes the issue is apparent when Publisher is installed, but its because publisher uses a hook that the forms module is bypassing. I’m not sure if working on this as a contract project will solve anything because I don’t feel like this is a Publisher bug, and I don’t want to add silly hacks to Publisher’s code or drastically change things just to make it work in this one use case. Like I said, I’ll reach out to DevDemon and see what they say.

Lastly, your English is fine 😊 If you didn’t say otherwise I would have assumed it was your first language.

I’m going to mark this ticket resolved b/c there isn’t anything I can do other than refactor a large portion of Publisher, which may not even fix the issue, and could very well break a lot of other things. I suggest looking into submitting the form via ajax and working with the folks over at DevDemon on how to do that.