[Resolved] Using “product” slug

[Author]

Posts

[glenn]

Form redirect not working.

And than create a profile on this page:
hidden link

When you submit this profile is when you get redirected to a page not found page.

Access Details here: https://toolset.com/forums/topic/user-form-allways-creates-customer-role/#post-951250

Kind regards,

Glenn

[Minesh]

Hello. Thank you for contacting the Toolset support.

Please kindly share a duplicator package which should be accessible to all users as when I escalate it to next level support the duplicator package is not accessible.

I have set the next reply to private which means only you and I have access to it.

[Minesh]

Ok - nevermind, I managed to upload it to drive again as its big file that was causing issue.

I'm escalating it to next level support again. Please hold on for further update.

[Beda]

HI Glenn, Beda here.

I see there is a longer history to the issue in another ticket and I already handled the issue there (but in the second tier)

As you know we decided to split this issue to a new thread, to keep it all a bit more organized.

Now, the problem I have been assigned with here, and which you reported, seems to happen after these steps:

1. Install this website: (the Duplicate)
2. Head to hidden link
3. Fill out as many fields as possible
4. Submit
5. It should redirect to the Page which the Toolset Form is instructed to use as redirect: Contact.

Now, I see that neither Luo, nor later myself where able to replicate this on the copy of that site, installed locally.
I tried this already several times now, as well with other plugins active like WooCommerce, and add ons.

Always that form redirects properly to the contact page it's set in the Form edit screen itself.

I actually made a little .mov illustrating what I do locally:
hidden link

Can you look at it and let me know if I miss a step?

That is the exact same install as you delivered in the Duplicate, but, I removed all Plugins but Toolset, and used a Fresh copy of the Theme Twenty Sixteen, as well as replaced the native WordPress files (the install itself)
The database and all the rest is still the same.

If I need another Plugin or code or specific theme, to replicate it, can you let me know?
I see you already mention that you tested this in the other tickets, correct?
Hence, it could be a server issue.

What we could do is set up the site on a test server of ours, for free, if you see no solution when you as well try with the same setup as you will see in my video.
Then we can see to replicate or not there, and act on that server.
However, I think, what the issue here is, are the PHP errors that are shown when the entire, original package is deployed
Those are the reasons I replaced WordPress and especially deactivated the non-Toolset Plugins and the not related plugins, as well as used a native Theme.

You say, in your server that does not help, so we can exclude a issue in the other plugins I removed.
It should then be a server problem which we could see to replicate on the test server I mention

Please let me know how the situation looks on your end after watching the video and trying those steps.
(The best, on a test site or after a backup)

[glenn]

Hi BEda,

thank you for picking up this thread. I have followed your instructions. I have reverted to the 2016 theme and disabled all plugins accept toolset and basic woocommerce. It still does not work. However i saw in your movie that you did not have toolset layouts activated. So i disabled that one and then the form does work. So it still seems like there is some issue with either toolset or woocommere. If you activate toolset layouts in your server, does it still work or do you then also get the same problem?

I have left the settings on the testserver so you can check it yourself(i also left toolset layouts deactivated. But you can activate it to see the error).

Kind regards,

Glenn

[Beda]

OK, I did not have Layouts enabled.

And with Layouts active, the issue is replicable.

It is confusing that in the package I received, there was no Layouts included - but however, when I activate it (which I should, I do not know why I missed it), I can replicate the issue when I fill all field.
When I fill all field but not the last set of checkboxes I can submit as well (I mean, with a successful redirect).

==> Note that in the Layout, that designs the page with the form, I change the Visual Editor to show only the title, and added a Post Content cell instead.
That is designated to show the content of the post as you have the Form as a ShortCode in that page's content.

So the problem is with all the fields, AND the last section.
If you leave out that section the redirect works.

Now, when you select the Check boxes at the end, all of them, then you get these errors when you submit (note, I also have added some values to the other fields, as usual - but this time as well selected all the checkboxes)
( ! ) Warning: trim() expects parameter 1 to be string, array given in .../wp-includes/class-wp-query.php on line 736
( ! ) Warning: strip_tags() expects parameter 1 to be string, array given in .../wp-includes/formatting.php on line 1981
Redirect fails.

So, the form could not complete, that is the issue that blocks the redirect, it is the PHP error above.

I have seen this in past, it was due to several fields, taxonomies, form and layout displaying it all:
https://toolset.com/forums/topic/cant-select-multiple-taxonomies-and-regular-checkboxes/

The exact issue we see here if you ask me.
In fact none of the taxonomies get saved as far I see.

And that would match this issue:
"Checkbox Field(s)" AND "A Custom Hierarchical Taxonomy displayed as Checkboxes" within a Toolset Edit Form, displayed via a Content Template used in a Layout, is failing.
That is quite much what we see here.

But this should be solved since Toolset CRED 1.9.1 and Layouts 2.0.2

Now, I have your duplicate locally where I can see the issue and probably already pointed the issue.
I just need to figure out, if that as well happens on a fresh install - then it is a regression

This will require me a little time and I will feedback here tomorrow the results.

In case I cannot replicate it, I will in any case work on the duplicate with the new data and steps, which now are clear and simple to replicate the problem
Then we can also find a solution.

For now, I see the only solution is to either remove all, or eventually just restrict the number of, taxonomies in that form.

That should solve the issue, but of course, you will not have the taxonomy fields in the form, this is hence only a workaround for now.

[Beda]

Analyzing this site, I see that you have a Taxonomy "Products" created in Types.
This is not a good idea.

I have just lately helped someone that had a taxonomy "author" registered that broke an entire Post Query:
https://toolset.com/forums/topic/post-author-filters-not-working/

In fact I found that you cannot re-save the taxonomy as "product".
It says what you see in the screenshot.

When I renamed that to product_custom I needed to regenerate the Form, and submitted it.
It works.
Even if I fill out all of the fields and taxonomies.

It seems to be the same issue as in the ticket linked above, just this time with another taxonomy as well using a reserved word (reserved by WooCommerce)

I need to know, how you made it to create a "product" taxonomy with Types, when you have WooCommerce installed.
It was eventually the other way around, you first installed Types, created such a taxonomy, and then added WooCommerce?

I did not try what happens when I do that, but I can confirm, that without WooCommerce, you can create a Product taxonomy in types, and with having WooCommerce installed you cannot do so.

Hence, what we can do here (and probably should) is add product to reserved words of types in curtesy of WooCommerce, I think.

I will ask the developers if we can do that.

The solution to this issue would be to not use the served word for the taxonomy.

[glenn]

Hi Beda,

thank you so much for your given explanation. I have done the suggestions you added and everything now seems to work. My clinet will be soooo happy that the problem is fixen and we can continue development.

I do think i installed toolset before woocommerce yes. So if this causes problems i think it woul dindeed be wise to make it a reserved word.

Also Minesh and Luo, thank you for your support too.

[Beda]

I did add the notice to make the word product reserved by default.
Thanks!

[Beda]

We will not make this word reserved.

It was decided it seemed unreasonable to deny users who make "products" with Toolset - but will never use WooCommerce

[glenn]

Hi Beda,

thanks for your message. It makes sense. I would however make it something noted in your documentation. To prevent future users pulling their hair out 🙂

Kind regards,

Glenn